Metamuse

By Adam Wiggins, Mark McGranaghanTechnology

Metamuse episodes

January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: As software developers, maybe we go towards
building a GUI with specialized inputs and forms and controls too soon,
because it’s so much easier to explain to the computer what the user
means if they use a specialized input tool like a button check box and
so on. But if that weren’t the case, if it’s easier for the computer
to understand what you mean as you’re typing in your note, then
suddenly text input is the primary thing.
00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac. But this podcast isn’t about Muse product,
it’s about the small team, the big ideas behind it. I’m Adam Wiggins,
joined today by Jeffrey Litt. Hey. And Max Schoening, great to be here.
Now, the two of you are working together with some others on an ink and
Switch project we’re gonna talk about today, but first, I understand
that there’s some cooking adventures going on in the lit household.
00:01:02 - Speaker 3: Yeah, so I’ve been trying to make my own stock
lately. I’ve been reading this incredible book that someone recommended
to me on Twitter called An Everlasting Meal by Tamar Adler, and it’s
all about how to use leftovers and just like random stuff in your fridge
to cook both as a way of not wasting, but also just cause it feels good.
So I’ve been, you know, throwing random like carrot tops and stuff into
a pot, and it feels really fun. That’s my recent cooking adventure.
00:01:29 - Speaker 1: Inspired by, we’ll get into it a little bit later
with the project too, but partially by Jeffrey’s cooking. I’ve also
started taking cooking maybe a little bit more seriously than before.
Like I think one of the things that sort of distinguishes the amateur
from someone who’s more seriously involved in something is consistency
and my cooking was never all that consistent cause the loop of how
frequently you repeat a dish when you’re just cooking sort of for fun
is very long, right? So the learning is slow, so I’ve been getting into
sous vide cooking. And just eating way more steak slash anything you can
sous vide that I would like, but at least the results are getting
better.
00:02:11 - Speaker 3: I’m a sous vide fan as well. It’s a major cheat
code, I find. Everything is perfect every time.
00:02:17 - Speaker 1: I wish that had been my experience too.
00:02:21 - Speaker 2: Yeah, consistency and repetition, yeah, short
feedback loops.
I was inspired by a book, I think it’s called the Food Lab, where
basically the author does some, call it like.
Amateur science in the sense of taking common cooking claims, like
should you salt meat before cooking it, or is it better if you don’t
flip it, or you only flip it once versus twice or something, it would
essentially just cook several side by side, varying this one thing. And
then do a little informal taste test with his, you know, housemates or
whatever, and sort of like try to answer that question, and many times
found out that, or at least had the finding, let’s call it, that things
that people swore by didn’t really actually make a huge difference in
the outcome, but that idea for myself, I think even our Mutual friend
and colleague Peter Van Hardenberg introduced a version of that in the
Hiroku offices when he would do a little coffee workshop and essentially
like brew a cup of coffee with several different approaches, you know,
here’s the Chemex, here’s the French press, here’s the, and then you
could taste them side by side and have new appreciation for the way
these different techniques change the taste of the same source bean.
00:03:34 - Speaker 3: Yeah, I love that mindset. I think what I see as
the challenge at home cooking is, you know, to bring in some of that
idea of getting better and being a little rigorous without making the
whole thing too overcomplicated and kind of perfectionist. There’s some
aspect of amateurism and just having fun with it, that’s sort of the
whole point to begin with. So I think that’s a fun balance to strike.
00:03:57 - Speaker 2: So longtime listeners of Meta Muse will know that
we’re shaking up the format a little bit here.
This is our first time with two guests. It’s usually me and Mark as
co-hosts along with one guest, and this is partially my theory that
it’s a little hard for listeners to adapt to two new voices, but in
fact, you two are not new to our guests potentially.
Max, you are one of our very first guests all the way back in episode 8
when we talked about principal products.
And Jeffrey, you joined us for somewhere around episode 34, where we
talked about bring your own client. So, anyways, I thought it would be
fun, especially because both of you work together on this research
project to get you here together. So you can go back and listen to those
episodes if you want the full backstory, but maybe you could each give a
32nd summary bio of yourself before we dive into the project itself.
00:04:51 - Speaker 3: Yeah, so I’m a grad student at MIT as well as a
collaborator with the In and Switch Research lab, and my research
mission is to figure out how to make software more customizable so
people can edit the tools that they use and make their own software, and
the project we’ll be talking about today has a lot of resonance with
that theme, so excited to be here again.
00:05:12 - Speaker 1: And this is my first foray into research. I’m a
software designer. I’ve worked on things like Hiroku, GitHub, cloud
app, way in the past, and generally I like to summarize. My efforts as I
like to make things for people who make where make is the developer
build tool.
00:05:33 - Speaker 2: And our topic today will be dynamic documents,
which indeed is what the potluck project that you both worked on and
recently published about is all about. So we’re hoping to dive into the
specifics of that project as well as some of the research process behind
it. Maybe we could start out with a description, kind of the, I don’t
know if elevator pitch is the right way to talk about a a research
project, but a short summary.
00:05:58 - Speaker 3: We’re not raising funding, but I can give a
summary, sure. So, Potluck is a substrate that we’ve been developing,
where the goal is to turn regular old text documents into interactive
tools that help you in your life.
And so there’s this idea that you can just start by, you know, jotting
a note on your phone like you might in an app like Apple Notes, and then
gradually you start enriching that note with little bits of computation
and interaction.
And if you keep doing that for a while, you might end up with something
that looks suspiciously like An app that you might download from the app
store, but it’s not like someone else made it for you, it’s sort of
organically evolved out of just a note that you started writing, and,
you know, some examples of the kinds of things that we’ve thought about
in the substrate are You’re writing down a recipe that your mom told
you for how she makes her dumplings, and then you decide, oh, I’m gonna
have a party, so I want to make 5x the recipe. What’s like 730 g times
5. That’s something that a computer should be able to help you with,
right? But if your data is in a text note, how do you bring in the
computer to play its role and help you out a little bit? We’ve
developed these primitives where you can start injecting these little
bits of computation as you need them into your text note. And so,
that’s kind of the overall idea of the project.
One analogy that I think is helpful to understand the general ethos of
it is spreadsheets. I’m a huge, huge fan of spreadsheets. I think
they’re a really empowering medium that people interact with pretty
typically on a computer these days. And the cool thing about a
spreadsheet, right, is that when it starts out, it’s just a bunch of
numbers in a table. It’s just data sitting there, and it’s already
useful in that state. And then gradually you might add a little formula,
you might add a V lookup, and if you keep doing that, by the end, you
might end up with this ridiculously complicated app that’s running your
whole business, but it didn’t start out that way. It wasn’t planned to
happen that way, it just started out as this little bit of data that you
were storing, and it naturally evolved, right? So that’s kind of the
general idea.
00:08:04 - Speaker 1: Yeah, there’s the well known meme of this insert
startup could have been a spreadsheet, and I think in this case, you
could probably make the same argument that this app could have been a
note.
And in fact, I would love to be able to do this at scale, but like if
you just open the average users notes apps, what kind of notes do they
take and, you know, throughout the course of this research project.
That was sort of a grounding force of, oh, what kind of notes do people
keep track of and so we started looking at, you know, like Jeffrey was
saying recipes. At some point we did workout tracking and plant water
tracking and like collecting your favorite hikes and so on, and they all
have this sort of very innocuous beginning. You’re not planning to make
something big, you’re just sort of planting a little seed as a note and
What was frustrating for us is, at some point, if you then want a little
bit more help from the computer, you usually have to move it out of the
notes app, which is a little bit sad because it’s this big drop off,
and so that’s kind of what we’ve been looking at, like, how do you
make that go away.
00:09:14 - Speaker 2: And I love the diversity of use cases outlined in
the essay.
You focus on this cooking use case as a sort of a central one, even
baked into the name of the project, but indeed all of these different
kind of personal tracking stuff that tends to get scribbled down in
notes and and in particular notes in your phone, text notes in your
phone, that they’re not very structured, you’re trying to capture them
in the moment and move on.
And certainly many of those are things I have done, but also there is a
whole industry is a way to put it, category of app which is trackers.
So, yeah, hike trackers and run trackers and sleep trackers. And yeah,
fitness trackers, step counters, weight trackers, you know, and
sometimes that’s paired with, I don’t know why, you know, Fitbit has
their Wi Fi connected scale, and when you step on it every morning, it
automatically records the data, but then a weakness for someone who is
both curious and has some light programming capabilities is actually
getting that data out or doing something with it in a more flexible tool
like a spreadsheet. is often pretty difficult. Actually, Fitbit, I think
even famously had a little bit of pushback for the, you had to pay for
the feature to kind of like download your data as a CSV and even then it
feels like this very discontinuous, OK, I’m exporting now, the data,
who knows what format it’s even in, and there certainly can’t be a
continuous using of the app, inputting of the data, and then also I’m
gonna put it through my own, call it personal analytics.
00:10:43 - Speaker 3: Yeah, and I think another weird thing about this
ecosystem of trackers is that it sort of splits up your life into these
very specific categories, right? So, for example, after my workout, what
if I have a nutrition shake and I’m tracking my nutrition, I need to
switch from my workout tracker to my nutrition tracker, and there’s
this sort of world that each app considers its space that it doesn’t go
outside of, you know? This also happens when, you know, We looked a lot
at recipe apps because we were thinking about cooking as one of our main
domains with this tool, and a lot of cooking apps start out very simple
with tracking your recipes, but then there’s sort of a natural force to
bloat them with extra stuff, so, You’ll add grocery list stuff, and
you’ll add menu planning, and, you know, meal planning for the week,
and all these.
00:11:29 - Speaker 2: All of your friends, what are they cooking?
00:11:31 - Speaker 3: Yeah, like social, you know, and I feel like
we’ve all experienced this tool starts out nice and small and grows in
weird ways.
And what I think is important here is, I’m fine with it growing in the
ways that I want it to be useful.
What’s annoying to me is having 100 things crammed in there that I
don’t need and can’t remove from the tool. And then on the flip side,
the one extra thing that I do need, I can’t add myself, right? So, we
sort of like, let the developer of each tracker decide what does cooking
or what does workouts mean, like, what’s the scope of that activity,
and it’s really hard to permeate that kind of boundary that gets set
there, and so that’s one of the problems that we were thinking about in
developing potluck.
00:12:12 - Speaker 2: So some of the key concepts here, dynamic
documents is obviously a spreadsheet is a dynamic document, but the idea
here is taking text, plain text, which is incredibly universal.
Everybody’s phone has some kind of plain text notes app just kind of
built in by default, but then you can use gradual enhancement to add
some computation and make it something dynamic while keeping that same
basic medium of just simple text you can manipulate.
That you also talk a little bit of the essay about personal software,
which I think is precisely this concept you’re just describing here,
which is rather than my run tracker being an app that I download from
the app store and I’m more or less just have to use it as intended by
the developers, that I can use the computational medium to build a quote
unquote application that just suits my needs, is truly personal.
00:13:05 - Speaker 1: Yeah, personal software is, well, first of all, I
think it’s getting more mainstream in the sense that if you look at a
lot of people’s notion, usage, and all the other insert, you know,
personal knowledge management tool here where people are sort of
aggregating all of this stuff in their life into a personal OS and I
don’t know where the appetite comes from. I don’t know if it’s tied
to increased computer literacy, at least some form of computer literacy,
or it’s people have been burned by their favorite app changing either
by adding too many features or just being deprecated, but there seems to
be a lot of energy around it and so one of the things that is
surprisingly Or rather, something that you wouldn’t think about right
away is when you start building these apps from scratch from a note, you
never really notice that you’re actually making a big complicated
thing. You’re just starting out with some text and at some point you
start adorning that text with some functionality and you just keep going
and going and going, and at some point you wake up and you’re like,
wait, this is actually quite complicated logic.
Am I a programmer? And for us, that sort of was quite important, right,
like embracing this notion of personal software that is truly yours, not
from some team somewhere in Silicon Valley or wherever else deciding
what’s best for you.
And I think Jeffrey, you gave this analogy early on to like imagine our
homes were Just furnished completely by other people, and all the
objects in there just are sort of almost immutable, like we would not
have that, and we do with software, and so I think nudging at that is
super interesting.
00:14:53 - Speaker 3: This is one of my favorite ways to Open up my own
mind to how weird software is, is to use analogies to other parts of the
world, you know, I think we sort of have gotten so familiar with these
metaphors of how software is organized.
Like, in some sense, in this potluck work, what we’re doing is arguing
against the idea of applications, right? Which is a really weird
argument to make to a typical computer user, you know, it’s fish and
water, like, what do you mean? I love apps. Apps are how we do things on
computers, but It doesn’t have to be that way.
I mean, Alan Kay, who’s responsible for a lot of the metaphors we use
in personal computing, has, I think, said that apps were like the
biggest mistake that was made in software ever, or something like that.
You know, another analogy to bring it back to the food thing, I think,
is restaurant versus home cooking. And the reason I like that analogy is
that I think it gets that, I’m not trying to argue that we should ban
restaurants. I love going to restaurants. It’s more like, if you
imagine a world where All you can eat is restaurant food every day for
every meal, and you think about what kind of society that would be, it
starts to feel a little weird, right? When you go to a restaurant, you
are putting a lot of trust in someone else to give you a good
experience. You’re accepting kind of a restriction in choice, whether
that’s like a full on oakcase, you know, meal, or even, you know,
picking from a menu with 10 items is very different from going to the
grocery store, right? But also, you’re acknowledging maybe that chef
can do things I can’t, and maybe I’m tired today and don’t want to
cook, whatever the reason may be, it’s nice.
But it’s also a certain kind of limited experience, I think.
And when I look at home cooking, I see a totally different set of
trade-offs and values almost, where I’m not trying to become a
professional, I’m not trying to make the best thing, I’m just trying
to make something nice for myself that I like, and, you know, for my
family, whatever. It’s a very different scale and and feeling, and I
think that’s sort of the right way to think about, you know.
There are always going to be tons of professionals making software, and
I think that’s great. I love Apple products where someone in Cupertino
has thought for a year about what the width of this button should be.
I’m not against that, it’s just that I think there’s also this
complementary role for a different way of thinking, especially in these
more personal domains.
And one last thing I’ll say about the home cooking analogy that I think
is interesting is that it’s a very cultural thing. If you imagine a
world where everyone always eats at restaurants and you tell someone,
you know, why don’t you start cooking in your house? They might be
like, well, I don’t know, that seems really hard, like, all these chefs
have spent like years in school or whatever, and, you know, you can see
the analogy here to, like, currently software is so professional and
difficult, that it just seems unthinkable that everyone would be making
this stuff themselves every day, but I think we can imagine a culture
where that’s a little different, and, you know, try to promote that
kind of Thinking and culture more generally, and I think that would be a
good thing for software.
00:17:51 - Speaker 2: Yeah, I think the restaurant versus home cooking
comparison is a great one, and also just reflects the fact that in the
scheme of things, computing is just so new, and we don’t necessarily
know how it fits into our lives and our society and how to relate to it,
and we’ve ended up in this, you can think of it as a local minima or
just a particular circumstance of time, which is that software is built
by these professionals who are typically far away and building for many,
many users. That’s not where we started with computing, and I certainly
don’t think that’s where we’ll end up, but hence the reason to invest
in research to take us in this direction.
Now one thing I think your project touches on that’s an interest of
mine, obviously I would lump this under end user programming, something
we’re all interested in essentially bringing programmability of
computers to a wider audience, not necessarily in a professional app
building context, but just in the sense of embracing the dynamic medium.
But I feel one of the big unsolved problems of end user programming is
really just getting it into a context where people can use it. There’s
many, many really amazing research projects and prototypes and etc.
where if you go into there, I don’t know what, here, launch this small
talk browser and once you’re within that world, everything is malleable
and composable and you have total power, but it’s not connected to
anything you do in your life. And one thing I like about how your team
went about this project is that You’re starting from text notes, which
are on your phone. Now, it’s sort of an unanswered question is how
exactly this computational medium gets into the notes app or whatever,
that maybe it’s not a part that’s figured out, but very
hypothetically, going from, I’ve got this text file or a series of text
notes, and I wanna layer this dynamic medium on top of it, feels like a
lot less of a jump than many of the other kind of programming
accessibility research that I’ve seen.
00:19:47 - Speaker 1: Especially cause if you actually look, for
example, Apple Notes, right, it already has hints of these data
detectors. If you type a phone number and I don’t know, a few other
dozen types of content, it automatically finds them for you and
underlines them, and then you can, you know, tap and initiate a call and
potluck just takes that notion to an extreme by saying, well, first of
all, I can write my own detectors cause I don’t just want to find. A
phone number I might want to find the quantity of a recipe and then it
also just doesn’t limit you just to the oh I can tap and initiate a
preprogrammed action. I can do something else with it, a calculation,
fetch some different data and so on, but it’s a very gradual enrichment
of the original note and it’s also already somewhat at home on iOS. I
don’t know, Jeffrey, if you want to talk a little bit about the data
detectors and the origin.
00:20:47 - Speaker 3: Yeah, totally. One of the more interesting kind of
related work references that we found while we were thinking about this
stuff was, what I think is the original paper describing the seed that
has become these, you know, phone number recognition and stuff in modern
Mac OS and iOS.
But there was a research team at Apple in the late 90s, which included
Bonnie Nardi, who’s sort of well known in the end user programming
space. And it’s really interesting seeing the original rationale they
had for how they got to this idea of data detectors.
Their starting point was thinking about, OK, how can computers help us
do stuff and be intelligent helpers, and they Sort of draw this
distinction between two styles of how the computer can help you.
One is the computer just does stuff for you, or like, you know, you sort
of vaguely say what you want and it doesn’t, sort of more of an
assistant metaphor, you can imagine, you might not even know it’s doing
stuff, it’s just behind the scenes. And I think this sort of
corresponds to some of the modern ways that people think about, oh yeah,
AI will just do it for you type of thinking.
But they realized that actually, both at the time that was totally
infeasible. Computers weren’t good enough, weren’t smart enough to
actually pull that off in a satisfactory way. And they also realized
maybe it’s not quite what we want, and they went down another path,
which is, let’s just have the computer find stuff for us that we care
about, like, dig around in all the things on my desktop and find useful
information, and then let me decide what to do with it.
And You know, as Max was saying, I think their view of what you can do
with the information was relatively like straightforward. You just right
click on a phone number and you hit call this number, simple
interactions like that. But still, this idea that the user was in
control of what to do with the information. And so, I think that’s a
really nice kind of design goal for these sorts of systems is carefully
balancing what are the parts that we want to be automated versus where
the moments that we want to be in control, you know.
00:22:49 - Speaker 2: And data detectors is the term from, I think that
paper in the potluck essay, you call it extensible searches, is this a
rebrand to be a little more familiar to current audiences, or do you see
that as actually, it’s because it goes beyond these more automated kind
of default types, like a phone number and address?
00:23:10 - Speaker 1: With a lot of the stuff, it’s very serendipitous
about how it happens during a project, and we initially didn’t even
start out with potluck having these continuously running searches. It
was much more of a manual process.
In fact, I think to this day, if you look at the code, it’s still like
cold highlighters because we started out with this notion of, well, you
have a note and then the sections that you care about, you’ll just
highlight and you have different colors for highlighters to start
imbuing those highlights with computation.
And someone on the project at some point sort of said, oh, well, why
don’t we just run a search against it? And at the time, I think we
didn’t even call it search, it was just a pattern. But if you think
about how mere mortals would maybe think about this as well, I have like
a Google doc open. How do I target a specific word in the Google Doc?
Well I hit command F and I try and find it, right? And so that’s where
this notion of search comes from, which is sort of the Most maybe human
way of thinking about these detectors.
00:24:11 - Speaker 3: Another small thing I’ll add is that one of the
really cool parts of the original data detector’s vision that we share,
but it’s kind of been lost in the modern Mac OS version, is this
extensible part of extensible searches is also really important, the
idea that you can define your own.
You know, in potluck, this means that you can decide that these are the
types of ingredients that I want to find in my document, and nothing
else. I control the dictionary of what I consider foods, or I control
the list of workouts. So if I write, you know, squat, my note will
recognize that that is a kind of workout that I do, but all of it’s
sort of very tailored to your life.
And the original data detectors paper had this too. They had this idea
of, for example, you would teach the system, here are all the names of
the conference rooms in my office. So whenever I write the name of a
conference room anywhere in my OS, the computer will just know that
that’s what that means. And of course that doesn’t apply to every Mac
OS user, it’s more of a personal data detector that’s tailored to
exactly my context.
00:25:08 - Speaker 2: Maybe like adding a word to the dictionary so that
it doesn’t show up as a spelling error because it’s some nickname for
something in my life that wouldn’t make sense to add to a global
dictionary.
00:25:20 - Speaker 3: Yeah, exactly.
00:25:22 - Speaker 1: It’s funny to think about how frequently we have
data detectors in the software that we use, right? Like on GitHub, if
you want to reference an issue, you do pound 247, and that’s a data
detector, famously like Twitter hashtags and at mentions were all not
built into the software. They were just ways in which people invented
small little microsyntaxes very fluidly.
And there is no primitive in the operating system that is not super far
down to actually do something fun with those, right? And so by making it
super easy right in the context of the note to write a new data detector
and super easy, we can get into that a little bit later, is obviously a
spectrum.
Ours still involves way too much knowledge of programming to be super
easy. But the power of inventing those small microsyntaxes is super
addictive.
Like you just start coming up with small things that only you are
familiar with, kind of like in a notebook, you would have some sort of
notation, and it’s just flabbergasting to me that operating systems
haven’t embraced that at a more sort of a cross app boundary level,
right? Like, I think to this day there is a class in Some SDK from Apple
NS data detectors where I believe developers of apps can write data
detectors for you, but you as a user have no influence over them, which
is fine, like I guess some developer could build an app that lets you
write your own, but partially what gets left behind there is that the
same data detector should run across many applications.
If I have that, you mentioned a meeting room. If I have a meeting room
name, then you should highlight it in iMessage in mail app in notes and
my 23 other apps that I’ve just downloaded from the App Store, and
that’s sort of lacking. If you read the paper, I highly recommend it.
I’m a huge fan of BonnRD. It’s very sad that we don’t have that in
our computers today.
00:27:24 - Speaker 3: And I think this brings it back to what Adam was
talking about earlier around integrating with the rest of your tools,
right? Sometimes. I think a really important point to make about this
research project that we’ve made is that currently, just to be able to
move freely, we’ve built this thing as it looks like an app.
You open this thing called Potluck, it is, you know, a web app, there’s
a text box and you can do all these fancy things with the text, but the
final form of this that we envision being good is not a separate app,
it’s deeply integrated with all your other tools.
You could imagine any app that has text, you should be able to pull this
panel of searches over and just start pointing it at any text in your
system.
And we actually built a little bit of that into our prototype where we
do some things where we actually interopt with.txt files on your file
system. So you have a little bit of being able to open these text files
in the text editor of your choice, work with them, and then when you
look at them back in potluck, you see the interaction appear on top, but
I think that one of the interesting open questions that we haven’t
quite figured out yet is, how does it really work for this to be
embedded at more of an OS platform level? Like, where do these search
things live? How do you share them with other people? How do you share
them across apps? It’s just sort of an interesting design challenge to
think about there.
00:28:43 - Speaker 2: I feel like there is a commonality across many
research projects that I was involved in and I can switch in maybe in
general in the research world, which is if you could do it just in an
app, you would try that, but the whole thing that makes a research is
really this is something that should probably be operating system level
or just cuts across.
This tech stacks or the tools you use or the devices you use in a way
that isn’t really well supported by the current ways that things are
divvied up or the way that we kind of compartmentalize the various
elements of our computers and hence the only way to try them and see if
they are plausible or good ideas in. or how they feel to use is to do
them in this research context where you kind of have to hand wave and
say, well, imagine this was built in your text editor or cut across all
your apps or you know was there in the browser or you have a good way to
share these things.
Would we want that? Would we like it? Would that help us? And that
doesn’t get you all the way to what it would look like in the real
world, but it certainly is a fair sight further than just sketching it
out on a whiteboard.
00:29:49 - Speaker 3: The first one is figuring out what we want,
prototyping the experience with enough fidelity that we actually have
some idea of what platform primitives we would like to have available.
And then the second part, which I think is at least as hard, is how
would you actually enact that kind of change in the world. If the thing
you’re doing is not trying to add another app to the app store, but
totally change the structure of the app store, and all the economic
incentives and the technical interfaces between things, that’s a very
different shape of challenge, and so, yeah, it’s a lot.
00:30:24 - Speaker 2: Now obviously I’ll link the essay in the show
notes, and there’s also a live web demo that’s pretty workable, I
think, or at least in my experiments with it got pretty far, which is
saying a lot for a research prototype, which tend to be, you know,
focusing on the learning rather than the polished product. So I’ll link
both of those in the show notes and people should certainly check them
out. I’d be curious to hear briefly. On the findings and what you
learned from building this and trying to use it in practice. Was there
anything that stands out as surprising or unexpected?
00:30:58 - Speaker 1: I think there was this distinct moment in time
where the prototype was actually good enough, that inventing your own
syntax for something was very trivial.
You could just say something like find every line that starts with plant
emoji, and then suddenly do something with it.
And I still remember it having the feeling of why doesn’t all software
work this way. And so to me it wasn’t super obvious that personal
microsyntaxes should be a thing, and the idea that the same way you can
scribble personalized notations into a paper notebook, that we could
bring that into software.
If you make it easy, right? If you don’t make someone go into some
settings screen that’s 4 pages deep to say I’m going to change how
this works, right, like usual programming, but just ad hoc, you’re
like, oh, I’m just gonna start these next lines with, and, you know,
famously look at markdown, like, I’m gonna start the list with
asterisks. Well, I can just invent that. That to me was actually a very
surprising finding is the ease of creation of a syntax and then the
utility.
00:32:07 - Speaker 3: I think for me, one of the surprising things was
just how nice it is to work in text. This might be sort of a bit of my
programmer brain, you know, speaking, but I’m not typically one of
these, you know, everything I do is in plain text kind of people, but I
found that We’re so used to editing text. We have really strong muscle
memory around, for example, things like, I can select some text, cut it
and paste it somewhere else, or I can even paste it into another app, or
I can undo, and I understand how Undo is gonna work. And all these
little affordances are really mature in the systems we use, and they’re
mature in our heads. They’re really strong conventions, and I think One
thing we found is that when you build software on top of that really
solid foundation that we all have, a lot of things just sort of fall out
of that.
So, for example, when all of the state of your application and all of
its UI live in a text file, you can just snip parts, move them around.
If you undo your app has undo for free because it’s state is stored in
the text. You get all these things out of that. And I think there’s
some lesson there it feels about, I guess it’s about using the same
well developed tool for many different things.
I’ve used the analogy before of, it’s like a chef’s knife, where
it’s like, good at all these different things and someone put a lot of
effort into making it really good and versatile. It feels like there’s
something similar there going on with text, and It’s not a new insight.
I think there’s lots of people out there who do Emacs or there’s all
kinds of to do list apps, or, you know, budgeting apps based around text
files. I think that’s a thing that some people have been experimenting
with for decades, but it was surprising to us just how far you can push
that into so many different domains. Of course, you can’t do everything
with text. There’s lots of apps that would be ridiculous to even try
making them potluck, you know, YouTube is not the target, but I think
that’s fine, you know, there’s some Kernel of personal use cases that
fits really well with this medium, I think.
00:34:05 - Speaker 1: Yeah, plain text, or just maybe text in general,
is a surprisingly good layout engine in the sense that if you want to
make personal software very frequently you’re gonna have to go and come
up with your own layout.
Oh, I’d rather actually have these things at the top and not at the
bottom of the screen. And I think maybe because as professional sort of
software developers, maybe we go towards building a GUI with specialized
inputs and forms and controls and all that stuff too soon because it’s
just so much easier to explain to the computer what the user means if
they use a specialized input tool like a button check box and so on.
But if that weren’t the case, if it’s just easier for the computer to
understand what you mean as you’re typing in your note. Then suddenly
text input is the primary thing.
And if you think about what we do on computers all day, including people
who are not sort of in the industry, yes, Emacs and so on, great, but
you spend most of your time writing texts to people, right? So if you
can’t type on your device, then you can barely use it, which means most
people who use devices spend a lot of type typing.
And I think we should encourage software designers and developers to
lean into text way more than we do, and like you even see that possibly
in this resurgence of the command K command lines that every app now
implements, right? Like command palettes, which are also just text-based
entry.
And so I think potluck maybe takes this to the extreme of saying, look,
just write whatever you want, and then we’ll just teach the computer
with you how to interpret what you wrote, and then you can do awesome
things with it, and that’s kind of exciting to me.
00:35:47 - Speaker 3: In some ways, it’s like even one more step
towards messy than spreadsheets.
Someone at the lab was computing a spreadsheet, I think, to sum up how
heavy things would be in like a backpack for a hike, and At some point
they realized, oh, I should just do this in potluck, because even the
effort to put it in a spreadsheet table was just felt like a little bit
of ceremony, like, spreadsheets are sort of clunky to edit on your
phone, for example, whereas text, it just kind of, it’s one
dimensional, so it resizes onto your phone, you just type characters in,
it’s very low ceremony, and so if you can get the interaction you want
out of such a messy data substrate, in some ways I think it’s like a
good go to before you start adding too much structure.
00:36:29 - Speaker 1: Yeah, there is this, I think we link to it in the
essay as well, a paper, deferred formalism, which sort of encourages you
to not get into structure really early on, right? and text is great,
like I can just put the cursor in the middle of a line, hit return and
now I have two lines.
And if you think about some of the tools that are extremely popular,
notion and so on, they always make that distinction of are you inputting
pros and making a list, or do you want more structure to do some
computation, which is, oh great, now you have to think like a DBA and
the notion of being able to move between those two modes fluently, I
think is really cool.
And at the same time, if you can afford to push the formalism as far
back into the process as possible, right? Like, hopefully without the
app hopping, right, of like, oh, I started thinking in Muse, and
suddenly I want some more structure. Therefore we have to go get out a
spreadsheet and at some point you’re like 6 level deep writing a rails
app with a SQL light database and you just don’t, you know, it’s it’s
not the way to go.
00:37:34 - Speaker 2: And now when it comes to structure versus free
form, I do think there’s a feedback loop when you talk about
microformats where you kind of are inventing your own little structure
as you go, just naturally, even like writing in a notebook can be
something like this.
Yeah, some of the trackers you mentioned there, one use case that came
to mind for me was in the early days of parenthood, we basically had a
log for things like feedings and sleeping and diaper. because it’s very
useful, especially with handoff between caregivers to just at a glance,
be able to look at this and see when was the last time they ate, when
was the last time they slept, because that tells you a lot about trying
to figure out whether they’re crying right now, what need they’re
expressing when they’re crying right in this moment, as well as other
maybe slightly longer term analysis in terms of like, OK, are we getting
enough sleep each day, for example.
But there does tend to be a feedback loop if you do add the rigor of the
computer trying to parse it, even if I’ve written that search for
myself, then that is going to enforce as a strong word for it, but
encourage me to use a format that can be easily parsed and to be
consistent with that because I make my job on the called the programmer
side or the adding the dynamic aspect to it a little bit easier. Did you
see something like that in your user testing?
00:38:55 - Speaker 3: Yeah, I think there’s a really interesting
tension here where it’s exactly what you’re pointing out, where on the
one hand, we don’t want it to feel like programming.
So in textual programming, especially for beginners, you’re typing in
characters, and there’s a very, very strict set of rules defining
what’s valid and invalid, right? And if it’s valid, you get nice
syntax highlighting and everything, it’s great, and if you have one
comma missing, everything falls apart, and so we I thought that it was
really important that you don’t start feeling that way in your text
notes.
It should generally have the sense that you can just type the way you
normally would. But of course, on the other hand, we still need to
figure out what you meant. And so you need patterns that are
accommodating enough to let you write, but also rich enough to figure
out what you meant and extract the meaning. I do think one thing we
realized is that there’s a big difference between applying patterns
later on to some text that’s already sitting there, versus having them
being applied live as you type. Because in potluck, as you type, for
example, if I type 5 minutes into a note, by default, potluck has this
time recognizer built in, which will search for all the durations you
add to a note. And when I type 5 minutes, this underline just appears
and clicks into place, and I sort of get this live feedback that I’ve
typed a duration that the system has understood. And we just found that
that felt really good. It feels good to have the system give you that
signal that it recognized what you did. And obviously, if you were
expecting it to recognize something and it didn’t, then you realize
that because of the lack of feedback. And so, what we found in our
experience using this thing was that if you have the searches running as
you’re inputting the data, it does have this natural nudging force of
making you aware of the structure a little bit and maybe being a little
more mindful of where you put. New lines or things like that, but again,
shouldn’t be too rigid ideally.
00:40:45 - Speaker 1: Adam, you do bring up an interesting point. I
think partially why notion is so popular and such a great tool is that
it does invoke a little bit like this collector mindset of I’m just
going to collect, you know, whatever you’re into and make a nice table
so that I can actually reason about it as a collection instead of
individual items, right? And like I always joke that sort of computers
are really, really good at doing stupid math and for loops. And maybe
one way of thinking about this is if you look at the user interface for
potluck, on the left hand side you have sort of this messy, I’m just
going to type stuff out, and as you write searches that match against
the document, it populates a table and that table can have arbitrary
metadata, right? So I can add a new column and say actually for this
timer, I’m going to add a different property and The idea of having
both, both this sort of reasoning about things in collections, large,
you know, all ingredients or whatever, and the idea that I don’t have
to do that from the beginning, or if I change my mind, it’s not such a
big deal, is really appealing to me because I think we usually switch
modes from reasoning about the individual thing to the collective thing
and back and forth and back and forth and software today just makes you.
Sort of jump through hoops if you’re switching between one or the
other, and potluck tries to, as best as possible, sort of make that
fluid.
00:42:12 - Speaker 2: One thing I wanted to ask about is, in the future
work section, you talk about machine learning and language models, which
is a pretty hot topic among certainly the tech world broadly and also in
the tools for thought space. Since you are focused so much on text as
well as detection, what role do you see that as having either now or in
the future?
00:42:34 - Speaker 1: It’s really interesting timing because as we were
writing the paper and like doing the research project, all these big
language models and like stable diffusion and a bunch of other things
sort of came out and became sort of accessible to like hackers, I would
say. I mean they have been for a while.
But at some point we were thinking about, well, we have these searches
and the way we’ve implemented searches both sort of from a time
perspective and maybe a little bit of a philosophical thing that we can
get into, are all, I don’t know, like rejects, we have our own pattern
language and so on, and you can if you want to write rejects. It’s
obviously not super approachable to mere mortals.
So how wouldn’t it be cool if I could just have a note and say, find me
all things that are quantities of food. And then GPT 3 goes off and
comes back and says, here are the ones that we found.
And I think it is so obvious that the data detectors will get so much
better the better machine learning gets, right? And you can kind of get
a glimpse of that future in the photos app on, I forget the current
photos app on on iOS, where if you take a picture of a recipe index card
and it says 24 g of sugar. It’ll actually, you can tap and hold and
it’ll do a unit conversion for you. Now, it won’t let you do anything
else because somebody decided for you what you should do with those 24
g. That’s the part where we would hope some other, like some maybe some
more extensibility, but that’s just machine learning, finding the 24 g
for you and you don’t have to do it, right? And so I think it seems
somewhat obvious to us that all the detectors that are currently
patterns will just become much more human friendly ways to describe
patterns.
00:44:16 - Speaker 3: I will add one interesting tension that we were
thinking about a bit. We didn’t end up implementing AI based stuff in
the project since we didn’t have time to get into it, but we thought
about, you know, do you want the AI to find the stuff for you, or do you
want the AI to essentially write a reject for you? And those actually
end up being pretty different things because predictability and speed
actually end up mattering a lot.
When I’m typing, I wanna be able to learn.
You know, if I type this string, is the computer always gonna see that
as a food or not? And if you have machine learning in the loop for
actually doing the detection, It’s probably pretty hard to get
guarantees around, oh, you know, it depends on where it is in the
sentence, or how the model’s feeling that day, whereas if you have a
more deterministic pattern, that gives you something that you could
learn as a human, like how it works, and sort of learn to wield
predictably, but there is a tough tension there because the predictable
thing probably is gonna miss a bunch of cases that the ML could have
found.
So, I think there’s an interesting design challenge there and how do
you Get a system that does both of those things well.
00:45:22 - Speaker 2: And maybe an example of that from kind of an
earlier phase of technology is autocorrect, which on one hand was this
huge enabler to be able to type full sentences on a phone.
On the other hand, is the source of huge running jokes, you know, it’s
basically the butt of jokes, which is like autocorrect, does hilarious
things all the time, people are used to that, it’s part of modern life
in a way that, oh, I pressed the wrong key on my keyboard. I guess that
happens sometimes, but it’s so infrequent for someone who’s a
reasonably competent typist, that it’s just not a point of discussion,
and, you know, it’s one thing to use autocorrect to bang out a quick
text message to someone, but if you’re a book author and you can sit
down and write your book, Autocorcrack is not the right solution for
you.
You’re gonna become a touch typist with a precise keyboard, maybe you
get a mechanical keyboard with big chunky keys, because, yeah, you want
precision from your tool and you’re willing to invest in that.
00:46:18 - Speaker 1: Yeah, I think it may have been Paul Shan on the
team that came up with the funny analogy of, we were arguing about AI
cause I think sort of just what role should it play in potluck and so
on, and One of the things he referred to current AI models to is like,
look, this is like the toddler stage, and if you go and say, hey, go
toddler, find me the ingredients on this table, you’re probably not
going to just blindly take them and then cook a meal. But at the same
time, if you can send off 10,000 toddlers to try and find the
ingredients on the table, and then you check their work, seems pretty
reasonable, right? And so I think that the idea of having the ML try and
suggest something to you. But then you check the work, commit that and
say this is the correct thing that you found, then it’s a totally
reasonable approach, right? Like, I think GitHub co-pilot does this for
programming, like you’re not writing a method call that at run time.
Goes to GPT 3 and says please sort this list. It gives you the text to
autocomplete that then you commit and run. I say this as now there are
examples where GPT 3 calls itself to do stuff, which is both super
exciting, but at the same time, you probably wouldn’t want that to be
part of your stack all the time cause you can’t rely on, you know, the
model upstream changing and suddenly saying that the car is an
ingredient and yeah, but I think that tension. is good. I think we
haven’t really figured out what the user interfaces for AI and for that
interaction looks like, right? Like right now, all these interfaces are
just slot machines. Like stable diffusion is just, it’s addictive
because it’s a slot machine. You type in a prompt, you have to wait 30
seconds and then you get the variable reward of nice picture or not nice
picture. But for a tool, I think you would want something a much more
fluid and fast, right? You can’t wait for 30 seconds and you probably
also want something much more predictable. I think it’s a future
research project waiting to happen to say, in an environment like
potluck, what role does AI play and how would you go about designing
that?
00:48:23 - Speaker 2: Well, it’s all super fascinating stuff. I highly
recommend reading the essay, trying the project, but now I want to
switch gears a little bit and ask you both about the process.
What does it look like to, I guess, come up with research to work on in
the first place and certainly within the can switch container, recruit
the team and run the project and how long does it last and who’s on
it.
And I’m especially interested to get both of your takes cause Jeffrey,
you’ve done a bunch of Ink & Switch projects at this point, as well
as been in the research world for a while, and Max, this was sort of
your first exposure. You’re very accomplished in the commercial world,
but this was your first exposure to both the research world and I and
Switch. So, yeah, give me the rundown. What does the inside of this box
look like?
00:49:08 - Speaker 3: Yeah, totally. I guess I can speak to how the
project originated as the person who kind of started bringing things
together here.
So I can Switch typically these days runs projects that are You know,
around 10 to 12 weeks, which is pretty short from a research
perspective, and what we try to do is bring together some small team of
people for an intense period of time there and just really focus, you
know, ideally everyone’s full time and just intensively work on some
aspect of a bigger problem. And so, before that, there’s this phase
that we call pre-infusion, which I think Peter talked about when he was
on Metamuse, where there has to be some prep work to figure out, you
know, who do we need on this project, what’s the question we’re
asking. In this case, we knew we wanted to do something related to the
themes of malleable software, you know, this personal tool stuff, but we
spent a while kind of searching for, I think it’s important to have
kind of a nucleation point of some kind, something you can latch on to
as a place to start, especially, I’m a fan of having some concrete
examples or use cases in the mix at that stage, because what I found is
that if you start with your prompt being like, how can we reinvent the
way people do work or something, it’s easy to get lost in the woods,
basically, whereas if you can at least focus on one thing to start and
then branch out from there, it makes it easier. And so, I think Peter,
the lab director and I were having a conversation, and we’re both big
fans of cooking, and so we just started talking about, you know, isn’t
it kind of weird that recipe apps are simultaneously so popular and yet
seem to do so little and have all these frustrating restrictions, and so
we thought it’d be fun to run a project where the original prompt was
kind of, could you make a recipe app yourself, and, you know, go from
there. And a lot of the ideas that ended up emerging in pot, like, we
didn’t really Set out specifically to answer that, you know, specific
question, it just kind of more emerged from the original prompt. So
that’s kind of on the idea side, and then on the people side, you know,
I am a big fan of small teams where everyone can kind of do everything a
little bit, generalists, especially in this case. I think one of the
tough things about this kind of work is that there’s a lot of context
you have to build up, and so I felt that it was important to get a team
together that had at least been thinking about these general kinds of
problems before. You know, if you bring a typical engineer onto a
project and say, let’s get rid of apps, you know, that’s sort of a
strange place to start, right? And so, anyway, that led to, obviously
Max, as sort of a design focused person, and then Two other people, Paul
Shen and Paul Sonnetta, who are both, you know, more engineering
focused, but, you know, all four of us had previously thought about
these themes, and so it was really fun to get this group together and
kind of jam on, you know, each having a different perspective on what it
means to make personal tools, but kind of find a way to blend them in a
way that made sense. So, that’s kind of the general overview, I guess.
00:52:12 - Speaker 1: I think you had a comment early on when we were
doing intros, because most people we hadn’t worked together yet, and I
think you made the comment of, oh, it’s well, if any of the people on
the team really wanted to, they could just make the whole thing
themselves.
And I would have actually loved to see a parallel universe where we all
separately would have tried to make a malleable recipe app, cause I’m
sure it would have been very, very different than what we ended up
coming up with.
But this idea that you don’t have to spend any time explaining basics
and can just go into building right away is really important when you
only have 10 weeks or so. And I mean, I loved working on this team,
maybe my favorite team working experience I’ve ever had.
00:53:00 - Speaker 2: Wow. Now, how did you perceive Max, this kind of
research angle where the end goal is not to ship something to end users,
yeah, you want something usable, and even there’s a demo on the web,
you can go try, but the goal here is not to build a product and iterate
on that and bring it to market. How did that change the experience of
building something for you?
00:53:22 - Speaker 1: It was both very refreshing and at times
frustrating, so it was a little bit of a palette cleanser.
Most of the time when I’m looking at, you know, building software,
it’s like, OK, when do you get to product market fit and what’s the
economic viability? How many users, how are you going to make money,
whatever, right? And this is not the case with research projects. There,
I think the goals are much more, can you find a novel take that maybe
explicitly wouldn’t work.
In the app store right away, because, well, either the tech’s not there
yet, or you need to commit access to Mac OS and iOS to actually fix this
thing, or Linux or whatever.
And so I didn’t really have any notion of what it was gonna be like.
The only thing I knew is that all the Ink & Switch essays are badass,
and surely something about the way these projects are run contributes to
it. And I think it’s that weird tension between both, well, we’re
gonna think big and do something that might not be viable right away,
and at the same time we’re gonna ground it in that use case of, in this
case, Jeffrey’s idea of a, well, let’s just make a recipe app. That’s
our use case. How would you make that malleable instead of much more
generic and, you know, inventing something that maybe no one will ever
want to use.
00:54:47 - Speaker 3: Another part of the research first product thing
that I find important is the end goal of this project is kind of idea
transmission, like, we succeed if we change the way people think. And
so, the way you explain the thing and frame it ends up being super
important, which I guess that’s also true of marketing a product or
whatever, but I think it’s just When that’s the main artifact that
you’re going for at the end, it puts a lot of pressure on that angle of
things. So, one process that I think we all agreed was really helpful is
typically on lab projects, every 2 weeks, there’s a demo day, basically
where you just demo what you’ve been working on to other people in the
lab, and I think it’s really important to take those opportunities to
sort of practice the story and try to explain what the heck are we
doing, what problem are we thinking about, what’s our prototype right
now. And just rehearse that every 2 weeks. And if you can’t convince
other people at the lab that this thing makes sense or is good, you’re
never gonna succeed at convincing anyone else, right? This is like the
most high context, sympathetic audience you could find. And we did have
a couple demos where people were like, what are you doing? This doesn’t
really make sense, we don’t get it. And that was really, really helpful
for kind of refining both the way we explain what we’re doing, but
also, you know, obviously the work itself and sort of guiding the
direction of it.
And I think that’s an interesting process question is like, what
cadence do you work on? In some ways, 2 week cycles may seem pretty
fast. A lot of researchers work on much slower sort of base cadences,
but I find that I really like having an intense kind of pretty fast
rhythm when you’re in this execution, or kind of intense momentum mode,
and then Once you’ve finished this 12 week period, you can spend some
time to like, walk around and think about what you’ve done, and think
about what you wanna do next, and, you know, have a sort of on-off
approach.
00:56:44 - Speaker 1: That tension or the 10 weeks, Jeffrey and I have
definitely had some conversations about, is that too short? Is it too
long for a research project and sort of, I think my view initially was.
It’s like, 0, 10 weeks is too short to do any meaningful research, and
I think that’s still true, except that you shouldn’t consider those 10
to 12 weeks as the entire research.
It’s a season in an 11 season lost sort of show, right? And there’s
this thread across all I can switch projects and Potluck will infuse
other projects going forward, and I think if you bring that mindset,
then suddenly the 10 weeks are really great because it’s this forcing
function of just not wasting 2 years trying to see if there’s a there
there. You have 10 weeks, go ship something, publish it, and have it
torn to pieces because it’s not good enough, right? And if you’re not
embarrassed, you’re shipping too late. I am definitely embarrassed by
some of the UI and the UX and the Maybe complexity that exists and it’s
not a product, but the idea that it kickstars, you know, a couple of
other seasons of development, I think is a good framing, and in that
case, the 10 weeks, the intensity, daily stand ups. I was only on it
halftime, everybody else, which I do not recommend, everybody else was
on it sort of full time, and the intensity is truly what leads to this
pressure cooker environment of like building something that’s both good
enough that you want to play with it. But not a thing that is ready for
any kind of adoption by people outside of the lab environment.
00:58:24 - Speaker 2: I’m curious about the transition from that, yeah,
10 to 12 week more intense building phase to, OK, now let’s take what
we’ve learned and turn that into a written artifact or it could be
sometimes a talk, but in this case it was an essay. I guess some of the
question is, is all the team involved with the essay or just the
writing? How do you know when you actually have something good to write
about? You’ve learned something useful, which maybe could happen
halfway through that 10 or 12 weeks, or maybe you get to the end and
actually don’t feel like you have a lot to say. How does that whole
transition work?
00:59:00 - Speaker 3: I love the writing phase because it’s where you
get to figure out what you’ve done, and I think it’s really funny.
This is such a cliche, but like, you start writing and it’s like, wait,
what do I want to say? And it can get really confusing, and I think in
some sense, even once you’ve done all the work, you haven’t actually
done the work yet of figuring out what you’ve learned from it.
And so, on this project, what we did is we tried as we were going to
Prototype the paper, kind of. We, you know, recorded little talks
explaining the project or like, wrote notes of, like, here’s how I
would explain it today.
But even then, when we got to, you know, the end of this intense period,
there was still a lot of mess to work through, and we’ve all been
involved in co-writing the piece, and I think that’s sort of important
to the extent that, again, the real value that this thing is trying to
provide to the world is like, here is what we learned, and the writing
process is where that gets clarified, you know.
00:59:53 - Speaker 2: Do you find you wanna go back and make changes to
the software as a result of things you’re writing, or especially
screenshots or videos you’re including?
01:00:02 - Speaker 1: Yeah, when I read the essay now, I’m like, OK,
obviously an exaggeration, but this is all wrong. We have to start
again.
This is how we would design it, and it’s really not that it’s all
wrong. It’s just that you want to do so much more to it, right? Like
now is the time where you would simplify and so on, and the writing is
the clarifying piece for me, the seeing what findings we actually think
we found. Even if you set the essay aside for a couple of weeks and then
look at it again, it’s like, do I still agree with this? Is this still
a sort of meat and a finding that’s worth publishing, or was it
incidental? But yeah, for the most part I have the feeling of great,
this is potluck one. Let’s get both a sledgehammer and like a scalpel
and figure out which parts need to be reworked. Less so in the essay
itself, more so in the experience, so that the findings just shine
through the experience very clearly, which is obviously a form of
iteration, right?
01:01:03 - Speaker 2: I think this projects that end, you cut it off and
you have the space and time to not only think about it, but then try to
write it down, indeed may spend as much or even more time in terms of
calendar time writing as you did building. is something that is unique
to research, yeah, when you’re building in the commercial world,
whether it’s a small business or a startup, either way you have the
kind of time is money pressure, you gotta keep shipping, fix those bugs,
satisfy those customers with the features they’re asking for, which is
well and good and as it should be, but often it doesn’t give you that
time for reflection.
And by drawing that really hard line, you have the chance to learn, and
then in that next iteration, it can be not just the scalpel, but the
sledgehammer something very different, even discontinuously different in
a way that maybe it wouldn’t be with a product.
01:01:57 - Speaker 1: Yeah, I think you could maybe fake this for a
product as well, in the sense that everybody or a lot of people are
familiar with the one pager idea of look, we’re gonna write the one
pager of what this product’s gonna be, and you include all the hopes
and dreams and all this stuff that you may or may not do, and then you
actually go work on the thing, and after like 3 or 4 weeks, you’re
like, OK, this has diverged from the one pager.
Go rewrite it or perhaps write the announcement blog post of the thing.
And sure, you could write the announcement blog post of the thing from
day one, but I actually think the refining and constantly evaluating, is
that actually the thing that’s core to this idea, or is it something
else? You could bring that same kind of mindset into a product
development process, I think, especially for less, oh we’re making
version 27 of something and more 0 to 1, maybe 0 to 2 kind of
environments.
01:02:52 - Speaker 3: This is one of the reasons that I love reading
good academic papers. Not all academic papers are good, but the good
ones are really, really good, and I think it’s because, if you think
about how much time has gone in per word in that document, you know,
it’s very possible that a team of 20 people spent years working on
something.
And then obsessed over how should we explain this, what order do we
bring things in, one of the best examples, and it’s just like the
opposite of a tweet, you know, it’s like, how much effort can you put
into explaining something well, it’s really rewarding to read things
like that when you can tell someone put in that much effort to the
writing.
So, I also find it fulfilling on the other side of trying to aspire to
write stuff like that.
01:03:36 - Speaker 1: To bring it back to cooking, and Jeffrey’s latest
obsession, it’s like making stock, right? You just keep working at it
until it’s reduced and all the flavor is in there, and I think that
sort of writing process was incredible here for me, at least, cause
it’s the first time that I’ve even just adjacently participated in
writing a paper.
01:03:56 - Speaker 2: Thinking about what it would be like to take this
project and turn it into an app that you could use that kind of fits in
with your operating system.
Max, you made the point earlier that you would need to commit access to
Mac OS, iOS, essentially the computing platforms that we use to bring it
in the way that you’re really envisioning it.
And I think more broadly than that practicality of you want to modify
the operating system, it’s really a rethinking of how the pieces of our
computing world fit together. So again, it’s much easier to create a
piece of software if it fits cleanly into a box. Here’s a website,
here’s an app on the App Store, but here when it cuts across those
layers or recombines them in a new way, and that’s part of what makes
it exciting, but also makes it very hard. To go from this, let’s say
idea space slash hypothetical embodied in a prototype to something
that’s in the real world. What are the implications? Where could we go
if we were inspired and excited by this vision for computing?
01:04:55 - Speaker 1: I think the notion of unbundling the app is really
interesting to me. This idea that you have your home screen and we have
these little squares, and those squares are quite literally fused
together behavior plus data and getting data from one square to another
is sort of this orifice of the share sheet is just not good enough, I
think, and If you want to unbundle the app, then you have to sort of
make the data substrate. In our case it was, you know, plain text, much
more shareable between, let’s call them apps for a second, but at that
point the apps are really just views with a specific emphasis on what
you’re trying to accomplish, right? Like, is it more image focused, is
it more text focused, is it video focused or whatever, and they all
operate on the same data substrate.
Therefore, each of the apps sort of lose importance and the unbundling
is more about the interop between them. And I think it’s likely that
we’re already seeing the beginnings of it.
Like I think if you do look at even though we don’t have commit bit to
iOS and Mac OS and so on, you see this sort of like widgets and all
these things that are just taking specific views for A set of data and
putting it on your home screen or on your lock screen or whatever. And
that’s the notion of just breaking it up, putting it on the device
that’s most useful, maybe it’s your watch, maybe it’s your phone,
maybe it’s your computer, and optimizing for that use case, but the
data lives sort of in this bucket.
Now, if we just said, hey, let’s break that up, and the data doesn’t
live in the app bucket anymore, it lives on this magic data substrate.
Suddenly you get an experience that is much more like we are used to
with working with plain text and notes, right? Like if you told a
developer, you have to use this editor that we’ve blessed, you’d be
like, no, I want to use a different app and you can because it’s just
plain text, right? And you can use anything from them to X code to
Visual Studio code. The same can be done for other types of applications
if that shared substrate is sort of more powerful than maybe just dumb
files on a disk.
01:07:10 - Speaker 2: Who or how do we create this one magic data layer
to rule them all.
01:07:16 - Speaker 3: If any of us knew the answer to that, we’d be
billionaires already. Well, so one possibility around that that I find
exciting is, as you know, Adam, I can Switch has done a lot of work
around local first software, which is a research theme that I see very
deeply entwined with that thing Max was just talking about.
The local first cross tool file system, I think, is a thing that needs
to exist.
And so, I’m kind of curious to see how That research that the lab has
been doing for a while, starts to entangle with these ideas from
potluck, as well as even, you know, the lab’s also been doing work for
a while on thinking with ink and tablets, right? And we’ve actually
been noticing recently that some of the ideas from potluck seem to be
related to that work as well.
There’s a shared theme of working in the way that feels natural to you
in a very messy, sketchy way, but still being able to bring in
computation when you want it. And so, I’m excited to, you know, see
going forward how those different threads of work can kind of combine
with each other, and maybe someday we’ll figure out how or who is going
to build this better computing platform that we all want.
01:08:26 - Speaker 1: I’ll plug Jeffrey’s I can switch essay, Cambria,
which talks about this notion of bidirectional lenses on data so that
you have interop between two things that may interpret that data
somewhat differently, and the surge of AI and ML actually gives me hope
that we can Not necessarily at that level, but at the human level, make
the interop between different pieces of data much more fluid, right?
Like the idea that today you have to reason as a computer user that a
PDF is fundamentally a different thing than a JPEG or a screenshot is
very unreasonable if you think about it, right? That’s just, I think
Jeffrey likes to call it programmer bullshit. I’m not sure if we’re
allowed to swear on the podcast, but AI makes the input and the output
much more lossy, right? It’s like, oh yeah, just interpret my
screenshot. It’s text, why can’t I copy and paste it? And so I think
that plus some advances in sort of the CRDT space and actually gives me
hope that we could achieve something that is much more of a Less
understanding what a signed integer is and more, hey, look, I have a
number, go figure it out, computer, that’s what you’re there for.
So, I don’t know, the future seems bright.
01:09:46 - 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. And Max Jeffrey, thank you for stretching
our imaginations for what we can do with dynamic documents and text and
end user programming and well, I’m looking forward to that next
generation computing platform.
01:10:10 - Speaker 3: Thanks so much. This was fun.
01:10:12 - Speaker 1: Thanks for having us.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: I remember the last time we did a paid upgrade, we
had a feature done for almost a year before we actually shipped it
because we knew it’s such a huge feature that will bring in new
customers and make it easier for them to understand why they have to pay
again. 2.5 years ago, we switched to a subscription-based business
model. And this is also switching company development culture that you
suddenly have to ship updates or features more often.
00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac. But this podcast isn’t about Muse product,
it’s about the small team and the big ideas behind it. I’m Adam
Wiggins here with my colleague Adam Wulf. Hey, everyone. And joined
today by Marcus Mueller Sihoffer of Mind Node.
00:00:50 - Speaker 1: Hello, thanks for having me on the podcast and
greetings from Vienna Austria.
00:00:54 - Speaker 2: Yeah, and you’re in Vienna, and this is a city
that’s known for, let’s say it’s classical music history. Mozart is a
certainly a name that springs to mind. Is that something you ever took
advantage of?
00:01:05 - Speaker 1: Oh yeah, when I was still a student, I really like
to go to the opera, of course they had those really cheap standing room
tickets back then. I think they still have it, sorry, but nowadays,
yeah, I have kids now and well the business, so I hardly ever find time
for that, unfortunately.
00:01:22 - Speaker 2: Well, Wulfstaller is about to head off to
university, so that’s gonna be lots of room in your life for opera
after that, huh?
00:01:29 - Speaker 3: Yeah, that’s right. I just need to make the 1.5
hour trip downtown to go see it. So that’s my other thorn in my side.
00:01:39 - Speaker 2: Well, before we dive in here, just a quick
housekeeping announcement.
The Muse team, together with a friend of ours named Arun, have put
together a little website. It’s at infinite canvas.tools, and I’d like
you all to check it out. The idea here is to kind of give some
definition to this category.
We talked with Steve of TL Draw a few episodes back about Infinite
canvases and I guess we were inspired enough by that. We felt like that
a standalone site that helped define the category better would be
worthwhile to all of us.
And indeed, Marcus, this is an interesting tie in with your history a
little bit, which is, I believe you worked on a project of that exact
name some years ago.
00:02:18 - Speaker 1: Yeah, that’s right. Back when I was still at
university, I did a student project.
And later on, it’s also turned into my final thesis, in fact, where I
created an app that was called Infinite Canos and it was highly inspired
by a comic book or graphical novel by Scott McCloud.
Scott did two interesting books about comics. One more general book
describing what comics are. And a second book describing how he would
reinvent comics for the new digital age.
The book was also called Reinventing Comics.
And in one of the later chapters, he described the concept of infinite
canvas as a tool or method to bring graphic novels to the digital space,
in fact.
And as part of my studies, I created an app that allowed you to put
graphics on an infinite canvas more or less.
And then put a navigation area on top of that.
So that allowed comic artists to create interactive comics that they
could lay out and then present in a that place to to their readers.
And unless other kind of student project, this project actually found
some comic artists who created their own comics and their own graphic
novels of that it was kind of cool.
00:03:39 - Speaker 3: That’s really interesting, so it’s not just an
infinite canvas, which I think of as A very general just giant space,
but there’s a specific navigation format or navigation structure that
was built into it as well. Am I understanding that right?
00:03:54 - Speaker 1: Yeah, when we considered that at first, what we
wanted to do, we had concerns that if you just provided an infinite
comes to the readers that they would have problems navigating these
cameras.
And so we came up with navigation layer on top of that that allowed to
predefine a certain path you could take around this canvas. And you have
to compare it to a typical comic, which is laid out on a piece of paper,
and then if you bring that to the infinite canvas or to a canvas that’s
infinite, you can lay out the panels all over the place you would like
to do.
For example, there were comics that were just side scrollers or comics
that took in all different directions.
Unfortunately, many of those projects are no longer around because back
then I used a chalet for the viewer part and Chalet is more or less
separateated and. And later ported it to Adobe Flash and that’s also
unfortunately not really available.
00:04:49 - Speaker 3: It’s the never ending story of technology, I
think.
00:04:53 - Speaker 1: Oh, that’s true, yeah. But if you like, you can
still go to infinite canvas.com and see how the app actually looked
like, but I fear most of the projects are probably no longer available.
00:05:04 - Speaker 2: Marcus here, the CEO and founder of Mind Node,
which I think of as the quintessential or most canonical mind mapping
app. It’s been app of the day, it’s been around the app store for a
pretty long while. I think of it as a well respected tool for thought
from before that term was sort of popular or experienced the modern
resurgence that it has. But before we get to talking about my Node, I’d
love to hear a little bit more about your history, maybe what happened
in between the time of that student project and thinking about comic
infinite canvases and the creation of the business you’re working on
today.
00:05:41 - Speaker 1: Yeah, let me go a little bit further down my
history. I have a major in computer science, and back then the computer
science curriculum was very, very general in Vienna.
There we had many courses in mathematics, computer algorithms, computer
graphics and stuff like that. And going into the study, I was never
really sure what I really want to do.
My vision was, oh, I just wanted to do something with computers because
I like games, so computers are the things I wanted to do.
And having this exposure to all those different parts of computer
science allowed me also to experience human interaction design. And this
is something I was never really interested in before, but throughout my
studies, I kind of always had those intersections with that.
And I also had, what’s kind of interesting, I had a course on next
step. Which kind of showed me a new way to use a computer, which was
kind of different from the Windows side, I only knew. So with the
exposure of having experienced the next step computer and then also my
the growing interest in human interaction, I started considering getting
a Mac, and this was the time when Steve Jobs announced the iMac G4,
which was this kind of cool looking computer that looked like a stand,
which I have still somewhere in my office.
00:07:01 - Speaker 2: Is that the cube?
00:07:03 - Speaker 1: No, the tube was before that, that was the T4
tube. It was the 2nd generation iMac, that’s where you had this kind of
round stand and then you had the flat panel the hinges come out of that.
00:07:15 - Speaker 3: Oh, that’s right. Yeah, that was a beautiful
machine.
00:07:17 - Speaker 1: Oh yeah, it kind of looks very similar, or at
least the hinges look very similar to the studio display if you get the
one with the moving, where you can move the display up and down. So
yeah, back then I really had nobody around me that used the Mac, so it
was kind of jumping into cold waters.
But if you think about decisions you made in your lifetime, that was
definitely one of the better decisions I made and it was just one of
those feelings that I follow that, wow, that’s probably. Yeah, that’s
just a feeling in there, but if I do that, it feels great.
And this is when I kind of left the Apple platforms. This was also the
time where the iLife apps were really popular.
If you think of iTunes, iMovie, IDVD and IAB, for example, they were
great focused apps that did one job really well, and for the, they were
designed for this one use case. And this was kind of influential on me.
And then there was a second part, it was very influential, and that was
the upcoming of ID Mac developers. If you think back, there was
delicious library or Net Newswire. So, after I wasn’t really sure what
I wanted to continue to do, but having those people show what is
possible, creating your own small Mac software studio, that’s kind of
something that really inspired me to try to do the same thing.
00:08:40 - Speaker 2: So the MMA G4 was introduced, what year do you
remember?
00:08:44 - Speaker 1: 20 years ago.
00:08:45 - Speaker 3: Wow, that long, yeah.
00:08:46 - Speaker 2: And then how long between sort of that device,
seeing these indie apps, falling in love with the Apple platform, and
the founding of what would be the company that would make my Node.
00:08:58 - Speaker 1: I wrote the first one of mine to note in 2007, so
it’s now 15 years since I started the project.
00:09:07 - Speaker 2: Wow. And, yeah, give us the elevator pitch. What
is my note? I’ve already perhaps tipped it off a little bit, talking
about mind mapping.
00:09:16 - Speaker 1: The awesome thing about MO is that I didn’t
create the app because I thought, oh, cool, mind mapping app would be a
good idea, but I was kind of stuck in the infinite chemist project we
talked earlier because I had this big picture of few idea that, OK, I
have this app.
It’s kind of popular in this niche area.
But let’s try to bring this to a more. Broader audience.
Just imagine having an infinite canvas where you can show your
presentation, that’s something that’s was unique at the time and I
thought, oh, that could have potential, but as it’s always with great
ideas, you have too many of those and you don’t have a clear vision on
what you really want to do in the end.
So after coding for a while, designing for a while, I was kind of bummed
out. And looked into techniques that would allow me to bring back this
focus, bring back or allow me to really discover what I really wanted to
do. Did a little bit of research and discovered mind mapping and well,
I’m a computer engineer. I like coding. So the first thing you do when
you come across a new concept, you want to do it yourself. So I want
really great apps back then, mostly ports from Windows, I decided, oh,
let’s look what Apple is doing with the I work apps, what all these
other indie developers do. Just try to do a tool that does one job
really good. And I started a prototyping phase. I decided, OK, let’s
try it for one month, see how it turns out, and then I can still decide
if I want to go back. To infinite canvas or if I want to resume it I
know.
00:10:51 - Speaker 3: It’s really interesting. I feel like that’s
where Almost all good products have that same kind of a route, where
they’re solving a very specific problem. It’s not just building neat
software, but you are building neat software to actually help you think
better, to help you do something better. It had a very specific purpose
for you. Sounds like that gave a lot of Vision and direction for you
early on.
00:11:15 - Speaker 1: Yeah, I always feel that the best features in Myno
or and other apps are the features that the developer itself uses. So if
you develop a feature just because a customer wants to use that, you
will never create a great feature, you will create a decent feature. But
if you really are the user and the customer of the app, then you really
are behind the feature. You understand how the feature works. You just
don’t have some description of how the feature should look. Or behave,
you actually lift the feature, you know all the ins and outs, you really
know in what edge cases you can run and and those are often the features
that turn out really great and awesome.
00:11:59 - Speaker 2: And originally this would have been for Mac
because the iPad didn’t exist. Am I right about that?
00:12:05 - Speaker 1: Yeah, I think the iPhone might have been announced
by the time I started creating my Node, but I think that was way before
the SDK. So I started initially on the Mac. This is also where I had the
most experience. And even after SKN was announced, it was kind of, ah, I
did some experiments, but it was kind of hard to create something with
an expanding or infinite canvas to the iPhone because the API wasn’t
really designed that way. So I started with doing. The Mac version first
and then later try to bring that to the iPhone platform and then also to
the iPad.
00:12:41 - Speaker 2: And I first saw it on iPad, and I think this was
circa would have been more like 2017 or something when we were doing
tablet research back at in and Switch, but one of the things I was
struck by was how just beautiful and good the iPad hardware was,
particularly when paired with the pencil, which was relatively new at
the time, and I went looking for really good quality iPad apps, and I
was just shocked how few of them there were.
So many were just iPhone ports, in many cases they were scaled up or,
you know, just like in a letterbox thing.
And so, from my perspective, it felt like an app that just could have
been born on the iPad, it was made for iPad, but maybe that also to me
is the connection in my mind between a tablet is such a great device for
open-ended ideation, which indeed is what mind mapping is.
You can sit back on your sofa, you can take it to the coffee shop,
something like that. So it’s interesting to hear that that was a very
latecomer to this product.
00:13:42 - Speaker 1: So when we decided to do the iPad app, it was just
a 1 to 1 part of the iPhone app. We actually, when we released our iPad
app, I still had no access to a real iPad back in the days because they
were only released in the US and not. In Austria, even had one of our
customers send me one of the first iPads so I could actually try and use
the app on the iPad.
But you always have to keep in mind an iPad app also has to be a good
iPhone app because you can always resize the app itself to be as small
as an iPhone on an iPhone device. So that’s all I think the real big.
Challenge of doing a great app for all free Apple platforms or major
Apple platforms that you always have to keep in mind the app could be
launched or could be a size like an iPhone, an iPad, and a Mac. And I
think iPad and Mac are starting to converge a little bit, especially now
with iPad S16, but you still have to keep those tiny iPhone screen in
mind.
00:14:42 - Speaker 3: I’m really curious to hear how difficult it was
to make that jump to iPhone, and then eventually to iPad, cause as I
recall, the Mac APIs kind of in the late 2000s versus the iOS SDK were
pretty dramatically different, and then they’ve kind of congealed
lately and merged together in a lot of ways, but at the time, Pretty
separate. Is that just a huge effort and what were some of the risks or
thoughts in your mind as you Expanded into new devices.
00:15:15 - Speaker 1: Creating the first iPhone version had several
challenges looking back. Definitely very restrictive hardware and uh a
really a huge problem of fitting everything into memory and the app
getting killed if you use too much memory was always a kind of an issue,
especially if you look at the technical side, we tried to use internal
layers back in the time. And those had really issues with fitting in a
memory and if you imagine how a very graphic intensive apps like my not
has to do it, we have to use very large layers to draw all of our
branches. So that was a really challenge.
Another challenge was actually text because back then, the iPhone only
had simple text, so there were attributed strings are similar. So then
we ported my the iPhone, we actually had to define a new and custom file
format that didn’t use our extensive use of attributed strings and had
to tone down the file format a little bit.
And the first problem, what was really a problem was getting the data
from the Mac to the iPhone. Back then, Apple still used iTunes to sync
everything over. And that wasn’t really a good way uh to transfer
files. So we had our own app socket kind of ad hoc connection between
the iPhone and the iPad, which was kind of like it didn’t really
support things so you had to transfer the document over. And in this
process, the file was converted to a minor version of the file for much
more or less. And then customers had to move it back to the iPhone or
the iPad.
It’s got a lot easier when Apple introduced the iCloud, but that was, I
can’t remember when this was announced I think in the 2nd year or 3rd
year of the iPad or.
00:17:02 - Speaker 2: Yeah, that’s really interesting that you’ve
weathered all of these changes, both introduction and new hardware, new
APIs, yeah, even it almost like, I can’t even remember it in some ways,
I’ve maybe I purged the memories from my mind, but yeah, this tethering
your phone to your computer was a thing you needed to do for all kinds
of stuff that was just part of daily life, and it wasn’t even that long
ago, it was like 10 years ago. But now the over the air stuff and the
sync via the internet and so on, it’s just what we expect and we’ve
grown used to.
00:17:35 - Speaker 3: One of my favorite things to forget is the
hardware limitations of those very early phones and iPads. It’s just
amazing that anything was ever written for them in some ways. I think
the first iPad had enough memory for like Basically 4 uncompressed
screenshots before you got killed, or just something ridiculous in terms
of the lack of memory that your application could use before it got the
hammer.
00:18:03 - Speaker 1: I think in the initial iPhone version of Minor you
could only create 90 nodes or so before the app was killed by the system
because it took too much memory pressure.
00:18:14 - Speaker 3: What’s that quote? 32 kilobytes is enough of
memory for anyone. There’s some famous quote that I’m forgetting.
00:18:22 - Speaker 2: I feel like it was 640K is enough for anyone
attributed to Bill Gates, but that may also be a misattribution, but
yeah, for sure it’s. Go back and look at what kinds of limitations, you
know, you look at the hardware for 80s arcade games, for example, and
it’s just, it’s really marveling how little resources they were able
to do pretty comprehensive pieces of software and.
00:18:49 - Speaker 1: But I have to say it wasn’t all bad for us
because in the end, we really had to do a very performant iPhone
version, which was very optimized for the memory pressures and the
performance of the chips back then. And we later ported the core of this
back to the Mac and this really brought us a lot of improvements for the
Mac version. So it’s not all bad if you look back.
00:19:12 - Speaker 2: So fast forwarding to today, and I know it seems
to be this pretty successful app on the App Store, and indeed you are
not only one of these indie Mac developers that you were inspired by,
but indeed you have a whole indie company that is behind it. So tell us
a little about that. How many people are on your team and how do you all
work?
00:19:31 - Speaker 1: I currently have 8 employees and 4 freelancers on
the team, and I grew the company really, really slowly in the last
couple of years. I probably added on a new employee a year or so, so we
only saw a very slow growth and that’s kind of also what helped me a
lot to learn on the go how to actually run a company because coming from
an engineering background. I never really learned how to manage people,
grow a company, do all the business stuff. So having a company that
slowly grow every year, always a little bit, that really helped me to
better serve the role of the developer and the role of actually running
the business.
00:20:14 - Speaker 2: What’s your split these days? Do you have uh much
coding on the core app at all? Have you become a pure manager as a
result of your team?
00:20:24 - Speaker 1: I think none of my code actually goes into the
shipping version nowadays, and this was really, really, really hard to
letting go of that.
So if you talk about my earliest team members, they will tell you that I
always looked over their shoulders and reviewed every line of code they
committed on GitHub and So, uh, it was a really hard time letting go of
the code, but nowadays, um, my focus has shifted.
So what I do from time to time is write some prototypes, prototype one
feature or I even have several features that are called Marcus features
that are in the app that nobody else uses, but only I. But otherwise, I
try to keep up with all the technologies, so I try to learn SwiftDI and
I also, you know, have vapor back and vapor is a service that Swift a
framework which we use for business intelligence software and I try to
use my coding for those non-critical areas nowadays.
00:21:23 - Speaker 2: I think that’s a good approach. It reminds me of
the old ransom repose blog. I’ll have to dig up a link or something,
but he is speaking about kind of the transition to engineering
management and basically frames it as, once you move into this kind of
management or leadership, you should not code. And also you have to
code. And the way he resolves that is actually kind of what you
described there, which is if you don’t code, you lose touch with the
technology, you can’t command the respect of engineers, you can’t
really make good decisions and understand what’s happening because
you’re just out of touch. But on the other hand, owning stuff that goes
into production when you have a bigger duty, a bigger responsibility to
the people and the company. is actually sort of irresponsible from the
perspective of you’re taking on too many conflicting responsibilities
and so in that sense, yeah, prototyping or a little bit of pair
programming or helping write some tests or that sort of thing is a good
way to stay in touch, but also not be in a position where you are the
person who is really bearing the responsibility for something that
customers are depending on. So our topic today is the business of apps,
and of course app is short for application and really refers to any kind
of piece of user facing software. Certainly there are web apps and that
has their own set of business dynamics, B2BASS, and so forth. But today
we’re really talking about selling apps through an app store, and
particularly while there are many app stores in the world now, the
granddaddy of all of them, and still the biggest and most important and
the best place to build a business is the Apple App Store in Marcushia.
Wonderful person to speak about that, having over a decade of experience
of selling through that. Adam Wulf, I know your time and your various
entrepreneurial ventures, as well as other apps you’ve worked on, like
Fantastical, you’ve had plenty of contact with that. I’m a relative
newcomer here, having gotten into it just for the muse venture, so I’ll
probably have less to say, but I’m looking forward to listening to the
experienced voices we brought to the table here. So maybe as a starting
place, we could talk about just what is the app store? What do you get
from a business perspective when you put things there and what are your
options about how to make money.
00:23:42 - Speaker 1: When I started selling my No, I actually started
selling it through our website.
So the app store only came later. So I remember that before the app
store, you really had to think about how do you protect my app from
piracy, how do I create a license codes, how do I invoice people?
Initially, I tried to do it myself, but very quickly switched to an app
service that was called K Kai. And uh I also learned that some license
codes that are too long are also not really good, so I had a lot of
learning effects back then.
So the app store definitely takes away all this burden of having to
think about how you protect your app and how you unlock certain features
of the app. If you stay with a very basic app store or business model,
so if you go with a paid upfront app, you basically don’t have to do
anything to sell your app on the store. Apple takes care of everything.
00:24:42 - Speaker 3: I think one of the other really important things
is just the huge customer base that Apple brings to the table as well,
that getting shelf space in Almart is very difficult, but they have lots
of traffic, but getting shelf space on the app store is very easy, and
they have lots of traffic.
And so just having that immediate visibility can be a really important
first step as well.
I think that’s what’s particularly impressive about especially the
early apps and early Mac apps, was the Mac App Store didn’t show up
until significantly later compared to the iOS app store, and so you had
to build that customer base on your own from your own website. What were
some of the things that you did to bring in those initial customers?
00:25:32 - Speaker 1: What I initially did was post the app on certain
forums, for example, on developer forums where I had my initial beta
version.
And we ask those developers there to provide me feedback on that.
And also very helpful back then was a site on Apple.com/ downloads where
they promoted first party software and I had the luck that Apple already
promoted our first free version, which we later turned into a premium
version half a year later or so. And this premium version was again
featured by Apple on this website, so this definitely helped a lot. What
we also did was send out press releases, contact press directly, but
it’s very different, especially in the beginning of the app store where
there weren’t a lot of apps available on the app store, so basically
every new app received the full attention of the press and the customer.
00:26:24 - Speaker 2: Yeah, it’s certainly a very different story today
that where the huge, huge number of apps means that you really do have
to do something to stand out.
Certainly Apple does do a certain degree of curating their winners,
featuring apps and editor’s choice and app of the day and things like
that.
He’s been lucky enough to be the recipient of some of those.
I get the feeling that my note is a perpetual favorite, so I’m guessing
that helps a lot with getting you surfaced, and then once you’re in the
productivity charts. I just took a peek and see you’re pretty high up
on the productivity charts, and then people go and just kind of scroll
through that, and probably it’s more likely to pop up when you search
for mind mapping than anything else.
So, all of those combination of things means that it’s a distribution
channel, that is to say that shelf at Walmart, you mentioned there,
Wulf, the virtual shelf, in this case, the app store can be very, very
good if you can do a good job of playing the game.
00:27:18 - Speaker 1: Yeah, I think nowadays just releasing the app on
the app store is not enough.
But if you try to find a connection with Apple, try to find somebody
inside Apple who can pitch it. This is exceptionally helpful.
So I always recommend contact the evangelists, contact your local app
store managers, let them know what you’re doing. And I think in our
case, it really helped a lot that we always try to feature that Apple
was very interested at the moment.
For example, when we first started, Quick look was very new and we had a
Quick look extension right away and we continued this trend with one of
the first company who supported iCloud and We try to always be there
when Apple announces a new technology. For example, we try to have a
really good support for stage manager this year on iPad OS, and this
really helps if you try to communicate with Apple, you show them what
you’re doing, and if you’re doing something that makes Apple and the
platform stand out, then this is a good reason for Apple to feature you
and list you in all those categories they have.
00:28:23 - Speaker 2: Yeah, that’s a great point.
We’ve, well, I would say we’ve experienced that mostly in the sense
that we speak to our contact at Apple and they basically say which of
these new APIs are you supporting and more often than not, the vast
majority of them are things that just don’t really make sense for the
type of app we have and or don’t match up super well with the roadmap
of things we think our customers want, but on a few occasions we have
tried to hook in with those things in a timely fashion, and then that
potentially puts you in a position to be part of their story, part of
their launch story, and that’s the cycle, I think, for a platform. A
platform is as good as its developers, if a platform is exciting new
features built into it, but there’s no apps that exercise them, then
people aren’t gonna care.
This actually is a trick. Now I’m almost diverting back into our recent
episode.
On platforms here, but I feel Nintendo has done a very good job with
this where they always have their first party apps like Mario and Zelda
and so on, and these will be the ones that often showcase the brand new
motion control or whatever the new gadget or gimme or API is that
they’re putting in their platform, they could count on these first
party apps to use those really well and show them really well, but I
think Apple obviously does. do a bit of that, but I think they’ve also
been very good at engaging their developers on those new features, and
it’s precisely that, that’s kind of the bargain, which is if you can
show up with a good implementation of something related to the new
platform feature, then not the promise, but the possibility there is
that then you’ll make it into their marketing materials about that, and
obviously they are a very, very powerful marketing machine.
00:30:03 - Speaker 1: That’s true. If we look at our funnel, we always
see that the App Store is really the strongest part of that, and even
App Store search is a huge part of bringing customers to our App Store
page. So whatever we try outside the App Store, nothing comes close to
what the app store itself can offer to a developer.
00:30:23 - Speaker 2: Now when it comes to the payment side, you talked
about the challenge of setting up your own payphone infrastructure and
license keys and so on, and there’s certainly a fair bit of complexity
to set that up and implement it well using store kit in your app, but as
you said, so much is handled, currency conversions and you don’t need
to really deal much with even certain kinds of customer service things.
They’re sort of a go-between for basically everything payment related.
But that also does mean you need to use one of their payment options,
one of their models, let’s say payment models.
I think you’ve been around that you’ve seen the full evolution.
You mentioned starting with the free app. Tell me how that went, you
know, in those early days, you could pay, but it was kind of a one-time
upfront fee. I believe nowadays you’re on a subscription. What are all
the different options there and what’s been your journey going through
all those?
00:31:18 - Speaker 1: So we basically started with the free app through
our website, but when we launched on the App Store, we had actually 3
different versions on the different app stores.
On the Mac App Store launch, we had a free version and the paid version
because there weren’t really a possibility to have trials. So customers
wanted to use the, or try the version for the purchase. And this was a
real problem, or is it still a real problem if you want to follow the
paid up front. Purchase model.
And there is a second really big advantage in my opinion, if you choose
the paid upfront version that you can’t ask for a paid upgrades. So if
you want to ship a paid upgrades after 2 or 3 years, you don’t have a
lot of options.
You can still probably choose. An option where you have an inner
purchase for the existing app or you can switch to a new entry in the
app store, a new SQU, but uh if you really do the switch, you lose a lot
of listings and Ato categories.
And the worst thing is, and we, we tried it, so we have experience of
that customers no longer find the old app. So they think, oh, you
removed the old app and I can no longer install it. You just have this
new app and I have to pay again and this kind of triggers a lot of Not
so nice to read customer feedbacks on the app store itself and also in
our support inbox.
00:32:38 - Speaker 2: Yeah, I feel like payment is one of the things
that’s most likely to be a really emotional topic. Yeah, you’re
reminding me of, I feel like this was a really common pattern, and I see
it a lot less these days, but you would have sort of a light and a main
version or a main and a pro version.
I think I did this once for just a little side project game thing where
the light version had the first N levels, and they had pretty specific,
you know, rules about you. Upsell too hard, but we would just
essentially say, you know, this is the 1st 10 levels if you want more,
you can get the other one, and then that was free, and then there was a
paid one, I can’t remember it was like $5 or something, and that was
all the levels and that was the solution for that.
And then similarly, the paid upgrades, as you mentioned, I think Things
still does this and does pretty well with That which is they’re on
things 3 or whatever it is, and at some point that was announced and was
a paid upgrade and things too disappeared from the app store and you
have to go through that process. But exactly as you said, there’s all
kinds of ways in which that’s disruptive for your customers and
confusing and way, why do I have to pay again and so on.
Although that actually is just channeling, I think, a very traditional
model for software, Microsoft Office or Photoshop back in the day or
that sort of thing. It was just normal. They would come out with major
new revisions every year or two and then at some point you would need to
be on the latest version, probably just to open files from your
colleagues and or because you want new features and so then you pay
again and I always saw those as being kind of a Basically, a software
subscription, as long as you were using the app, but at least there you
can decide on your own timeline a little bit when to buy the new
version, so there’s pros and cons relative to subscriptions, but the
reality is ongoing software development has to be paid for one way or
another, and paid upgrades are certainly a way to do it, but just not
well supported in the app store.
00:34:38 - Speaker 1: It might sound a little bit strange, but we still
get complaints from customers that our 7 year old version which we
continued 7 years ago, no longer works on Ventura and M1 Max, so, yeah.
00:34:50 - Speaker 3: It’s amazing. I almost feel like the very early
app store. It just encouraged to race to the bottom on pricing, where
apps would go cheaper and cheaper or free just to get those users, and
like you said, it’s the one time purchase and there was no upgrade
path, and so then users got used to, oh, I’m gonna pay 299 for an app I
can use for the next 10 years, perfect, and that’s just not
sustainable, and so then Migrating a 299 purchase from 10 years ago into
a subscription. It’s such a difficult transition for the customer, and
a difficult transition for the developer to Bring those customers in.
Onto the bus and onto the wagon. How did you manage that communication
as you changed your business models and as you increased? There’s
obviously gonna be unhappy people, but did you take any Extra efforts or
extra communication to bring customers with you on that journey, or what
was that like to go from no options to suddenly now we have in-app
purchase and trials and all sorts of things?
00:36:03 - Speaker 1: Yeah, we definitely had our share of trying to
find a good working business model on the App Store coming from a paid
version, then doing another paid version as a paid upgrade kind of where
we just lowered the price a little bit and launch a week or two, then we
try to move to a free app with uh free in a purchase to unlock a trial
version and then in a purchase to unlock the pro features.
And now we only 2.5 years ago, we switched to a subscription-based
business models. And I think a lot of customers don’t want to hear
that, but every change we made, we always had the same amount of
complaints and always people were angry. Either way, we tried it, they
were always angry and I always had a feeling, if I do the subscription
switch now, I can get it behind me and I can no longer have to think
about. This part of running the business again, having to explain why
they have to pay now again. It’s obvious that with the subscription, I
ask them every month or every year that they have to pay again, but
that’s part of the business model and that’s part of what people
understand.
But I think a lot of uh customers or potential customers don’t realize
what a paid upgrade is and this concept never really Came from the Mac,
where it was a very prominent business model to the app store as Apple
also never supported it, and there were always these workarounds.
So for me, one of the more important learnings was every switch is
painful and it’s always hard to communicate it to customers.
But in the end, after having done the subscriptions, which I kind of
feel relieved that this part of running the business behind me. And I
fully understand that a sun switch or subscription is something that can
annoy a lot of customers. I think if an app I daily use suddenly asks me
to have a $10 subscription month for so I’m also feeling angry, to be
honest, as a customer. So we really have to be careful on how you
communicate this and how you transition customers over from the, I call
it legacy old version to the new uh subscription model.
00:38:23 - Speaker 3: Yeah, I think one thing that really stands out to
me is just the risk of the upgrade model versus the risk of the
subscription model for the business, because if you spend a year or a
year and a half building an update, And you have an upgrade model, then
90% of your revenue is gonna come from that update, and you need a giant
slice, a giant pile of money on upgrade day. And if that doesn’t come,
then the past year and a half was a really painful experience.
But then with subscriptions, it suddenly smooths all that out and you
have a much more predictable revenue stream, which then makes new
features and customer support, you know, actually a lot easier because
it’s Just a more consistent and safe developer environment compared to
the risk that was taken on with an upgrade path.
00:39:14 - Speaker 1: I remember the last time we did a paid upgrade, we
had a feature done that the customers really wanted to have, and we had
it done for almost a year before we actually shipped it because we knew
we have to delay this feature for the next paid upgrade because it’s
such a huge feature that will bring in new customers and make it easier
for them to understand why they have to pay again.
But sitting on a feature for such a long time is also kind of
frustrating.
And this is also kind of a a switching company development culture that
you suddenly have to switch over to shipping updates or features more
often and it also allows you to have Incremental feature releases where
you say, oh, let’s try if this feature is something that our user base
is interested in, don’t fully implement it. Try to work with uh MVP
that’s good enough and then later build it out based on customer
feedback.
00:40:10 - Speaker 3: Yeah, I think one thing that gets lost for the
customers they’ll see the, oh, you’re not offering upgrades anymore,
and now it’s a subscription. Oh, I’m never gonna get upgraded software
and I just have to pay you all the time. That stinks. When the reality
is, they’re getting those upgrades so much sooner than they would have
and so much more consistently than they would have. I think the story of
subscriptions is sometimes lost in the trees compared to what it
actually provides for the customer.
00:40:36 - Speaker 1: Yeah, you asked me before about how we communicate
subscriptions or the subscription switch to our customers, and I think
that’s a really hard thing to communicate because you know in advance
that the customers won’t be happy about the switch, because you are
also a customer for other apps and you don’t like that, as I mentioned
before, but you really have to think about how can I make this easier
for the customer? How can I communicate to him that Feature development
or simply adopting the app for a new Apple release simply takes time.
And what we try to do, and I was kind of happy with our end result is we
try to provide existing customers with um basically cheaper version to
upgrade to the subscriptions. We had different trial lengths for the
introductory offer of 6 months or 12 months. Then we shipped a very
large free last free update to our existing customer base who used the
paid upfront version together with the subscription. And we also try to
communicate it very early. So we told them 2 months before, hey, we are
going to switch to subscription. You will get the same features that we
are planning to ship to our new subscription customers at the same time
for this last release. So they had some positive connection with our
switch to subscription because they also got a new feature at the same
time. And I would say it kind of worked but we still, of course, got our
share of not so positive feedback.
00:42:12 - Speaker 3: Yeah, and I think that’s inevitable, but that
empathy for the customer. I think really goes a long way when you, you
know, understand there are people just like us, and have those same
visceral reactions to change, but being able to empathize with them and
understand.
And explain, here’s our motivation, we want to do right by you, here’s
me trying to do right by you, and here’s the new world we’re moving
into.
We would love for you to join us. It’s a very difficult conversation to
have with customers, I think, but when done right and when done with the
right motivation, I think it really does make a difference for the
number of customers that will continue on that journey with you.
00:42:57 - Speaker 2: Now I assume, Marcus, that you’re doing a
freemium model where you can basically try the app initially with some
kind of limits and then choose to sign up for a subscription, is that
right?
00:43:08 - Speaker 1: Yeah, that’s right. What we actually did is we
moved our premium version we had before where we only allowed a few
documents to actually version where you could also make tiny or minor
changes to documents themselves. So when you download the free version
of Minno, you can create new documents, can Add basic content and it
also covers really all your basic brainstorming needs. But we unlock uh
more premium features, for example, our new editable outline behind a
subscription now that we have to plans a monthly and a yearly
subscription.
00:43:46 - Speaker 2: And was the freemium something you experimented
with, because there is the approach and actually someone we worked with
in the past who has some subscription apps told me about a bunch of
pricing experiments he’d done and discovered that for one of his better
selling apps, just putting the paywall literally the moment you run the
app was actually by far the best thing. the moment someone downloads it,
they have their intention for what specific problem the app is going to
solve for them. They’re gonna hit the button.
One thing that’s also good, I guess about the App Store is that
subscriptions are something you can cancel easily through the settings
page and you have confidence in that. And so you just say, yeah, OK, I
want this, I want to try it. So what was your thinking on? Giving those,
yeah, the free capability sounds like somewhat extensive, free
capabilities versus more immediate paywall.
00:44:38 - Speaker 1: It’s kind of interesting that you mentioned this
because I’ve read about the same thing recently.
We are currently in the process of reviewing our entire onboarding
workflow.
And when we first envisioned it for our subscription, I always had the
feeling I wanted to get the customer from our tutorial directly into the
app and experience how powerful mind mapping is, how they can start
putting all their ideas and collecting all their ideas to have some
positive impact on them before I actually forced them to see the
purchasing screen.
We’re still reviewing if we might want to change that in the future,
because the app store has the problem when you only see that the app is
basically free, you can download it for free. But there is no good
communication. What the real business model behind an app is before they
actually launch the app.
There is a small section on the app store page where you can see label
in a purchases and all the subscriptions, but hardly any user scrolls
down. I think most users just look at the screenshots, the first text
before the fold, and then they click on download.
00:45:46 - Speaker 2: Yeah, and I think that’s a real flaw in the App
Store page. Obviously, they’re inheriting the legacy of history, which
was in our purchases were originally a tiny add-on and then
subscriptions came from there, but that becomes the main way that at
least serious professional or serious productivity software is sold,
then it needs to be more front and center, and yeah, that leads to angry
reviews and things because people feel surprised or tricked or something
like that. So, yeah, it’s really tricky.
00:46:15 - Speaker 1: And then imagine back in the day, it was not
called get how it’s called now, but it was called Free and you clicked
on the button that said free.
And then you kind of realized as soon as you launched the app, the app
wasn’t free. There is an inner purchase behind that.
So I’m really glad Apple changed it a few years ago.
So as you can see, Apple is thankfully listening to some of the feedback
we developers provide.
And when it comes to subscription, I’m definitely seeing that this is a
model that Apple very highly recommends and makes constant changes and
improvements to how subscriptions work and how we as a developer can
profit from them, but also make it easier for our customers to work with
subscription. For example, last year they added a way to allow you as a
developer show a cancellation dialogue from inside the app to cancel the
subscription. So there are some great improvements there as well.
00:47:06 - Speaker 3: Speaking of feedback from developers, I remember
very early in the App Store life, customers could add a review, but then
there was no way for the developer to reach back out to that person, to
reply to that person. So yes, Apple brings you a lot of, you know,
customer visibility, but then they don’t necessarily want you talking
to those customers. So what were some of the challenges there in terms
of just, you know, dealing with those reviews and I’m sure I I brought
some very sad memories back to you just now.
00:47:39 - Speaker 1: Oh yeah, I almost forgot about that.
That was kind of frustrating if you have a customer writing a review,
and I think like a lot of customers also don’t write reviews because
they want to review that, but uh several customers also wrote reviews to
get support, so they thought, oh, that’s a great way to reach a
developer, and they were never aware of that developers had no way to
actually contact them again, so.
That was definitely one of the more frustrating things about the app
store in the beginning, but thankfully Apple changed that. And we also
try to respond to, if not all, at least most of the reviews, but I have
to be honest, I’m not really sure how many customers get the feedback
or understand that we responded, so we get unfortunately not a lot of
feedback from those.
00:48:28 - Speaker 2: One thing I’ll note, and again I’m coming from
the world of web software and seeing both the pros and cons, but also
just the differences of selling through the app store, and one striking
thing is that it’s clear that Apple or other app store creators are in
the same boat, I would imagine are really inserting themselves.
Between you and your customer. And for example, anonymity that I can
download an app and use it and the developer really doesn’t know that
much about me, and even something like sign in with Apple offers you
these abilities to obscure your email address or not share it at all.
And one of the things we chose to do on Muse and sometimes actually does
give us bad reviews, but we require you sign in with an email when you
start using the app, which is totally standard in the web world, people
don’t bat an eye. You wanna try a new service? Yeah, sure, you sign up
with an email, that’s just a normal thing. And we like that because it
allows us to have a direct connection with our customers, which is
important for support, it’s important if we need to proactively notify
them about a specific thing that’s affecting them, and in general, we
just think that owning the customer relationship is good for our
business, but that is going against the grain a bit in the app world,
where the expectation is sort of anonymity because of the platform
provider being this third party go-between.
00:49:48 - Speaker 1: I can totally understand that and we recently
considered doing something similar just to have a way to contact a
customer that their trial is running out. So we currently don’t really
have a way to contact the customer to let them know, oh, you are
currently on our free trial. The free trial expires in 2 days. We would
love to have you as a customer, but if you’re not really happy, here’s
the link to cancel the subscription with Apple. This is something that
we sadly can’t do at the moment, but I think it would really help us to
have a better understanding with our customers.
00:50:21 - Speaker 3: In some ways it makes me think that you have 2
customers, you have the customers that use my node, and then you have
Apple, and you have to keep both of them happy to some degree. Have
there ever been times where you’ve needed to kind of pick one over the
other, or they’ve competed a little bit in terms of attention or
features or direction that you needed to take my node, or has it been a
fairly benevolent relationship with both of those?
00:50:49 - Speaker 1: I think they did a really good job trying to
balance this in the past. There were not a lot of cases in the past
where, for example, we had to remove a certain feature because the
platform vendor wasn’t able to continue to support it, talking about
sandboxing another pain topic of the Mac App Store back in the day.
But overall, I think we try to find a good balance and If, as you
mentioned Apple, it’s always better to not get into the way of Apple
when it comes to certain features.
For example, if you know that this might be a feature that might not
pass a peer review, we personally try to stay away from this feature
just to be on the safe side because having a pain to go through
rejection after rejection is probably not worth it. Mhm. Which is kind
of unfortunate to be honest, because it means that some features will
never actually be considered to be explored by us and features that our
customers will never experience.
00:51:51 - Speaker 2: I’ve seen that, yeah, sort of counterpoint, I
guess, to the app review process, which, you know, is sort of a
controversial topic in some ways. There’s a lot of ways that it does
protect the quality of the app store and create trust with the end
customers, which is good for all the legitimate businesses that are
running there, but on the other hand, it does create a lot of
frustration and slowdown, which happily has gotten better over the
years. At this point of experimentation is a really good one that Yeah,
I hadn’t thought about like features on an individual app, but because
I know folks have talked about whole apps that they had ideas for that
they thought actually could be really valuable, but as they thought it
through, they’re like, no, there’s 20 ways that’s gonna run into this
app review gauntlet. I just don’t want to deal with that. I’m just not
even gonna create it.
00:52:38 - Speaker 1: And even if it passes a review, you never know if
it will pass the next app review or the one coming after and we had
similar issues with our business model where Apple was certain at some
point of the opinion, oh, you can’t use a free in a purchase to unlock
a trial that’s not supported by us. And then we had to go through the
app review board and show them other examples of apps doing just that.
And it’s just always lost time and lost resources you could have spent
otherwise.
00:53:07 - Speaker 2: Mhm. Another major difference I noted coming from
the wild west of the web, is that experimenting with pricing is way
harder to do within the App Store world.
Even the process of getting a price, whether it’s in an out purchase or
a subscription reviewed is a whole journey, and then if you want to test
out a couple of different price points with an AB or an ABC test, if you
want to test out something like the freemium model, something where you
say, OK, you know our current setup, you get 100 cards in the free
version, and then you can buy the starter plan. What if we make it so
that you can have a lower limit. On the free version, but the entry
price is a little lower.
Or what if we make the free version a little more generous but make the
entry price a little bit higher? What fits people better? And I think my
past experience as a business owner is you’ve got to experiment. If you
can’t try different things, you’re never going to land on the right
answer, and I think pricing is a really important thing to get right,
but trying to experiment with that, it’s possible, but it really is an
act of contortion.
00:54:08 - Speaker 1: Um, that’s right, yeah. But I think when it comes
to subscription, Apple tried to make this a little bit easier.
For example, I think only with a subscription you can set a price based
on the region you are. I think that’s not possible for any purchases.
And there’s also some new features that Apple added to store it and the
App store itself.
For example, you can now finally provide offer codes for your customers
to unlock a certain promotional offer which weren’t. Available until, I
think they only added it 3 years ago. So this is always when I think of
business model. I look at what is Apple currently doing, and they are
doing a lot of things when it comes to subscription, making things
easier for developers to experiment with pricing in this area and also
adding new features.
They haven’t added new features to other parts of the store kit
framework, I think in like forever.
And all the new features always land on the subscription site, which has
also, I have to be honest, some disadvantage because actually
implementing subscription in an app really takes a lot of time. So we at
least spent 4 months just trying to find a good implementation of
subscription, finding a good way to sync our subscription across
platforms, which is only possible since 2 years now, but that was before
we made the switch. So Store kit is not the easiest framework to work
with, to be honest.
00:55:36 - Speaker 3: Mhm. Which is surprising because it’s so, you
know, indispensable to both Apple and every developer. You’d think that
there would be a nicer environment to work in there.
00:55:47 - Speaker 1: That’s true, but subscriptions are also not easy.
They add a lot of things to consider, a lot of edge cases, a lot of
things when it comes to churning or. The customer needs some approval
from somebody else, from a parent, for example, to get the subscription
running and stuff like that. So we have a lot of states in our app in
which a subscriber can be and covering all of those correctly,
definitely takes some time and it’s not easy.
00:56:15 - Speaker 3: Yeah, I feel like even Understanding what the
options are isn’t easy, let alone then implementing those options in
the app.
00:56:23 - Speaker 1: Yeah, and also the UI and Aster connect is really
complicated when it comes to managing subscription. Have you ever tried
to increase the subscription price and to how many screens you have to
go through and how many little dials you can turn, that’s really not
the easiest UI.
00:56:39 - Speaker 2: Yeah, that’s right, and you also end up with a
lot of canonical information only in this web interface, which Apple is
great at building many things, but web interfaces are not one of them,
you know, it’s slow, there’s lots of unreliability, and in general
it’s just kind of confusing to navigate.
Things move around all the time, and yeah, for those screens, it’s just
very often, oh, I thought it was on the features, subscription, manage,
but it’s actually under App store payments thing and you’re looking
for the exact right checkbox and going through these flows.
I did a lot of the setup for the last time we did a major revision to
our pricing last year I did a lot of the just kind of grunt work of
essentially typing it all in.
And in addition to being really easy to do wrong, it’s incredibly high
stakes because once you type it in, you cannot change it. And in fact,
even the identifiers, the unique identifiers, which have to be unique to
the entire app store, not just your own app, for each. Subscription
code. Once you type it in, you cannot change it and you cannot delete it
and you can never use it again. So if you don’t type it in right the
first time, you know, so yeah, very harrowing. I think I messed one up
one time and we had to basically change our naming scheme for the
subscription codes.
00:57:56 - Speaker 3: I’m embarrassed to say on a very old app of mine,
I made a misspelling in one of those identifiers, and so it just haunts
me because it sits there mocking me in the App Store connect. 01 letter
wrong.
00:58:11 - Speaker 2: And then on the implementation side with Storitt,
it’s also tricky because you’ve got this concept of, I’m still
struggling to wrap my head around the exact technical architecture. I’m
sure you both understand it better than me, but there’s something where
there’s an on-device validation of this receipt, that’s the kind of,
yeah, anti-piracy stuff you’re talking about, Marcus, and then there’s
the Apple servers for managing, yeah, payments of subscriptions and
things, and then you can optionally, but it’s recommended, have your
own back end. That does some of this, and so there’s a three-way data
exchange between Apple servers, your servers, and the app on device app,
and then as you mentioned, the user might have multiple devices and
obviously the subscription can and should be shared across them, so it
gets confusing quick.
00:58:57 - Speaker 1: Oh, that’s true, yeah. As I mentioned before, uh,
store is definitely not the easiest framework, and web service and Apple
is also a topic, so you have this back and call that you can do to the
app store servers where you can validate a receipt. And in the past we
had several times where this kind of failed and we had issues with that,
so not really fun if your payment flow is not really working the way it
should be. But I can always have to come back to this one comment. It’s
getting actually better, so Apple is improving things and also when it
comes to services and running services, so I always try to be more on
the positive side and try to forget how it happened previously and what
was in the past.
00:59:42 - Speaker 3: It’s really striking to me how much of app
development has nothing to do with the app’s development sometimes
where the Features are certainly an important part of building an app,
but, you know, there’s all the payment flow which we just talked about,
but then you’ve mentioned that a lot of your traffic comes from, a lot
of your customers come from app store search. Have you done a lot with
the App Store product page and experimenting with screenshots or with
descriptions or with the tags or anything like that, or is it just a one
and done, we put it up there and Apple take the wheel?
01:00:21 - Speaker 1: We did a lot of optimizing the descriptions, also
the title of the app itself and also the tags, because in App Store
search, those are the three more important parts on how an app is listed
in the search ranking. Um there we did a lot of changes and I hopefully
we landed on something that’s working quite well at the moment.
But what we recently tried to use search as on the App Store, and there
we were looking really at everything, we kind of realized that our sales
page inside the app is probably not the best performing sales page, so
we are currently focusing on improving that and that’s also a lot of
work, to be honest, just having to think about what else you have to do
there and how you present the sales page.
01:01:10 - Speaker 2: By sales page, you probably are referring to what
on our team we usually call paywall, so this is some kind of dialogue
that pops up and basically says, you know, hey, if you buy this thing or
you upgrade, then you can get these features.
01:01:24 - Speaker 1: Exactly, yeah, I just called sales pitch. I’m not
sure if there’s an official name for that. You’re a business person,
right?
01:01:31 - Speaker 2: Yeah, fair enough. Well, I’m also reminded of in
addition to this idea that so much of building an app is not what you
think of as building the app, building features and creating value for
the end user and solving their problems, but as all these meta things
that go around it that are necessary and in fact critical like getting
that paywall right, making sure your app presents well in the app store,
all those things are so important if your business is gonna survive and
ultimately if, yeah, people are gonna find. the app and use it and want
it and pay for it in the first place in order to get actual value from
it. But so much of that is outside the realm of maybe what we got in to
do this for, and there’s a parallel on, I think the company side as
well, you know, at some point after I started my entrepreneurial
journey, found myself, my day absorbed with employment contracts and
filing taxes and, you know, twiddling admin interfaces and some SAS tool
that I use. I said, was this my dream? This is the thing I wanted to do.
But yeah, it’s just part of it, it’s the reality.
01:02:32 - Speaker 3: It really takes me back to the beginning of the
conversation when we were talking about how important it is.
For a coder turned manager to stay coding and to stay, you know,
involved in the product somehow, even if you might not be writing
features every day, but to still find that thing that brought you there
in the first place, and to still find that original motivation and that
original excitement in the product.
I think for me it’s certainly the code, it’s certainly some of the
elegance around that, or the data structures, it’s the piece that I
enjoy, but for others, I think it’s the team or the cohort of people
that you’ve built that are Going on this journey with you. What is that
for you, Marcus, that You know, you’ve been doing this now for Gosh, at
least 14 years, maybe longer than that. What’s been that thread for you
that’s really tied this together, that’s been exciting?
01:03:21 - Speaker 1: There were always those ups and downs where I
wasn’t sure what my job really is.
Should I do more coding? Should I be more involved with the vision of
the company? And I think 1 or 2 years ago, I kind of realized.
I had lost the vision on why I actually wanted to do this app, and then
I took a little break and I came back really strong thinking that I want
my vision is not that I code every feature that I know every part of the
app, but my vision is that I really want to create a great app for the
platform. I want to. Enable our customers, our users to find their own
excitement inside the app, to enable them to use the app in a way that
brings their creativity to the front and always thinking that helps me
really to stay motivated and find the real vision behind what we are
doing.
01:04:16 - 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. And Marcus, thanks for becoming one of
those indie developers that inspired you and how hopefully you can
inspire that next generation of developers who can build productivity
tools that are made with love and intention.
01:04:41 - Speaker 1: Thanks again for having me and being able to tell
my story, which is hopefully inspiring to some of your listeners.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: You can also be notified just based on an
algorithm, you know, if somebody files something that’s similar to your
trademark to trigger a notification to you. The interesting thing about
the trademark office, at least from a government perspective, is it’s
the most government 2.0 out there in the sense that the data is publicly
available and can be downloaded every single day.
00:00:24 - Speaker 2: Hello and welcome to Meta Muse. M UUE is a tool
for deep work on iPad and Mac. This podcast isn’t about Muse product,
it’s about the small team and the big ideas behind it. I’m Adam
Wiggins here with my colleague Mark McGranaghan. Hey Adam. And we’re
joined today by Josh Gurbin of Gurban Intellectual Property.
00:00:42 - Speaker 1: Thanks for having me, guys.
00:00:44 - Speaker 2: And Josh, I understand you have 4 kids. How in the
world do you manage life work balance with that and being a business
owner?
00:00:51 - Speaker 1: That is incredibly difficult. I will say that the
plan was maybe not to have as many kids initially, but these are the
things that happen as life goes on. And one of the great benefits I have
is that I get to work from home every day. So I don’t have a commute
into the office or home from the office, so I can wake up, get to work,
and You know, when the kids get home from school, I have a little time,
but, you know, I’m not wasting an hour or 2 hours a day commuting to
and from an office in a big city and having that time back is really the
critical element I think in making it all work.
00:01:23 - Speaker 2: That’s huge. Now have you found some good
techniques for communicating boundaries around your office slash,
you’re on a call or just need to focus, especially, you know, I don’t
know how old your kids are, but the younger they are, the less they
understand, you know, closed door means you can’t come in.
00:01:39 - Speaker 1: Absolutely, so in my house we actually have an
office, you know, that I work from that’s dedicated for me and
everybody understands that the doors closed, you know, you just don’t
come in, I’ll come out when I’m ready, and luckily, you know, when you
work from home and you talk about those boundaries with your kids every
day, they really understand what you’re doing. Now, of course, there’s
gonna be a situation here and there where they run in and They probably
shouldn’t be, but the benefit of COVID is so many people have had to
work from home and deal with that now that it’s not unusual for anybody
to kind of see a kid running around on a call here and there, so it’s
almost an enduring quality these days, so I find it works pretty well
and for the most part, you know, we’re able to sort of separate in our
house.
00:02:17 - Speaker 2: Absolutely, I almost wonder, yeah, every time my
kids run in and jumps in front of the screen and everyone sees her, you
know, it’s obviously always like a very positive reaction, but I almost
wonder if that’s a positive reinforcement for what ultimately is not a
good behavior, which is, you know, violating the boundary of the closed
door or the workspace. But yeah, then you can’t resist it. Everyone’s
just entertained to see an unexpected cute face pop up on the screen.
00:02:42 - Speaker 1: And honestly, if you have kids, you appreciate
what’s going on and you understand what’s going on, and I think that
that’s something that, you know, to me it doesn’t bother me if I’m
talking to somebody and their kids budging. I like to see what their
life is like. I like to see that they’re a human being too, right? And
I think that that humanizing aspect of things can even make
relationships stronger between people. So I personally have no issue
with it, and I think if somebody does and they’re probably got ice in
their veins, you know, it’s.
00:03:08 - Speaker 2: And tell us a little about your firm and your
background.
00:03:12 - Speaker 1: Yeah, sure, so I started the law firm in 2008 in
the middle of the Great Recession.
I had a steady job, a good job at the time.
I was 2 years out of law school and everybody thought I was absolutely
crazy as 27 years old and they’re like, you’re gonna start your own
law firm? I mean, most people don’t want to hire a lawyer and it looks
like he’s 12 years old and I definitely looked like I was 12 years old
at the time, but I said, look, I can offer pretty low-cost service and
I’m not gonna have any overhead and I wanna really be out on my own.
I’ve always wanted to have my own business.
And basically started by using Google AdWords and going out there and
putting up a website and slowly but surely got clients and If you’re
just building brick by brick day by day, ultimately you build up some
clients, you get some repeat and referral work, you continue to take a
new work and slowly but surely you grow a law firm, and now we’ve got
13 employees, we file around 1000 US trademarks every year plus hundreds
of trademarks in other countries around the world. So it’s been quite a
ride and just something we’ve built very methodically and slowly over
the last 14 years.
00:04:15 - Speaker 2: Nicely done. I feel with a services business,
which I for a few years was a software consultant, and the common wisdom
there and certainly reflected my experience was you get business through
referrals, essentially through your network and ideally clients that
refer you to other ones, but they tend to be all word of mouth. But we
found you.
Because you have a good website and I basically just Googled US
trademark when we were thinking about filing for Muse and now we have a
multi-year business relationship.
I don’t know, is that unusual that we came in that way, or is this kind
of reflecting a new reality of the internet world which is you can
actually essentially get randos from the internet that come to hire you
for your service.
00:04:57 - Speaker 1: Well, yeah, absolutely, and that was a lot of the
disbelief that I had amongst the legal community because lawyers, you
know, they tend to be really reticent to adapt to new technologies and
new techniques of advertising and things, and everyone said, who are you
gonna find online that’s looking to hire a lawyer? Who are you gonna
really get? And well, obviously, you know, we’ve gotten some really
good clients, you included and One thing that we invested in very early
on was search engine optimization. So you likely found us through an
organic search and not necessarily an ad.
I will say that in my experience, you know, the clients that come to us
when we were doing the Google ads, which we don’t really do anymore,
were harder to kind of parse through all the leads and finding sort of
the good. Ones in that bag of leads that would come in every day.
But because we have such a great organic presence and work really hard
on that, we find that the clients we obtain from that presence tend to
be really, you know, great clients, and we’ve built a business that
way.
I will say probably now, to grow a service business, I certainly agree
you need the referrals because it’s very hard. You know, there’s a lot
of work that goes into building a new relationship with a new client
that’s found you online and has their own suspicions about you and
building that trust factor is really challenging. But if someone comes
in through a referral and it’s a warm referral, they have the trust
already, they’re like, oh, this person has worked with Josh, they know
his firm, they trust him, I’m gonna trust him, right? And so there’s a
lot less work that has to be done to build up that relationship and
that’s really what’s allowed us to grow is that warm referral business
that we have.
00:06:24 - Speaker 2: One thing I noted right away on the embrace of
technology side is you had a calendly link or some kind of automated
form for basically asking for your time, asking for a call, and I think
I’m not sure how common that is nowadays. It’s very, very common in
the tech industry, but this. It was 3 years ago or something like that,
and so I was quite impressed by that and it seemed to signal that you
were embracing technology to make lives easier for everyone, and that
implied to me that we would be sort of compatible in terms of working
together, a working relationship.
00:06:55 - Speaker 1: That’s so interesting to me to hear that because
I have gotten mixed feedback on that Coly link over the years.
Some people really hate it. They take it as an insult that you won’t
take the time to schedule a call with them, and I’m just shocked
because I’m like, well, how many emails do we need to trade to find
what time works for you and what time, and this is just you go in there
and you just, you know, yeah, I mean I think that’s a nice.
The thing about working with people in tech is that you appreciate those
tools and, you know, we do offer a lot of our services at a flat rate,
so we are incentivized as a law firm to be more efficient, and that is
actually, you know, the reverse of the way a lot of law firms think,
because a lot of law firms are like, well, we want to be as inefficient
as possible and build as many hours as we possibly can to get this task
done, and we’ve always been designed of, we need to get this done as
quickly and as good as we can, but we need to get it done as quickly as
we can.
When you’re focused on that, you look at all the different tools that
are available and you start to use them because they’re really helpful
in keeping your time down and letting you move through projects.
00:07:51 - Speaker 3: This is very interesting to me.
So, for the listener context, Adam has sort of reached out and
established the relationship with Josh, so I wasn’t involved in that,
and I wasn’t aware actually Adam, that you had reached out sort of cold
over the internet, and my experience with almost all Lawyers and
accountants and similar professional services firms is that they
basically don’t talk to you unless you have a referral. They don’t
quite come out and say that, but that’s really the MO of most folks,
but I think it’s notable that Josh and I think the law firm that we
worked at, we both found through their online presence basically and
reached out, and then our accountant we’ve known for like 10 years, so
that’s a different case, but it is one little data point in the
changing world of professional services.
00:08:30 - Speaker 1: Yeah, it’s interesting to hear. I mean, I think
that it depends on the size of the professional services firm because a
lot of the firms are set up to have these really significant overheads,
and they have a very developed client base that they’re billing every
year, and these are retainer clients and they have these very set
budgets. So when they take on somebody new, that new person needs to
have a certain budget in order for it to make sense for that firm to
take on. And where we differ is we have a very low overhead structure
and we’re actually focused on serving. A lot more diverse of a client
base and let’s say 100 big clients a year. We’re focused on serving
1000 smaller clients a year. And to us, that’s a great benefit because
if one client for some reason leaves, we’re not looking at having to
lay people off or having a huge loss of revenue, you know, we still have
the 999 other clients that year that are gonna be, you know, keeping us
afloat and keeping the lights on and our people paid. And so when
you’re not reliant on these like large whale clients, then you are more
apt to really want to take in, you know, new work every single day
because you are relying on more or less the volume.
00:09:38 - Speaker 2: We went through something exactly like that with
our software consultancy, which is we got some.
Bigger projects, in particular, one big client and we had to staff up to
serve their needs, but then when things changed with them out of the
project or whatever, and then suddenly we’re scrambling around to find
enough work to keep these folks fed and so yeah, I mean, it’s of course
it’s always the case that professional services and you know it’s kind
of like a scaled up version of freelancing, which is feast and famine.
That’s right, but the more you can diversify and spread out a little
bit. But yeah, you get that client that comes in and, you know,
basically is well has like exactly as he said, and that’s it’s really
compelling, that’s how a lot of services businesses do what they do.
00:10:19 - Speaker 1: Oh, for sure, and I mean you know we had in the
last 2 years, we had 3 or 4 of our largest clients get acquired, and
when that happens a lot of times you lose the trademark work because the
business that’s acquiring them is much larger and has their own lawyers
already and so, you know, we have to be prepared that even when we build
up and work with a particular Client and they become a larger client,
they’re eventually gonna leave.
So you have to always kind of have what you call a farm system of
clients you’re developing and hopefully getting into the next big
client to take the place of the one that will eventually leave for one
reason, either through a sale of the company or they get so big that
some other lawyer poaches the work or whatever it might be.
00:10:55 - Speaker 3: Yeah, I wouldn’t be surprised that even if you
don’t have outsized clients in terms of work, you probably have some
clients that give you an outsized amount of referrals. I’d be curious
if that’s the case.
00:11:06 - Speaker 1: Yeah, you know, actually other lawyers are our
best source of referrals because a lot of other lawyers don’t have a
specialty in trademark law and they’ll get a question from a client
about a trademark, and there’s this ethics rule that applies to all
lawyers that you can’t do work for somebody unless you really feel
competent to do it, and if you’re not feeling competent to do it, you
might have to charge your client to get competent, whereas they could
just call us and we could do something really quick and easy for their
client and the client gets great customer service.
And at the end of the day, the lawyer doesn’t lose their client because
we’re not looking to take, you know, somebody on for more than the
trademark work.
So when we start working with our lawyers and other law firms, they’re
like, wow, this is great, we can send these things over to Gurin and
they turn it around and get everything taken care of and the client’s
happy and they’re staying with us for their other corporate work or
whatever it might be. And so those law firms and lawyers tend to be our
best referral source.
00:11:59 - Speaker 2: Well, that’s certainly a benefit of the tight
specialization that you have, and maybe that is a good transition into
our topic today, which is trademarks.
So maybe this is a slightly surprising one for our listeners who are
used to a lot of our focus tends to be on design, product, tools for
thought, research, things like that, but at least one of my goals with
this podcast is really to document all of the aspects of building a
business that Mark and I and all the others on the Muse team are going
through here and the trademark is.
One corner of that, but I found a surprisingly intriguing and
intellectually engaging one. And just in our conversations, Josh, just
on the phone working through our case of getting our various trademarks
filed, I’ve been just fascinated by the mechanics of it even past
what’s necessary for the purpose of doing the project, so I hope we can
share that with our audience here.
00:12:49 - Speaker 1: Yeah, absolutely. That’s my everyday.
00:12:53 - Speaker 2: Now of course, I’d like to tell a little bit
about the Muse journey in our trademarking and why we’re motivated on
all that and so forth, but we always like to start really at the
beginning, which is just definitional. What is a trademark?
00:13:06 - Speaker 1: Yeah, so a trademark is a source identifier,
meaning that it identifies the source of goods or services. So if you
see a Nike logo on a shoebox, you know that the shoes in there were made
by Nike Inc, the corporation, and you know that the shoes have a certain
quality about them and where they come from.
And so trademarks, and many business owners are surprised to hear this,
but trademarks and trademark law exist to protect the consumer, not the
business owner. So the test of whether you ever have trademark
infringement is whether consumers might be confused as to the source of
the goods or services because the trademarks are so similar. And that is
why trademark law exists in the United States.
But yes, so a trademark is meant to identify what company is behind
whatever product or service is being offered.
00:13:55 - Speaker 2: And I’ll do a quick call back to our episode on
brand, where I spoke there about some historical examples, and a notable
one here is Heinz, which actually started as a jarred pickle business,
later went to their now what they’re known for with ketchup, but the
big innovation there was that you had these door to door salesmen that
would sell these canned foods, but you didn’t know where it was from.
That’s the source that you’re talking about there. And Heinz came
along and came up with the idea of I’m going to put my name on it in a
very particular typeface and a very particular kind of recognizable
color scheme, and I’m really going to stand behind the quality on this
and get people to trust. I guess trust me, trust, you know, Mr. Heinz,
but really they’re trusting the brand, and that was maybe the birth of
the modern concept of brand, but that pretty naturally leads into why
you need trademarks in that circumstance, which is like, OK, if you
built a bunch of trust around a label with a typeface and some colors,
well, that’s pretty easy to duplicate. And so then legal protection to
prevent that as sort of a form of, I guess, defrauding the consumer or
tricking someone in a way that harms them, it makes sense for the law to
provide that protection.
00:15:03 - Speaker 1: Yeah, absolutely, you know, I’ve never heard that
story before, but that is an amazing way to kind of paint the picture of
why trademark law exists and how it helps protect consumers.
00:15:13 - Speaker 2: And just very broadly speaking, how do you think
about when a business owner should register a trademark for one or more
of their products?
00:15:23 - Speaker 1: So, I’m gonna be completely biased because I’m a
trademark attorney and this is how I make my living, but it should
arguably be the first thing that someone does in connection with
starting a business.
And that’s because if you have a name for your company or a name for
your product or service, you should not start investing in that. You
should not be creating logos around it. You shouldn’t be buying signs,
you shouldn’t, you know, you shouldn’t be building brand equity into
it until you know that trademark is clear for you to use, meaning
there’s not any other conflicts.
And you’ve got a trademark application filed, which gives you a
priority date in that particular mark, meaning if anybody else comes and
tries to use the name or file for the name, they’re all gonna be
subject to your rights from the date you had filed that trademark
application.
So we typically, if we can get to a client early enough, we remind
people that you want to do this as sort of number one A on your list of
things to do when you’re starting a new company or starting a new
product or service line.
00:16:20 - Speaker 2: So maybe you would lump it in with registering a
domain name, setting up your Corp or LLC, some of those other just basic
mechanics of getting a business started.
00:16:31 - Speaker 1: Absolutely, especially, you know, if you’re ever
going to spend a nickel on buying a domain, you know, you’re not just
getting it for $1299 because nobody else wants it, but you’re actually
investing a couple $1000 or whatever it might be to buy a domain, you
really wanna make sure that the name is clear, because if you buy a
domain that somebody else may have a trademark registered around or a
similar trademark registered around, they would actually be able to come
and take that domain from you potentially down the road.
So, Just making sure that name is clear and also again getting an
application file to set a priority date in place, absolutely critical to
protecting yourself whenever you’re setting all those things up.
00:17:08 - Speaker 2: And give me the simplest possible case. I have a
name that is very unambiguous, you know, maybe it’s long, it contains
my personal name or something like that, no confusion with, you know,
something that’s, for example, a single English word will come to why
that’s challenging. You’re in just one jurisdiction, let’s say the US
since you know that well. What’s the simple case in terms of like time
and cost to get your trademark filed?
00:17:32 - Speaker 1: Yeah, sure. So depending on the service provider
you use, the cost can vary pretty significantly. You know, you could go
online, as you mentioned, and find a lawyer like myself.
There’s other lawyers that now hawk their services online as well,
there’s plenty of them.
You could use a service like a LegalZoom, which is technically in most
cases a non-legal service, meaning you’re just, you know, using a
software that people have created to kind of help you with the search
and help you with the filing, and you pay a fee for that, or you can
hire a really large institutional law firm. And depending on which path
you go, your fee structure is gonna be a lot different.
The way that we view ourselves in the market is that we’ve always tried
to set ourselves up to provide the same style of service you’re gonna
get from a large institutional firm and the same know-how, but do it at
a rate in between what a non-legal service like a LegalZoom charges and
what a large institutional firm charges as many times as, you know,
priced out a small business owner.
So just to put numbers out there. We typically charge $950 to run a US
trademark search, provide an opinion, provide consultation time, and
then ultimately file the application. And in most cases, your filing
fees are going to be around $250 or $500 with the government. So, a
$1500 budget is pretty sufficient in most cases and whether it’s our
firm or some other small law firms, you probably find the prices to be
pretty similar.
Time wise, Typically it takes about a week or two to run a trademark
search properly. So you can go online and do this yourself, you know,
and there’s a lot of information about, well, go to this website and
run a trademark search or what have you, but those searches are very
inconclusive because they only are looking for identical matches, and
the thing that will cause the most problem for anybody that’s trying to
register a trademark is not an identical match, but something that just
sounds like your trademark or slightly spelled a little bit differently
than your trademark, because those are all things that can create a
conflict.
And so a professional search is gonna look for all those things and
takes a little bit of time. So typically it takes our firm about 3 hours
of staff time. There’s some paralegal time and there’s some attorney
time in there, and it takes us that kind of time to get a search done.
So, again, it might take a week or so to get that turned around, but
then shortly after that you can get an application filed. Let’s call it
2 or 3 weeks from the time you’re engaging somebody to the time you get
your application filed.
Now, once the application is filed, this is where it’s kind of a
process these days. The United States Patent and Trademark Office, which
is the government agency that processes these filings, they take about
10 months to even process your trademark application now. It used to be
3 to 4 months, of course, now it’s 10. So you’re gonna wait a really
long time to get an answer. But once you get that answer, if they
approve it and move the application forward to registration, typically
around month 12 to month 14, you end up with the registration
certificate and you’re all set.
00:20:19 - Speaker 2: As you mentioned before, actually being in the
line, having the application submitted itself is worth something that
kind of reserves your place, so to speak, and furthermore, I hadn’t
realized this until we’d worked together, but I think there’s these
two different symbols you can if you want. Use together with your
trademark. One is the little TM kind of superscript and one is the R.
And tell me if I’m remembering this right, the TM you can actually do
as soon as you have filed the application and the R means it’s been
registered and accepted. Am I remembering that right?
00:20:52 - Speaker 1: Yeah, absolutely, matter of fact, you can use the
TM before you even file, if you want to.
So the TM stands for, hey, I’m claiming a trademark right of some
kind.
It might be what we call a common law right, meaning a right that is an
unregistered right, or it could mean I’ve got a federal trademark
application filed and I’ve got a pending registration.
So that TM can be thrown up at any time.
The circled R can only be used once you actually get the registration
back from the USPTO.
So again, a year plus down the road.
People are often surprised to find that if you use that circle R before
you receive the registration, that’s actually a violation of federal
law.
No, they’re not gonna arrest you and throw you in jail, but it can
actually cause a refusal of your trademark application if the government
finds that you’re using that in their examination process, so you
don’t want to use it before you get the registration.
00:21:41 - Speaker 3: That’s interesting. I feel like I’ve seen TM in
places where almost certainly they’ve filed and gotten the
registration. Is that just because they like the TM or maybe there’s
never filed, or maybe I’m just misremembering it?
00:21:55 - Speaker 1: No, you’re remembering it properly in all
likelihood, because two things tend to happen.
One, folks set their marketing and forget it, so they never change to
the circle of R, and that’s fine too, like you don’t have to. I mean,
it’s not a requirement, you can still just use a TM.
The other thing is for a business that touches internationally, if you
are registered in the United States, but let’s say you also use the
trademark in Europe or Australia or South Africa and you don’t have the
mark registered there yet, don’t want to use the circled R there yet
either.
So it’s a little easier to keep just using the TM symbol if you’re in
jurisdictions where you haven’t yet registered the mark or still trying
to register the mark. And sometimes that’s why that happens too.
00:22:32 - Speaker 2: That makes sense. Now those markers, I don’t know
how it is for others or maybe beyond the tech world or whatever, but I
do think of them as being something that nowadays people would find a
little corny, you know, if you stick that into your product marketing
materials or whatever on your website that I don’t know. You sound kind
of old school or fully yourself or something like that, like we’re not
going to put MTM for example, up on our website. Now, maybe a little
more classy way would be at the bottom, you know, there’s some gray
text that says, you know, X is a registered trademark of dust and such
corp. I don’t know if your other clients feel that way, but I can’t
imagine myself using either of those symbols regardless of any trademark
status we have.
00:23:13 - Speaker 1: It’s so funny you say that because that is like
one of the most polarizing questions that I think I get, because
there’s people on either end of the spectrum and no one in the middle.
So either people love putting the trademark symbols next to their name
because they feel it makes them look official, or they hate it because
they think it junks it up and it’s corny.
And there’s no in between on that, you know, it’s like you either far
right or far left.
And so I personally like them. I mean, I’m a trademark attorney, I
think they look great when I see them, and we advise clients to use them
because there’s a technicality to using these symbols, which is that
when you use them, you’re putting the public on notice that you’re
claiming a trademark right.
So if somebody does infringe on your trademark, that quote unquote
notice has already been given, which could enhance damages and awards
should you, you know, have to sue somebody in federal court. So, Legally
speaking, the advice is always to use them. I certainly understand where
some folks feel like that is not the aesthetic that they’re going for
or the look that they’re going for, in which case we advise them to
just try to get it in somewhere like you say, maybe it’s in the footer
of your site instead of on the masthead or something like that.
00:24:14 - Speaker 3: And this reminds me, I feel like there’s some
branch of intellectual property law and maybe it’s trademarks, maybe
it’s something else where it’s like fight it or lose it, and that if
you don’t contest other people infringing basically on your whatever IP
then you sort of lose the claim to it, so you can’t come back 10 years
later and say, wait a minute, you know, I want this back. Are trademarks
like that?
00:24:32 - Speaker 1: Yes, they are. So basically, there’s a policing
requirement with a trademark in that if you don’t police the
marketplace and you don’t police the federal register and other people
register trademarks that are similar or same as yours, it will basically
erode your rights over time.
So the benefit of any kind of trademark registration is that you think
of your trademark and then draw like a big circle around it, and you
have a lot of elbow room that you can enforce, right? So if somebody
uses a phonetically similar trademark, you can ask them to stop. If
somebody uses a spelling of your trademark that’s very similar, but
maybe, you know, not the same, you could ask them to stop.
For example, let’s say someone tries to register Muse with a Y, and
they’re offering a similar service or product that you are, you could
ask them to stop.
But if you don’t, and you allow them to go forward and register their
mark or use it, and a certain amount of time passes, typically about 3
to 5 years, you could be stopped from ever making that claim in the
future.
So once somebody uses a trademark for so long and you sleep on your
rights, the law basically says you can’t sleep on your rights for 5 or
10 years and show up and tell someone they can’t use their name.
So you have this window in which you have to actually police it. And
then if you don’t police it and that person uses your name and somebody
else uses a similar name, basically that circle we’ve drawn around your
trademark gets much, much smaller and smaller and smaller over time.
So your rights just erode, and they get to a point where maybe you can
only do policing on a very, very narrow type of infringement that might
occur, and not some of these sort of fringe cases, if you will.
It becomes very common for clients to get a trademark registration
certificate and kinda just be done, you know, they’re just like, uh, we
got it, we’re good, we’ll see you later, we’ll see you in 5 years
when we got to renew this thing, and that’s fine, but the challenge
with that is, is that over time, again, if they’re not doing that
policing work, the rights just won’t be as broad and to most companies
that may never matter until you have a problem, right? And then you’re
like, ah, I would say it’s like wearing a seatbelt. If you put the
seatbelt on every day, Hopefully you’re not gonna have an accident, you
know, ever, but when you do, you’re really glad you put the seatbelt on
every day. If you’re not wearing a seatbelt and you just have an
accident, you start to go through the windshield, there’s no like going
back in time and putting it on, you know, and that’s kind of the same
concept here. Once you start to have the accident and the problem and
you haven’t been doing all the preventative work, it can be really hard
to kind of unwind that.
00:26:50 - Speaker 2: One way we can anchor the discussion a little bit
here is to talk a bit about Muse’s journey on this and some of our
motivations and some of the particular challenges.
Josh, you mentioned that one of the things your firm does is this
search, and indeed when I came to you and said, you know, we’d like to
register this word, and you basically said before even doing the search,
all right, you’ve got a short English word, this is going to be a
challenge, but let us look into it for you. And you came back with a
report that had a big red banner that basically said like high risk and
listed a bunch of similar ones again different spellings, some are
older, some are newer, some were for big firms and so on, and indeed I
reinforced. That for myself by just going to the US trademark search
page, we’ll link that in the show notes. You can do this yourself and
just search and there’s hundreds of entries.
Now many of them are defunct or businesses that aren’t around anymore
or whatever, but that seems to be true for almost any simple English
word like this. There’s a lot of businesses in the world that people
have registered for a long time and some of these are active and so you
basically came back and we did a process of, OK, could we Add a word,
could it be the muse canvas? Could it be something else to make this an
easier process for us, but ultimately we decided to go ahead and for
there I’ll rewind even a little further back in time. Which is Mark,
you and I had taken a walk while we were on basically our very first
team summit in Dublin, Ireland, which is when me, you and Julia had
gotten together to say, OK, we think there’s business potential here.
Do we want to spin this research project we’ve been doing out of the
lab? And indeed we decided there and the name you, I think you would
come up with Mark, but it was kind of a placeholder for this research
project, but he argued, you know, this is a good. I think it captures a
lot about the spirit of the project and I’d like to use it if at all
possible, and that includes obviously the defending against any risk
that either we’re stepping on the toes of someone else who’s already
in the space or someone else that might come up behind us and that’s
why we decided to go on this what has now been a multi-year journey of
filing this trademark in several different jurisdictions.
00:29:04 - Speaker 3: Yeah, names have always been super important to
me. I mean, there’s a whole business reason, of course, why names
matter, but for me, whenever I’m starting or in the early days of a
project or a library, There’s an incredibly important milestone where
you come up with a name that feels really good. You always start with
something generic or goofy, or maybe you pick some character from a
novel you just read or whatever, right? You got the kind of placeholder
name, and we had that with Capstone a while back, which was a prototype
that would eventually become used. But I remember quite vividly, I sat
down at one point and thought from first principles, what should the
name of this thing be? You know, it should connote thinking and
deliberateness. But have sort of this creative, not too mechanical feel.
And I wrote down a whole list and man, you really felt like the right
name. But I knew it was gonna be tough. It was gonna be very tough to
get a domain, and I assumed it was gonna be tough in terms of the VIP
side. But I really wanted to have a good name, both for the business and
for the sort of psychological value of saying it for the next 5 years or
whatever. And I specifically didn’t want to do something like use
Canvas software apps. I wasn’t gonna cut it for me. So I’m really glad
that we did try to pursue the single word.
00:30:13 - Speaker 1: Yeah, and there’s always this pool between
marketing and legal with any trademark.
I deal with this a lot, where from a marketing perspective, the single
word muse, four letters, that’s ideal, right? It’s an easy to remember
word, it’s short, it’s sweet, it’s to the point.
From a trademark perspective, when you’re trying to register a
four-letter word against millions of trademarks that have been filed
before you, the chances that there’s gonna be a completely clear path
are pretty slim.
And so that’s where the challenge comes in between what’s good for
marketing versus what’s good for legal.
I always give people the data point that in 2021, there was 669,397
trademarks filed with the USPTO, so nearly caught almost 700,000.
That’s one year, you know, so you could just imagine going back now,
we’ve filed more and more trademarks now than we ever had before for
various reasons, but You know, when you have this many trademarks
getting filed every year and you’re trying to get a four-letter word
registered, you’ve got a lot of potential complications and competition
to worry about. The one thing I always tell folks about name selection
is that Most great names didn’t really mean much or wouldn’t be great
unless the company really built a great product or service behind it. I
look at Nike for shoes, I don’t think there’s anything great about
Nike. It’s a four-letter word, but it doesn’t strike me as like a
great brand name if I didn’t know that there was a huge shoe company
behind it. Same thing with Google, it’s like, what does that even mean,
you know, but And famously, Google is a mathematics term,
00:31:52 - Speaker 2: you know, Google is where it comes from, yeah, but
it’s actually misspelled, you know, a misspelling by one of their angel
investors that, yeah, yeah.
00:31:56 - Speaker 1: So those are sometimes, you know, I do think
people put a lot of value in the names that really sometimes they
shouldn’t until they actually build the brand equity into the name, and
then that’s when the value is there.
00:32:09 - Speaker 2: Yeah, well, maybe there’s a mix there for me,
getting the right name on a project, on a company, on whatever it is, as
Mark said, it feels right, and then I, I’m actually more motivated to
invest myself in it and build that brand equity. Sure. You know, one
theme on this podcast for certainly is that the motivations of the
creators do matter a lot in making a great product and So, yeah, we
probably could have made things easier for ourselves, you know, gone the
route of, I don’t know, you know, Miro was called real-time board when
they started, could we have been called like real time canvas or
something, but that just would not have inspired me.
00:32:43 - Speaker 1: That’s totally fair and very important. There’s
no question.
00:32:47 - Speaker 2: Now one element of the name you’ve mentioned a
few times here is the overlap or I guess it’s the risk of confusion for
consumers.
And one thing that really struck me in one of our early calls is you
talked about the standard is different in different industries.
So I think this is pretty obvious for businesses that are clearly local.
So for example, here in Berlin for a few years it shut down, but there
was a restaurant near my house called Muse, and presumably they weren’t
worried about.
Even another restaurant in another city with that same name, for
example.
And similarly that any kind of local business you’re really worried
about the people who are near enough to you to know who you are, do
business with you, transact, a part of the nature of technology
business, you know, you put an app in the Apple App Store and you’re
instantly available in almost every country in the world where you put
something on the internet and you’re instantly available everywhere, so
you’re sort of little tiny just got started product is now essentially
competing in the global namespace.
So that makes things way harder, although perhaps that’s balanced out
by it seams, and you tell me if I’m remembering this right, but it
seems like the various trademark authorities in different countries know
that and actually apply a different standard to, for example, a piece of
software or an app than they would say, fashion.
Do I remember that correctly?
00:34:10 - Speaker 1: Yeah, for the most part, so one of the things we
talk a lot about when we’re looking at how clear a particular trademark
is is how diluted is that word in a particular industry as well. So, the
thing about clothing brands or fashion brands is that that is one
category of trademarks that probably receives more applications than any
other in any given year because of the low bar to.
Part of a clothing company. I mean, you know, you or I could go online
and theoretically start a clothing company in 20 minutes. The bar to
starting a software company and having an actual software product to
sell is much higher, so you have fewer applications coming around that
than you might the clothing category.
So, if you look at a trademark search that you would do around a fashion
brand, you’re probably gonna find Let’s say a couple dozen trademarks
that might look really similar, but yours is just different enough that
you can kind of thread that needle between every other one of them
because so many already coexist in that space.
Whereas if you come into a category that’s less traffic and there’s
only one other name that’s similar to yours, the government, at least
in the USPTO’s case, you know, when they’re doing a review of your
trademark application. They’re gonna have a lot harder time approving
your application if there’s only one other trademark in your space that
uses a similar name as opposed to having 20 other trademarks in your
space that might have a similar name.
00:35:28 - Speaker 2: And what is the standard for customer confusion?
So this is certainly a lot of what we’ve done in crafting our various
applications is describing what the software is, or I suppose, I guess
what the product is, but how that relates to the trademark, because it
seems fairly obvious to me that for example, I don’t know, there’s a
web browser or at least was one called Mosaic, and there’s also an
investment firm called Mosaic, and actually I’ve seen other companies
and open source projects and things.
It’s, it’s just like that’s a good name. A lot of people have used
it, but to me there’s no risk of confusion between a tech investment
firm and a web browser, but you could say they’re both in the software
business. Where do you draw the line and what’s the standard for
differentiating there?
00:36:12 - Speaker 1: And that’s what makes trademark law challenging
and exciting at the same time, which is that there’s normally not a
case that’s been decided on the particular point that you’re looking
at.
Like you said, would an investment firm and a software browser be
similar? I mean, the instinct that I have would be, no, they wouldn’t
be. But then you get other examples you’re like, well, what about this
and this? And you’re like, well, that’s closer to the line, right? And
so there’s this sort of imaginary line that we’re dealing with as to
when does something get too close to it. And that is why there’s
litigation in this world, right? That is why there’s lawsuits because
people disagree about what the line is and how close you can come to
it.
I also love the examples of, you know, you have Delta Airlines and you
have Delta Faucets, you know, faucet maker, you have Dove soap and Dove
chocolate, you know, you can reuse names in different industries, but
then the question becomes, you know, how close can you get? One example
that I can think of is Beer, wine and spirits are typically considered
to be very closely related from a trademark analysis.
Although from a consumer perspective, if you’re buying these products,
you’re likely in different aisles in the supermarket or in whatever
store you’re buying the product, right? You don’t normally buy a vodka
off of the same shelf you’re buying a Pinot Noir from. And so the
question is why couldn’t a wine and a spirit have maybe similar the
same name. And coexist peacefully in the marketplace. I think they
probably could, but there’s a lot of case law and a lot of decisions
that have been made out there that says, no, these are all very highly
related things and you can’t coexist. So sometimes you have a developed
area of law because people have litigated it, and other times you’re in
industries where people just haven’t litigated it yet and there’s not
really a clear answer to the question of whether or not these two things
are considered too close.
00:37:55 - Speaker 3: And is there any underlying statute here, or is it
just pure case law?
00:38:00 - Speaker 1: Well, the underlying statute in the United States
is called the Lanham Act. If you want to look it up, it’s L A N H A M
and then Lanham Act.
That’s where it kind of talks about the fact that if consumers are
confused, you’d have trademark infringement.
So if you’re litigating a case, one of the things you typically do is
you convene a poll or a study, and you actually go out and
scientifically interview consumers and see if there’s any confusion.
And these things can cost like 500,000 to $100,000 to run, so I mean,
they’re really expensive type of project, but you know, large
corporations do them when they’re litigating these cases. So you have
that baseline statute, but then, as to your point, the case law is what
develops kind of these finer points, which is, are beer and wine too
close? Is a clothing brand and a jewelry brand too close, you know, and
all these types of questions that get asked, this is where the case law
sort of develops and and tries to provide some guidelines as time goes
on.
00:38:58 - Speaker 2: I wonder if the software industry is harder or
maybe just more confusing from a regulator perspective because it is
still new enough, that’s something that’s often not well understood by
people who are not in the industry.
I certainly run into this all the time with just explaining what I do to
friends and family, very smart, educated people, but it’s just if
you’re not pretty deep in the software world, you may not know the
difference between Certain categories of productivity software versus
B2BAS versus infrastructure versus medical software versus something
else.
So I wonder how much, you know, obviously the folks working in the
trademark office, they are dealing with all varieties of business and if
you come in and say, Well, no, you know, this piece of software is an
app store, and this other piece of software that I’m registering for is
a health tracker, and those are just completely different and there’s
no risk of confusion, but maybe to the person in the office that it’s
sort of like hard to tell the difference.
00:39:56 - Speaker 1: Yeah, so there actually this case law out there
that talks about that two software products could certainly coexist with
the same name in different industries. So there’s at least a
recognition in the law that just because it’s a software doesn’t mean
that you’re in the same industry, because at one point that was the
problem that was occurring is that everybody was lumping software into
the same category.
00:40:15 - Speaker 2: Now that’s actually a really good point, which is
the software industry, I mean. We say that all the time. We talk about
being in the software, but like it’s really software and the internet
is part of everything now. So there isn’t exactly an industry. There
are practitioners like us that have skills around it to build careers in
technology broadly, but really when you talk about industry in the sense
of serving a particular set of customers’ needs, software is a means to
an end. It’s not a category of thing a customer is buying.
00:40:40 - Speaker 1: You’re 100% right, and then the law started to
recognize that, but where there’s still a challenge, and this is why
you’d sometimes have what’s called expert testimony at a trial, is
that understanding the nuance sometimes between what is really related
and what is not, is really, really hard for people that are not in the
industry to get their heads around, right? And so you might have a
software that tracks health data. And then you might have another
software that tracks or that is related to like a hospital system and
how it’s tracking patient data and the government thinks that those are
related, but one’s really a consumer product and one’s a product for a
hospital, and those are again, two very different channels of trade we
would call it. So you have those things that can be really hard for a
trademark office or a court to really Get into the finer details and
lines if they’re not super obvious, and again, that’s where you get
expert testimony and things like that involved, but that is also why
people run into trademark problems because there is still this really
difficult way of trying to parse out what industry are you really in
once you’re in that software category.
00:41:43 - Speaker 2: And then presumably that’s also part of your job
is to explain it, to bridge the gap, you know, we went through this
process which is I’m explaining what it is we do, and by the way, early
stage products, especially things that come out of a research world like
us, like it’s actually hard to even explain what it is that you do in
the beginning.
This is part of the nature of kind of yeah, early stage work generally
is you’re developing a way to talk about what it is you’re doing,
you’re pursuing an intuition to a product vision and you have a Message
or a position or whatever you want to call that early on, but it’s
often kind of wrong and you evolve it over time as you better understand
the problem you’re solving for customers.
But then your job is to listen to this early, very raw description.
We’re still figuring it out as we go along and then translate that into
something that a fully non. Software world person could hopefully make
sense of.
So certainly, you know, we can’t talk about tools for thought in our
application. That’s not going to make sense to someone here you need to
talk very about, you know, really well established patterns and maybe
also about the customer who’s the person that actually buys this
because maybe that’s one of the more relevant things here.
00:42:56 - Speaker 1: We have inside jokes as trademark attorneys, you
know, and one of the biggest ones is when you’re talking to a client
and they’re throwing all the industry jargon at you to try to explain
what they’re doing and you’re just like, You spend 20 minutes
listening to somebody and you have absolutely no clue what product or
service they’re providing to people, and I will be on the phone with
someone and I will be kindly as I can try to say to them, look, you
gotta stop using the jargon and just explain to me like I’m an idiot,
you know, what this is, because I have to be able to really get my head
around what you’re doing to write the language for the trademark
application and I will actually tell you this, I kind of use it as a
test when I’m working with a client, like our clients that end up
running the best businesses can articulate very clearly to someone not
in their industry, i.e. me, what it is that they’re doing, and folks
that just spill the jargon out and can’t get away from that, I find
really struggle because I just don’t think that they relate to folks
that are not doing that one very specific thing that they’re doing, and
that becomes a problem for them at some point in their business. And
that’s just something I’ve noticed over the years.
I’ll have younger associates at our firm called me up and say, I just
got off the phone with this client and I have no idea what they were
saying. They didn’t want to interject and tell the client they didn’t
understand, and part of my training is always you have to do that
because that is our job is to understand and if they’re saying it in a
way that you don’t understand, like you just have to be very blunt
about that.
00:44:17 - Speaker 2: That’s something I believe in in general, which
is I always take as inspiration some of these great scientists who are
able to explain things like electromagnetism or relativity or something
like that in a way that is accessible to potentially anyone whether or
not you have their training.
Now obviously you’re leaving out a lot of important.
Detail that people in the field need to be able to actually work with
it, just the high level conceptual pieces, but it’s something I’ve
always struggled with in my career in music actually is probably one of
the easier ones in some cases, something like Hiroku that was
infrastructure software where if you are a web developer and you need
this product, you understand. What I’m saying, and I do lean on jargon
because that’s the easiest thing when I’m speaking to my customer,
because they want to hear the jargon because they’re in the field and
they know it and this is a good way to communicate.
00:45:04 - Speaker 1: We love jargon as lawyers too, we have our own
language, yeah, yeah, and clients will complain about that too, like I
don’t know what you’re talking about, you know, it’s yeah yeah for
sure, yeah, jargon gets a bad name sometimes.
00:45:12 - Speaker 2: But I think of it as a highly efficient and
precise way to communicate between people who are in a very specific,
yeah, line of work, or even endeavoring under a very specific project,
yes, and that can be extremely useful and valuable versus the more like,
kind of general purpose explainer. But if you cannot bridge the gap to
the general purpose explainer, I think that’s a weak point that’s
worth addressing just kind of philosophically in life in general.
00:45:43 - Speaker 1: Completely agree. That’s a great way of putting
it.
00:45:47 - Speaker 2: The one thing you hinted at earlier that I found
to be an interesting part of the process is just putting in the
trademark application triggers, I don’t know the right way to put it,
but it goes into a public database. This is something where anyone who
wants to get notified, I don’t know how the system works exactly, will
find out that you’ve filed this application and Actually, I quite liked
this because at the beginning when we were looking at this very high
risk word to register, what I didn’t want to do is embark on a
multi-year potentially somewhat expensive in terms of attorney fees
journey just to get to find out that there’s some major firm that is in
our field or very close to it that basically is going to be really upset
that we’re doing this, and we might not discover that until further
along in our business.
And so I liked the idea that by just filing the application, we would
bring people out of the woodwork who would object to us using this name
and we could look at who those people were and kind of make our own
judgments of, oh, OK, this is really worrying versus hm, I don’t know,
this one, it’s a brand new startup, they’re kind of not even really
working on the same thing. Who knows if they’ll even be around in a few
years. OK, I’m pretty comfortable with that risk. Can you tell me about
how that kind of notification The system works.
00:47:03 - Speaker 1: Yeah, sure, and it’s different country by
country. So, for example, in the United States, when you file a
trademark application, no one’s ever gonna notify another party that
you might be in conflict with.
The only thing that will happen Is the US Patent and Trademark Office
might actually deny your application because of these other trademarks,
but they’re never gonna notify these other folks.
What you can do though, in the US, and there’s plenty of software
options for this, is that you can set up a watching service so that any
time your trademark is used as a reason to deny a new application, you
can be notified. You can also be notified just based on an algorithm,
you know, if somebody files something that’s similar to your trademark
to trigger a notification to you.
The interesting thing about the trademark office, at least from a
government perspective, is it’s the most government 2.0 out there in
the sense that the data is publicly available and can be downloaded
every single day. We actually have a section of our website that you can
go to. And it pulls every day from the trademark database, filings from
big companies, celebrities, sports figures.
So if you’re curious to see what trademarks LeBron James owns, you can
come to our website and see as of today what trademarks he’s filed and
owns, you know, with the USPTO and we have a back end, basically like
API that goes in and pulls that data every day. So you have a bunch of
software companies that have taken advantage of this data that’s
available and can push these notifications to you, like one of the
services we use.
I get an email on any client we’re monitoring their trademark on every
month that shows me what trademarks have been filed lately that might be
too close to theirs. And then I can go through and determine, of course,
the algorithm pulls things that aren’t relevant, but I can go through
that and determine what things the client should be aware of and notify
them and see if they want to take any action.
So that data that’s out there is really valuable and like you said, you
actually have a unique view on it, Adam, because Most of our clients are
very scared that somebody’s gonna see this and send them a letter.
You are more like welcoming it and saying, hey, this would be great if
we can get any objections out of the way. And so that’s a very
refreshing way to look at it, but a lot of people are actually scared of
that process and really get nervous if they get a letter.
But to your point, most of the time getting letters is the start of a
conversation, it’s not the start of a lawsuit or something like that.
Now, the difference here is where you are in the world. So if you go to
Europe or the UK when they review a trademark application, they don’t
just refuse your application. As a matter of fact, they won’t. They’ll
just tell you, hey, we saw that there’s a couple other trademarks that
are similar to yours, and we’re gonna notify those owners about your
application directly and they’ll have an opportunity to lodge an
objection. And if they lodge an objection, then that stops your
application, but if they don’t, we’ll register it. So, in those
countries, It becomes the onus of the trademark owner to actually spend
time and money to oppose an application they get notified about by the
trademark office. So it’s a really interesting and very different
fundamental process than it’s here in the United States. But that is,
again, yes, you’re right, by filing an application, that’s how you
will draw fire is by one of those two ways.
00:49:59 - Speaker 2: You know, I guess this comes from the, or my
perspective on this comes from the thinking of general like you know,
startup or early stage or risky ventures, which is your goal is to kind
of de-risk, to use some jargon, de-risk some, you know, the biggest
questions and the biggest things you’re worried about.
A lot of times that’s the technology, but it might also be the market.
It’s part of your job as the creator or founder or whatever is to sort
the list of things that would be catastrophic, you know, for your
business, i.e. their fundamental assumptions and de-risk those as early
as you can.
You want to find out if it’s going to work before you do a deeper
investment.
And so for me, I knew the muse, because it’s this short English word,
could be tricky. So before we spent a lot of time investing in Brand
equity, as you called it earlier, I wanted to know how likely was it
that 2 years on, we would need to like do this big rebrand. And so,
there’s always a risk of that, I suppose, but to me it created more
confidence to basically send the mind-seeking robot out into the
minefield and see what explosions happened that created more comfort for
me to step out into the minefield.
00:51:07 - Speaker 1: And you’ve seen the explosions at this point,
right? You know what you’re dealing with, and there is a lot more
certainty around where you are with the name and what the path forward
looks like. And I think that that is something that not only is valuable
to you, but would be valuable to investors in your business or
eventually an acquirer of the business, right? So, I would say if
you’re going to use a name, file the trademark applications because
people will get a search back and there’ll be some trepidation and say,
I see risk here, what do I do with this risk? And I’ll say to them,
well, you have two options.
You can change the name and try to get a lower risk situation, or if
you’re gonna use the name, we file the application and be aggressive
about trying to acquire the registration because once you acquire the
registration, you make it much, much more difficult for somebody to
challenge you and especially you make it almost impossible for someone
to challenge you once you get out to 3 or 5 years down the road of
having this registration because of the way the law works.
So, absolutely, even though there’s risk, going out and securing and
doing everything you can to secure registrations actually lowers risk
over time, and that’s why you do it. And I think you articulate that
great in your example and how you think about it.
00:52:12 - Speaker 2: One other note here is that I do really think of
this as a defensive activity. I certainly in no world want to be in the
business of suing anyone over their name being too similar to ours, but
what I am keenly aware of is that it is the reality of being on the
internet in this day and age that when things seem to be a success,
people copy them.
It’s software is in some ways. I don’t want to say it’s easy to copy,
but let’s say in some ways it’s easier to do that and perhaps even
fairly anonymously, and I’ve seen lots of great businesses and great
products that have to deal with copycats or in some cases wholesale
copying of their website or other things like that, and it’s harder to
fight back against that.
So for me it’s very much of a defensive thing.
And that makes me think to some degree of other kinds of intellectual
property and so software patents, which are a very contentious topic for
software engineers but nevertheless are a thing that exists and you look
at companies like say Google or Apple or Microsoft, they have these huge
patent portfolios, but as near as I can tell they mainly use it as kind
of a Mutually assured destruction style deterrence, which is, you know,
because Microsoft has such a huge portfolio of patents, Google is not
going to sue them over that and vice versa because they could then go
into some cross suing with that and it’s basically to everyone’s
benefit just to kind of hold their territory unless there is a truly
egregious violation.
00:53:40 - Speaker 1: Yeah, just to add on to that, Adam, I think the
one important thing about the defensive nature of trademarks, especially
in the software business, would be the platforms that you go on to
distribute your software.
So for example, the App Store. We had a client recently who, you know,
we have trademarks registered for them in US, Europe, Australia, some
other countries, and they found somebody in the app store that was
basically using their name, OK, and had an app out under their name, and
The problem was, is the app wasn’t really directly competing with them.
It was sort of an ancillary thing.
It’s kind of one of these question mark situations as to whether or not
it was really an infringement of their trademark, but because we owned a
trademark registration, all these jurisdictions, we could go back and
basically tell the app store, no, no, no, you can’t let This other app,
use our client’s trademark on your platform.
We think it’s too close, and, you know, Apple’s got like a
quasi-judicial system, it’s not really that great, but sometimes it
works, and in this case it worked, in which case we were able to
convince the other app owner that, hey, look, you’re gonna have a legal
problem if you continue to use this name on the app store, and we were
able to get that name back and Now that’s like our client’s username
and all these other countries where they needed it. So, just again, you
know, you’re not gonna get into federal litigation over that
necessarily, but you’re gonna be able to use the registration to kind
of elbow your way into the usernames and different things you need on
third-party platforms.
00:55:06 - Speaker 3: Now I know in the world of patents, there’s this
issue of patent trolling. Is that a thing in trademarks or is that just
not as much of an issue?
00:55:13 - Speaker 1: Not as much of an issue because Patent trolling
and the claims and patents, they tend to be a lot sort of more
theoretical in nature.
And as Adam was just saying, like you have this like mutually assured
destruction thing where like, yeah, you come after me for this, I’m
coming after you for that, and you tie each other up in litigation for
years and you end up sending a bunch of lawyers, kids to college, you
know, and stuff like that. So, you know, companies tend to be dissuaded
from that type of litigation at some point.
But yeah, with trademarks, in order to have a right and a trademark and
to be able to enforce the trademark, you actually have to be using it in
the marketplace.
So you can’t just go and register a name. You actually have to be using
the name for the government to grant the registration, and if you stop
using it, somebody else can cancel your registration. on grounds of
abandonment, whereas a patent is just good for however many years,
right? And so, it’s a big difference in the way that the rights are
created and ultimately how the rights are maintained over time.
So we normally don’t have a troll issue. We have people that get like
overly aggressive in enforcement, meaning that like Two very common
examples would be Monster Energy, the energy drink company. If you file
a trademark application that includes the word monster, you are probably
gonna hear from them, because they have registrations on Monster from
everything from clothing to jewelry to energy drinks and every other
product or service you could probably think of. And they do a ton of
policing around that, which, you know, a lot of people would argue is
what we call trademark bullying, because they’re basically saying like
this word monster, somehow they own it in every space and, you know, a
lot of people just don’t agree with that. So you have instances like
that, but that is sort of what you’re more or less contending with, not
necessarily like a troll, like a patent.
00:56:51 - Speaker 2: Makes sense. I opened up the, what I see is called
the Gurban Trademark library TM.
00:56:59 - Speaker 1: You got the TM up there for sure.
00:57:02 - Speaker 2: And you have quite a long list of, yeah, bands and
sports folks and companies and so on, it’s pretty interesting to click
through this, of course I had to click on Apple and they have looks like
over 1000.
In here, which in some ways almost seems low in some ways, but I’m
actually reminded that the kind of notifications of new trademarks
actually is also a way that sometimes journalists who are trying to get
an early scoop on what’s Apple doing, what’s Google doing with some of
these big tech companies is by seeing that they have filed an
application for a new trademark and then inferring what the product
might be from the name, just an interesting exercise.
I’m also noticing quite a lot of these are sort of logo number 103 or
something like that, which does lead me to another question, which is
basically the difference between logos and words in trademark.
00:57:56 - Speaker 1: Yes, so when you are filing a trademark
application, typically what we tell clients is you wanna first protect
your words, because if you file a trademark application from use, you
know, your name, you can then use it in any font, any logo, any
capitalization that you want. You just say, I just want the word
registered basically.
Because sometimes there’s this gravitation to clients that will call us
and they’ll say, hey, I have this name and this logo. I want to
register it, and they think they’ll just file it in one application,
and you can, but then what you’ve done is you’ve blocked yourself in
to having to use that logo in order to maintain that registration.
You know, we were just talking a minute ago about how you have to
continue to use the trademark in order for the registration to remain
valid.
Well, if you register a name and a logo together, And then all of a
sudden you change the logo 5 years later, your registration is no longer
valid or enforceable. You have to refile. And that restarts that whole
process or restarts all the time, you know, that 3 to 5 year period
we’re talking about to get more certainty on keeping people from making
a claim against you and all those kinds of things. So the very first
trademark you wanna file is typically just on your name itself, then you
would file other applications for logos and slogans and things like that
separately so that you keep those assets separate so if any of them
change, they’re ultimately not affecting your name.
00:59:10 - Speaker 3: So now I’m curious on this trademark, did you get
trademark library generally or urban trademark library?
00:59:17 - Speaker 1: Well, for the trademark application that we filed
on this, we did file for the Gurban Trademark library, and that’s
because trademark Library on its own arguably has some distinctiveness
concerns. You know, we talked earlier about wanting to have a really
distinct.
Trademark. Well, yeah, this is obviously a project we had. This is not
something we really make money on. This is kind of a side thing that we
do.
So we wanted to call it something that would make sense and people would
understand what it was. So we chose trademark library.
And if you look at our trademark registration on this, the government,
the USPTO made us put a statement in the application that we’re not
claiming an exclusive right to use trademark library apart from the
market shown, meaning that It’s really not distinct enough, and we
arguably might not be able to keep other people from using that phrase
at this time.
Now, this is something we launched in 2020. Once we get to 2025, which
would be five years after launch, we would be able to reapply for this
and claim that because we’ve been using this exclusively so long, we
should now get the rights on trademark library pretty much exclusively
from there.
So we will, presuming that that’s what happens. But yeah, this was, you
know, a name that did not have the elements of uniqueness that one might
really want if you were coming up with a super unique brand name. It was
just something we thought was kind of cute and catchy and was an easy
solution to what to call it.
01:00:38 - Speaker 2: Yeah, so I guess one question I think that I asked
you, Josh, and some of our early calls is, OK, part of being on the
internet and being in the app store is near global availability and so
as far as I know there’s no UN level trademarks and so they need need
to make a call where to register, and I think some are fairly obvious
for us like the US because that’s where our business is located and
where quite a lot of our customers are located, but how do you? And to
clients typically that they make a call on where to register and how
much to be concerned about global coverage, some of which may overlap.
You can register in an individual EU country or the EU as an overall, so
there’s a lot to think about there.
01:01:21 - Speaker 1: There absolutely is. I mean, it very much depends
business to business, and what we always remind clients is that
trademarks are jurisdictional in nature, which means that you can have
rights in the US you don’t have rights anywhere else. You can have
rights in the UK, you don’t have rights anywhere else. So where do you
want your rights to apply? So pretty much around the world, you have to
file in each individual country that you would like rights.
The one major exception being the European Union, where you can file an
EU trademark that covers you in every EU country. There’s some nuance
to maybe wanting to file in some EU countries directly, especially if
you’re really heavily invested in those particular countries, but for
the most part, the EU registration will be just fine. And then it
becomes a question of budget. So if your company is operating in 20
countries around the world, or, you know, has downloads in 20 countries
around the world, ideally you register in all those countries, but
there’s a cost to doing that. And so, You sometimes have to figure out,
well, what’s the cost of doing that versus what’s the cost of doing it
in the 10 countries that we have the most downloads in, right, or the
most customers in, and it becomes just a very practical question at that
point. So, we just tell our clients, look, we will price this out for
you and you have to kind of figure out based on, you know, what the
government fees are and the legal fees are and file in all these
countries. Is this something that’s acceptable to your company or do we
need to get this budget down? And then we kind of strategically figure
it out from there. The other good news is it’s not just an all or
nothing thing, you can Do 5 countries this year and 5 countries next
year, you know, you don’t have to do them all at once, and as your
company grows and as your budgets grow, you can continue to grow your
trademark portfolio from there.
01:02:59 - Speaker 3: Now, can you use trademarks that you’ve
established in your initial jurisdiction as sort of evidence as you go
to other jurisdictions in the case of software which is quasi-global?
01:03:11 - Speaker 1: It’s a real challenge because coming from the US,
you know, obviously I’m based in the US, a lot of folks here have a
very like world domination perspective that, well, I have a US
trademark, doesn’t that apply everywhere else? And the answer is always
no. We’re not that special.
And so the idea that you have used in the United States and then you go
over to Australia, like, they don’t care, it doesn’t protect you down
there. What might protect you is if you’ve used it a little bit in
Australia too and you just haven’t registered it, but Every country’s
got its own borders and its own laws, and that’s something that folks
in your industry have to be very cognizant of.
Is this name not only clear to use in my home country and where I’m
based out of, but is it gonna be clear to use in all the places that I
really want to be in? And look, there’s never gonna probably be a 100%
place where you can get 100 countries without a problem.
Even Apple computer has problems with its trademarks. You can Google
about all the trouble they had in China and other places, but You know,
you’re always gonna have trouble somewhere, but the idea is can we get
this in enough places that, you know, we feel we kind of hit a critical
point that we’re gonna be pretty good and the last few we gotta chase
around are just gonna be that. And that’s how you kind of build a
global brand is you really try to register it in as many different
places as you possibly can, that you’re gonna do business.
01:04:22 - Speaker 3: Interesting. So if you had cases where you had
clean trademarks in most jurisdictions, but in, I don’t know,
Australia, there’s been some company working there for 10 years that
happens to do some special software thing, and so you can’t, and then
what do you do? Do you like not list it in the Australian app store or
do you block Australian IPs? Don’t allow Australian credit cards? How
does that work?
01:04:42 - Speaker 1: Well, it depends on the client, but certainly
I’ve had that issue. I mean, some clients will say, well, we’re gonna
just move forward with this name, and if somebody objects to it, we’ll
deal with it then.
Then you have other clients who will take the steps to purposefully not
put it in an app store or make it available to customers in a certain
country.
You know, like we have clients that if somebody tries to purchase a
product, you know, it might not be a software, but let’s just say it’s
a shirt, you know, when they’re based out of the UK, well, we won’t
ship to the UK because that would be a violation of somebody else’s
trademark.
So, yeah, you can certainly do that in today’s world where you
basically have to say, hey, look, we’re not gonna operate in this
country, we’re not gonna ship product to this country, we’re not gonna
allow access to our website from this country and that’s not ideal, but
that is a solution to working around a trademark problem.
01:05:28 - Speaker 2: Wouldn’t another one be to use a different name
within that country?
01:05:32 - Speaker 1: Yeah, and we have those discussions with clients.
I mean, as you can imagine, that is something that a lot of people that
sounds like a huge hassle. It’s a huge hassle, right? Yeah, exactly.
And nobody wants to hear. Everyone’s like, oh my God, like is it, but
we’ve actually had clients do that, especially more or less clients
that have operated overseas trying to come to the US and when they come
to us to get the US mark cleared, they find a problem here and they had
no problem overseas.
Well, then they have a decision to make, you know, they don’t really
have any brand equity here yet, nobody really knows who they are. But
they have a good product or good service, and they want to access the US
market, well, maybe they’re gonna change the name over here. And I’ve
seen that happen.
01:06:05 - Speaker 2: I can imagine that being part of localization,
which is uh especially for a packaged product or something, it’s pretty
common, you know, it’s a drink and you need different, you know,
nutrition label on the back, depending on what the market is. So you’re
doing that work to print the different label anyways, so maybe it feels
like not such a big deal, but certainly it would be confusing for People
working at the company, customer support people, I don’t know, that
just sounds bad.
01:06:31 - Speaker 1: Oh, it’s rough, but you know, the other thing
that happens is sometimes you go to translate your word into a local
dialect or language and you realize it’s offensive in that language,
right? And so all of a sudden something that was mundane here in the US
and you go over to China or somewhere else. And it’s like, whoa, like
we don’t want to use that brand name over there because it’s gonna be
a problem.
So sometimes you even have that kind of issue develop.
So it really depends when you’re starting a company. If you’re really
gonna be global fast, you want to consider all these different things.
You might want to run clearance searches in multiple countries, you
might want to understand what the translation issues are in different
countries and things like that.
But then you have some clients and customers that are just growing
organically and they start in one place and then they just look to other
countries because that’s a natural growth place and that’s when they
can run into more problems down the road because they weren’t thinking
about it initially, and either way, you know, there’s not a right or
wrong answer, but these are just the problems you sometimes run into.
01:07:23 - Speaker 3: And I’m curious mechanically, do countries tend
to look like the US where it costs a few $1000 and takes a year or two,
or are there some that are really slick and it goes really fast, or are
there others that are just impossible to deal with?
01:07:37 - Speaker 1: Yes, so we basically have such a difference in how
things work. So in the US like I talked about, you gotta figure about a
year and change to get a trademark registered.
In the UK it might be 3 or 4 months right now. I mean, it’s fast, fast
trademark speaking.
In Canada, we’re up to 3 years of waiting, believe it or not, to get a
response from the trademark office.
I have filed things 3 years ago and I have clients that like just don’t
believe me. They’re like, how can this take 3 years to even get a
response? And I’ll have to send them like all the blog posts that our
lawyers have done about it just so that, you know, it’s like
unbelievable.
And then you have jurisdictions like China. Which, you know, seem to
basically refuse almost any application that we ever file for a US
client because they’re a US based business and then you have to deal
with the rigmarole over there.
So, yeah, every jurisdiction has its own kind of uniqueness and
certainly some are quicker and easier than others. I’ll give the
European countries a lot of credit. They seem to have this figured out
the most as far as, you know, our experience has been concerned and sort
of the slickness and easiness of the process. But yeah, it varies very
much country by country.
01:08:37 - Speaker 2: Well, I feel this is a reflection of a larger
shift, you know, we talk about making an app, some single developer can
put something together and have it in the app store and be starting a
side business or some soloreer thing very quickly and I think in a not
too distant past, going into another country as a new market would have
been this huge Step for any business.
Certainly a retail store or something like that, we’re gonna expand
from the US into Canada, or we’re gonna expand from Germany into
France, was a big, big deal.
And now the internet with app stores and just an increasingly global
culture, you know, people can Use products that are only available in
English, for example, the ability to buy things with credit cards and
PayPal and other means is much better than it has been before, so the
world is getting closer together, you know, this is globalization,
whether you are a fan or not, it’s happening, and so that the
implication. There is, yeah, for a small business owner, yeah, that
single solo developer that is putting an app together, but now they’re
thinking about trademark jurisdictions in dozens of countries. It’s an
interesting collision of maybe an older, less connected world and a
newer, increasingly connected world.
01:09:58 - Speaker 1: Very well put Adam. I completely agree with that,
and I think that’s a challenge that, you know, we’ll just continue to
face as time goes on and the world gets smaller and smaller. There’s no
question.
01:10:08 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at museAppHQ or
write us on email hello and museApp.com. And Josh, thanks for taking us
on this journey to help us secure the rights to this name that we love
so much.
01:10:27 - Speaker 1: Absolutely, and thank you for having me. Thank you
for entrusting me with your trademark and look forward to many
conversations to come.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Here’s my number one tip for listeners of this
podcast episode. The most unreasonably effective thing to do in
recruiting is to move quickly, especially as a small company where you
have the ability to do that.
00:00:16 - Speaker 2: Hello and welcome to Meta Muse.
Muse is a tool for deep work on iPad and Mac, but this podcast isn’t
about Muse the product, it’s about the small team and the big ideas
behind it.
I’m Adam Wiggins here today with my colleague, Mark McGranaghan. Hey,
Adam. And a fun little announcement here, we’re growing the Muse team, or
we have grown the Muse team, I think it’s the right way to say it.
So the designer storyteller position we posted a while back, we’re very
pleased to welcome Linda Ma to the team as our 6th team member, and
indeed we’ve also had some great candidates for what could be #7,
that’s the local first engineer, so we kind of hope slash expect to
have a similar announcement on that in the not too distant future.
And this is what made me think it would be time to finally do an episode
we’ve talked about for ages, which is on the topic of hiring or
recruiting or perhaps team building. And this is something you’ve done
quite a lot of, particularly a little bit of Hiroku and a ton at Stripe,
and indeed you even have an article on your website, Thoughts on
recruiting that I’ll link to, but maybe you can start us off by giving
an overview of what you think hiring is all about and why it matters.
00:01:28 - Speaker 1: Oh, I have so much to say about recruiting, and
it’s hard to believe we’ll even fit it all in close to one episode,
but A couple of things I’ll say at this stage. One is that obviously
the team that you build is gonna be the company that you build and the
product that you end up building.
It’s really the foundation.
That I think is pretty obvious, but I think people often forget that.
The other side of it is that this is a huge part of people’s lives.
If you work, say, at 4 years for a company, that might be 5% of your
mortal human life, you know, spent much of your waking time spent there.
And maybe it’s a 10th of your career.
So it’s a really big deal on both sides, and I don’t think that people
treat it with the seriousness and importance and gravity that it
deserves.
Just kind of throw something up on indeed and, you know, respond to the
emails or whatever. I don’t know. It just seems like such an important
topic that really merits deep thought.
00:02:21 - Speaker 2: It is certainly part of the Silicon Valley culture
to say hiring is, for example, hiring is job one for the CEO. That might
be a phrase that someone might bandy about, but I would argue maybe some
of that ends up putting a lot of emphasis on the quantity of hiring and
the speed at which you do it rather than the quality and the quality not
just of the candidates in terms of how they fit the company, but the
team that you’re building and how it integrates and fits together and
ultimately can. Do what you’re there to do, which is, you know, build
the product.
00:02:53 - Speaker 1: Yeah, I think a big theme of this discussion is
going to be holistically thinking about recruiting, hiring, team
building, and zooming out a little bit, and it’s not just about all the
little tactics, it’s really easy to get to zoomed in on that. We got to
keep in mind the goal of having an effective productive team, and
considering all the things that can lead up to that.
00:03:14 - Speaker 2: I think an important part of what we’re talking
about here as well is that we’re obviously talking largely about hiring
the technology industry, which is where all our experience is, but I
think an important part of it is hiring creative people to create
something that’s often fairly novel in the world, and so you really
need, there’s the whole mission driven concept and being aligned and
sharing values, all of these things I think are an important part of
it.
That’s one piece of it is I think you really need to get people who are
going to put their spirits into it in a way that It’s not just do they
have the skills, it’s a do their passions line up with the things the
company needs.
And a related thing is the immense privilege we have being in this
industry, which is it’s a very in demand field and so the people who
are being hired side of the equation, they have a lot of options. Not
only are they well paid, but they have the luxury, you know, if you’re
good at interviewing and have the right CV and everything like that, you
may be able to get offers from several places. So the hiring manager is
often not just kind of this doing this transaction of here’s the work
that needs to be done, here’s the skill set, and here’s the
compensation.
But actually there is an element of getting them to join your club,
perhaps getting them to join your cult, buying in on the mission,
believing in it in a deep way.
And I’m reminded a little bit of this 80s movie Ghostbusters, where you
have the original founding team of Ghostbusters, who are these kind of
kooky types, or at least some of them are these kooky types that have
all these beliefs in the supernatural and the occult and so on. At some
point they realize they need help and they go to hire someone new and,
you know, they’re basically asking interview questions about, what do
you believe. This and this and this, and he just says, look, there’s a
steady paycheck in it. I’ll believe anything you want. That’s probably
not what you want for creative work. You want someone who is going to
buy in because indeed the things they care about and working on in their
career, perhaps things they’ve worked on in the past or their personal
passions match up to some degree with what the company’s mission is.
00:05:16 - Speaker 1: Indeed, one of my little recruiting nuggets is
that the primary challenge with recruiting in this technology industry
is attraction, not filtering.
I think people go to filtering things like, what are the interview
questions and what are the criteria that we’re gonna use to knock
people out of the process because it’s more inwards focus, it’s more
about you and what you’re doing in the office day to day. And also
because I think people are keying off of companies like Google, of which
is a very small number that have a legitimate filtering issue where they
have a huge number of people applying. The challenge for the
overwhelming majority of software companies is that people don’t apply
to your job, they don’t even know about it. That’s why I think this
attraction problem is so important.
00:05:55 - Speaker 2: Well, I thought a good way to structure this might
be to talk through the hiring process we use at Muse.
Now, Muse, importantly, is not a growth oriented startup, but I think we
do need to attract in your wording here in the same way that a faster
hiring company would, and this is a process I think you and I have used
a bit at Hiroku. I’ve used in different companies and it’s kind of
what we use in Muse.
And not to be too process focused, but maybe in talking through it, we
sort of reveal the tips and tricks, the values, the approaches, the
painful lessons we’ve learned over the years.
Maybe also worth as a glossary here, kind of defining a couple of terms
that I will certainly come back to a lot. One is team. And that the team
of people that you’re trying to put together to again be sharing those
values and having work in chemistry and a sense of creative trust and
the ability to make commitments to each other and keep each other
accountable, that’s a key part of this.
You’re not just trying to hire individual people, you’re trying to
build a team and each of those people needs to be integrated into the
team. And I was like the anti- example of a team, which is something
like US Congress. The members of Congress may be colleagues, but they
are not a team because they really don’t have the same, many of them
don’t share values or have the same end goal, and so it’s a
contentious sort of finding of constant compromise, but I think a good
team is one that does share more values, goal, mission, and so therefore
you’re getting to great, great outcomes.
The kind of team is one word in there.
And then two others that will come up a lot, I think is manager or
hiring manager. And actually doing a whole podcast on management is
another topic that’s in my backlog somewhere, but at least for the
purpose of our discussion here, take a hiring manager and then the
person who not only figures out who should come into the team, but also
helps them be successful is a big part of this equation. And then the
job description is the other one, and we’ll probably start there. So a
clear written description of why you want to hire, what problem is being
solved, and what candidate would look like that would kind of fit that
slot.
00:08:05 - Speaker 1: Yeah, it’s a good baseline to have. So, where
does the process start for you?
00:08:09 - Speaker 2: Yeah, well, number one is the hiring manager
writes a job description.
And obviously that starts with whoever is going to do the hiring kind of
recognizing a need.
So this is why it’s important to, to my mind, label a hiring manager
who is a single owner for this, as someone who’s identified. We need
someone on the team and we’re going to figure out exactly what that
looks like and do the filtering, both the attraction and the filtering
that you mentioned, but also the onboarding and helping them be
successful on the team. But that kind of clarity of here’s a single
owner for this project because it really is a project and they may take
input from a lot of sources to create the job description, which is a
written thing you’re going to post somewhere that tells people what
you’re looking for in the role and about your company, but that person
is going to really own that whole process.
00:09:00 - Speaker 1: Yeah, and I’m a really big fan of having this
alignment between the person who’s eventually going to be responsible
for the person’s success on the team all the way back to writing the
job description and sourcing the candidates and running the interview
process. I’ve observed that in large companies, this often gets broken
up among a bunch of different people.
Sometimes, you know, for The defensible reasons, let’s say, but you
have the recruiter and the executive, and the group manager and the
manager, and the saucer, and the zillion people, and no one’s really
responsible, a candidate’s bouncing around through all these folks, and
you don’t get a strong, coherent, unified vision for what this job is
gonna be and why it’s awesome.
So I think we can get away with it, having a more unified approach is
the best.
00:09:43 - Speaker 2: Yeah, I’m not a big fan at all of kind of
recruiting in HR, playing a big role, especially early screening. I I
understand why that specialization makes sense.
I’ve worked with great recruiters and great HR people who are very good
at what they do, and certainly they take the weight off of the team
leads or hiring managers that have lots of other responsibilities. They
have their own specialized skills in some cases for just Dealing with
people and following up correctly and so on, but yeah, some more unified
ownership, I think creates a better experience for the candidates, and I
think it is more likely to make the whole process kind of be successful.
What does a good job description look like for you, Mark?
00:10:23 - Speaker 1: For me, it’s effective in convincing the best
candidates that they should begin a conversation.
And let me contrast that to what I often see in job descriptions, which
is speaking to sort of the median candidate and giving them as many
reasons as possible not to apply, right? You don’t paint a picture of
why the job is compelling, why the teammates are going to be great, what
they’re gonna learn, and you get this whole laundry list of, you know,
so-called requirements, many of which are not even useful. So when I’m
writing a JD I’m thinking.
Maybe I have a handful of people who are ideal archetypal candidates.
Why, when they read this, are they going to be interested in speaking to
us? And once they speak to us, you know, that starts a whole another
part of the process and we can almost forget about the JD in a sense.
But you just want to get that first conversation.
So it’s again, it’s about attracting the right candidates and you
don’t need to really care about what we candidates think, and you
don’t need to care too much about strong people applying who aren’t
exactly the right fit.
That’s a good problem to have. You’re just trying to get some initial
attraction from strong candidates.
00:11:27 - Speaker 2: Yeah, being specific so that when someone who is
the right person reads it and says, this is me, and feels compelled to
apply, but also not so specific that you, as you said, repel people.
The requirements section in particular is a dislike of mine where it’s
for example 3 years of experience with a particular technology, but I
think it’s really a certain set of characteristics in the person’s
personality and the kinds of things they’ve worked on in the past and
what they’re drawn to and the types of problems they’re good at
solving and certainly for a technical role technology experience is
first of all important to talk about.
But secondly, helps people know what the position really is and helps
define it.
If it says you’re a great swift engineer, then you know that’s going
to help clarify a lot, but saying you have exactly this many years of
experience with a particular technology in the Apple ecosystem is a
little bit too, I don’t know, just leads to disqualification for not a
good reason.
But then you always have this balance between, you don’t want to be too
vague. Because then it doesn’t speak to anybody, but if you’re too
specific, you disqualify potential good candidates, and in a way, you
don’t know who you’re looking for, right? You’re trying to like put
this beacon, this attractor out into the world and you have a vague
idea.
Hopefully that idea is based a little bit on the exercise of dream
candidates.
So this is something I like to do, which is, OK, if you could get anyone
in the world, even someone who’s completely ungettable because they’re
a celebrity or they’re busy with their own thing or whatever. Who to
be. And if you get 345 of those examples, and you look for attributes
they share, and you write down those attributes in the job description,
that’s very likely gonna, in my experience, do the job you described,
which is help attract those great candidates without having the
specificity that repels people for no reason.
00:13:19 - Speaker 1: And the flip side, by the way, of the industry not
taking this recruiting process very seriously is that most jobs and JDs
are actually not good. So if you have a really good job, if you’re
offering a genuinely good opportunity and you write a really compelling
JD, you can actually pull a lot of people out of the woodwork with that.
00:13:40 - Speaker 2: Absolutely, I always considered a good sign when
we get people applying who say, I’m happily employed, I’m not looking
for a new thing in any way, but this was just so interesting. I just had
to talk to you, something of that nature.
00:13:56 - Speaker 1: One other thing I’ll say about JD, I do think the
main role is outwards facing attraction.
JDs also are helpful internally for getting the team on the same page
about what this person is going to be doing.
We were working through this recently with the local first engineer. We
decide, OK, is this person gonna be doing protocol design and
distributed systems, or is it more like working on the clients, the iOS
client or the JavaScript client, or is it more like a just a pure back
and go engineer or is it some linear combination, or is it choose your
own adventure? And just having that conversation is good. And like to
your point about concreteness, you paint a picture about what success is
gonna look like and what they’re gonna be accomplishing, and that also
is gonna be, you know, resonant and coherent with the team is expecting,
which is good.
00:14:41 - Speaker 2: Yeah, a hugely important part of the job
description is what they’ll be working on and as specific as possible
past features, for example, that you shipped in your product that you
can link to the blog post or some open source thing that says, here’s
the sort of thing we’ve done in the past that is similar to the sort of
thing that we expect this role would do in the future.
Incidentally, I think in working through this process with our longtime
colleague Peter van Hardenberg years back, he said something that stuck
in my mind, which is he said, Ah, so I should think of hiring as being
like looking for a new guitarist for my rock band. Yeah, I mean, I think
there’s a lot to that. And if you think a little bit more in terms of
the skills matter, but you are looking for a, obviously the rockstar
idea is hackneyed, but someone who’s really going to add something new
to your unique team, and they’re gonna fill a specific skill, but you
also don’t want to be too prescriptive, and ultimately you also want to
find someone that, you know, fits in your vibe, fits in your style of
music, fits into your artistic point of view.
Alright, so you’ve got your hiring manager, you got a great job
description, hopefully you circulate internally, which often is by
itself is a reveal in the sense that either people realize they don’t
agree about what it is we think we’re hiring for, or in some cases with
larger companies you actually end up with internal candidates basically
showing up where they say actually I’d love to do that job that I
basically shift from what I’m doing right now. That can be quite an
interesting sort of internal recruiting approach.
00:16:14 - Speaker 1: Yeah, I think that’s very important. And by the
way, you can also share it externally, including with some of your ideal
archetypal candidates, because that already starts a little bit of a
conversation and there’s a little bit of a stronger relationship and
invariably when you read a really compelling job description, some
little piece of your brain becomes invested in wearing that hat.
00:16:33 - Speaker 2: Yeah, that’s true. There’s also this element of
long-term recruiting.
I read a book sometimes back, I should have looked up the citation for
the episode here, that basically is kind of a more classic business book
on hiring, but talked about.
Hiring like really senior executives, I think this is probably more like
public companies or whatever, but they told a story of someone who
worked a CEO who worked on hiring a specific person that they wanted on
the team for 10 years, and it was the sort of thing like where every
time the hiring manager would fly through the candidate’s hometown,
they would, you know, basically pay. A visit. Let me stop in for a
drink. Let me pitch you why you should join the team again. They did
this, you know, every year or two over the course of a long time, and
eventually, because so much of it is about where the candidate is in
their life, right? It really is about timing when they’re in a moment
where they’re thinking of something new or ready for a change, that’s
just really key. And so you can’t always Guess that for your ideal
candidates, especially the people you don’t know personally, but by
floating the job description in front of them, you get that little seed
planted in the mind, maybe you don’t end up hiring this time around,
but maybe a year or two later they come back and the time is right.
00:17:42 - Speaker 1: Absolutely, recruiting is a long game.
00:17:45 - Speaker 2: So that leads us to just kind of getting the job
description out of the world. There’s, yeah, sharing it privately with
your ideal candidates. There’s sourcing, which can be anything from
scouring LinkedIn to looking for people that might be a fit, to just
like, kind of thinking through your own personal networks, and there’s
direct advertisement, right? There’s job boards, stack overflow, GitHub
jobs, hacker news, who’s hiring threat is very good. How do you think
about all that fitting together?
00:18:14 - Speaker 1: Let me actually talk first about hosting the JD
so, The issue with recruiting is that both sides of the transaction, the
hiring company and the candidate, have very little information about
each other.
If everyone had perfect information, you would just go to the company
that was right for you and start the job and everyone would be happy.
The issue is that there’s imperfect information, and so whenever
you’re undertaking some work in the recruiting process, the candidate
is going to be performing a huge update in the Bayesian sense about your
quality and fit as a company.
And this is why when we go deeper into the interview process, there’s
gonna be so many important things there.
But potentially the very first thing they see is the JD.
So when I’ve had the chance, I’ve invested a lot in making very high
quality JDs not only just they were written right, but that, for
example, they were on our domain.com/. The name of the job. They had
excellent typography. We even commissioned custom artwork for our
original local first sync engineering job. And you know, some of these
things work out and some don’t, but just showing the candidate that you
are walking the walk of really caring about this job and thinking it’s
important, verse, you know, potentially you put it up on a third party
job site. It’s like, you know, your subdomain.job site.com/sh, you
know, some horrible EUID and then they go there and like the colors are
all wrong and they fill out a form, it’s like 17 buttons, you know, it
doesn’t send to me the message that you really care about this
candidate in this job, so. I think it’s worth putting some effort into
the actual posting.
00:19:39 - Speaker 2: Yeah, to me that might reflect the conventional
power dynamic between a sort of job seeker and job offerer, which is
very often the employer is the one in the kind of the position of power
and the person who is being hired is kind of hat in hand, you know,
please can I have a job.
And that is really not how it is in the tech industry, and so I would
hope if you were hiring anywhere, you would seek to try to make it feel
like a very mutual and even and balanced transaction.
I think that benefits everyone, but in the tech world, you know, you
really do need to think in terms of you’re trying to get people who
have so many options and Yeah, it’s really worth your while to do
everything you can to give them a great user experience just the same
way that you would a user of your product.
00:20:27 - Speaker 1: Yeah, and then to your question about actual
sourcing. I mean, to be honest, I’ve had most of my luck with
network-based sourcing and inbound based on really high quality public
materials. So I think Muse has been a good example of this. We’ve had
some sourcing and recruiting conversations via our network, often.
In combination with all this public material that we produce, especially
the podcasts and the memos, I can’t tell you how many candidates we’ve
spoken to who come to our local first engineer screens, like, you know,
I’ve listened to all your podcasts, I’m excited about everything
you’re doing. Tell me more about what you guys are up to. And that’s a
huge leg up versus going in cold to get up jobs or something, which is
the thing you can do and we’ve done it before, it’s just much harder.
So I think where you can do it in network and or buttress with high
quality public material that helps a lot.
00:21:15 - Speaker 2: I think the two of them do really work together,
and I’ve had good luck with paid job descriptions in pretty targeted
spaces, something like you want an Android developer, so you go into the
biggest Android email newsletter, for example, versus something more
general like Stack Overflow.
Also, conferences can, you know, you basically give a talk and you have
the requisite we’re hiring slide at the beginning or the end is also a
way to get the word out of it.
Yeah, I think you need to tell people and you need to say it publicly
and loudly. And that will get the conversations going in your network,
right? So you can try to think of everyone you want to talk to and email
them and say, here’s the link we’re thinking of hiring, but it’s
really a lot better if you tweeted it a week ago. They saw it kind of
looked at it briefly in that half distracted state that any of us are in
or. Looking through social media, they saw it and they’re like, oh, you
know, that’s really interesting, and it kind of, you know, the seeds in
their mind, and then if you email them a week later and say, hey, we
were thinking you might be a fit for this. Would you like to talk? And
they say, oh, it’s funny, you know, that’s been in the back of my
mind, and it basically opens the conversation more easily. So I think
putting those two together is a really good idea.
00:22:21 - Speaker 1: The last thing I’d say on sourcing candidates is
that I do think outbound is possible. It gets a bad rap because it’s
often very spammy coming out of these large companies with just template
emails and so on. But if you first make an effort to identify people who
are genuinely a good fit, and then to show very good proof of work in
your outreach email, like basically it’s not a template, it’s
customized to the intersection of their public profile and your job
description. I think that’s pretty reasonable, and I’ve gotten OK
responses on those.
00:22:54 - Speaker 2: And the bad version of this is the classic
LinkedIn recruiter. I still get these. I see you have written open
source projects on Ruby on Rails. I have a Ruby on Rails developer
position that may be exciting for you, and they just clearly haven’t
looked at anything about anything I’ve been doing in the last decade.
It’s all very automated, whereas, yes, if you say, hey, you know, I
came across you by the work you did on this open source project. And I
see you’ve been active on that recently, and I read more, you know, on
your blog, and saw that you’re really interested in the space that
we’re working in, and I thought I’d run this by you to see what you
think.
Something like that can at a minimum, just again, plant a good seed or
something like that, rarely gives a bad impression, and it can sometimes
produce some good conversations.
Now once you get to the filtering stage, if you’ve done a good job, you
should have lots of candidates coming through, right? And I think it’s
important here, this actually connects to a larger perspective I have on
kind of systematic searches, which I think can be applied to a lot of
things in life, whether you’re looking for a university to go to or,
you know, you’re looking for a school for your kid or you’re looking
for a home to live in or something like that, and certainly it’s true
for job seeking. And it’s true for candidates as well, which is that I
think it should be on both sides. A job seeker should be opening many
conversations with many plausible fits and then using that to do their
own filtering down to the best opportunities for themselves, and then on
the other side, the employers should be doing the same thing.
00:24:24 - Speaker 1: Yeah, and just to elaborate that, I think there’s
a benefit for the recruiting company on having some volume. I think you
want at least 5 to 10 people on what you’ve called the initial screen
stage. We’ll talk about that terminology. Just because by having a
little bit of volume, you basically get better at it. You get some
practice and you start to better triangulate what you’re actually
looking for because of the conversations with the candidate. For
example, the candidate will ask, you know, am I gonna be doing this or
this? and like, oh well, actually it’s a good question. You know,
actually it’s more like this you go up to the GD and then when you have
a subsequent conversation, it’s a little bit more dialed in.
00:24:55 - Speaker 2: It’s really important to know what you’re
looking for when you start and have clarity about that, but on the other
hand, I do often get more clarity through those conversations and
realize in some of the early interviews, oh, maybe we’re looking for is
kind of too many skills mushed together, it’s actually a little too
broad, or maybe the other way around, it’s actually too narrow and we
should really pair up with this other thing. I’m kind of realizing
there’s really sort of two things we’re looking for, maybe it’s worth
pulling those apart into two different job descriptions. You may
discover that through the process.
00:25:27 - Speaker 1: And even just the words that you use, cause again,
we’re trying to find a resonant frequency with the candidate, and that
can be made or broken just by what you call things. And so after you go
through a few of these, you find that, you know, local first resonates
better than distributed systems. OK, and now I can take that to your
next session.
00:25:47 - Speaker 2: Didn’t we for the job post where we eventually
got Adam Wulf, I feel like we even had two variations, was there maybe
like the systems engineer and the can’t even remember what we had, we
basically couldn’t decide which one we thought would be more
appropriate, even though we thought they would both feel kind of the
same slot on the team. To parallel job descriptions essentially had them
both out and we’re interviewing for both of them, right?
00:26:12 - Speaker 1: Yeah, that was a very interesting experiment. I
remember one was systems engineer, the other one might have been iOS
engineer, and like you were saying, they were for the same role.
It was this idea of someone working on a very high performance,
sophisticated iOS client.
And we had one track that we imagined, which is we eventually hired Wulf
with, which was more of a classic iOS developer who cared a lot about
performance and systems thinking.
And the other one was more like a game engine developer who was used to
building up these systems from first principles, and then would kind of
their novelty would be applying it to more of a consumer facing app. And
that was a good example of how we just didn’t get a lot of resonance
with systems engineering, cause it’s not that many game engine
developers out there, I guess, whereas we were able to find more
plausible candidates with iOS engineer.
00:26:59 - Speaker 2: Yeah, and it’s probably the same for candidates
as well, right, when you maybe apply somewhat speculatively to a job and
you kind of think, oh, is this me, is this what I want to do? And then
in the process of the conversation with the company and, you know,
understanding better what the role would be, you kind of realize, ah,
this isn’t quite what I’m looking for.
That’s fine. I think we all have to realize there is a mutual figuring
out what are we looking for. Hopefully you go into the conversation,
you’re serious and you’re not trying to waste anyone’s time by just
fooling around, but it is also a discovery process.
Which naturally leads into the next phase here, which is what I usually
call the phone screen, and this is something, it sounds like a very
small process detail, but it’s something I’m quite passionate about
because I feel that I have wasted a lot of my time and others’ time
early on by having a more heavyweight interview right at the start
because you can really read someone’s materials or see their online
profile, maybe open source work, design portfolio, whatever, and just
think, oh man, great fit.
This is gonna be great and you schedule the like 3 hour interview where
they could come in and talk to several different people in the office
and really, and I’ve been in the situation where it becomes pretty
clear in the 1st 15 minutes that how I was picturing them is not how
they are and it’s not a good fit, but now they’re kind of, especially
when you talk about they’re in your office. Sort of already there and
but it sure would be sort of pretty rude to just kind of end the
interview and you sort of feel obligated.
So, the solution here, and again, it’s the same thing for the candidate
on the other side, they may also discover pretty quickly that it’s not
what they thought. And so the solution to that. as you keep that first
contact just really low commitment, right? And so that’s the phone
screen. It’s 20 to 30 minutes, 30 minutes tops. It’s a mutual respect
for each other’s time. You’re there to make a human connection. I
don’t need to hear all your background. I already read your thing. I
don’t need you to demonstrate skills. I’m going to trust that what you
wrote down is your skills are true, and the more proof of that will come
a little later on. Right now we’re just making the human connection.
Kind of getting some initial sense of who they are and how they
communicate, they can ask me a few questions, things that are not clear
on the roll, and then that’s the end of it, regardless of whether it
was good or not, right? And if we make that habit of really brief
screens, then you can basically do more of them. Holy, that’s good for
both sides.
00:29:16 - Speaker 1: Yeah, now I tend to call these introductory chats
because they do think screen is very focused on implies filtering versus
attraction. And I do do some basic filtering in these initial chats. My
experience is that Basically asking a candidate to describe one thing
they’ve worked on and then asking 2 to 3 follow-up questions gives you
a very large amount of signal.
It’s enough signal in combination with the resume and what they wrote
in their email to determine with a high degree of accuracy if they
should move on to the next stage, which all you’re looking for is that
if you promote them to the next stage, they’ll have like a 25 to 50%
chance of passing that stage. And in my experience, I can basically dial
that in with a few questions plus the resume. And then the rest of it is
basically selling them on the company.
So again we’re under the presumption that the case we care about is The
exceptional candidate. So if it’s not a great candidate, either you can
tell that now or you eventually find out in the future, that kind of
doesn’t really matter.
But for the exceptional candidate, you know, they’re gonna have
multiple options and so you want to be basically beginning the selling
process, which is like a hard sell. It’s more like you provide the
opportunity for them to learn more about the company and the role, to
ask questions, to establish that human connection, and you’re also
beginning to understand what they value and want, like what you’re
looking for in this role, what’s important to you. What’s your
timeline, you know, more logistical stuff like compensation and location
and travel, just trying to, you know, establish the baseline on which
you’ll be basically selling this candidate in subsequent rounds.
And then I’m doing that throughout the recruiting process. Every time
we speak with a candidate is an opportunity to help them understand if
the company is a good fit. And by the way, it’s also an opportunity for
them to understand if it’s not a good fit.
This is the thing that’s really important for me with recruiting. It’s
about finding a mutual. Well fit, and I’m always really honest with
candidates about that. I’ll tell them, I’m gonna help you understand
if this is a good fit for you. And if it’s not, I’m gonna, you know,
tell you. And, and a flip side, I’m even happy to help you find a job
that is a good fit. You know, I know a bunch of other hiring managers in
the industry. I can introduce you to them. That’s a very genuine offer
that people have taken me up on. So I find that having that very
congruent stance of, we’re here to find that this is an awesome job for
you works well.
00:31:18 - Speaker 2: You mentioned here the 25% chance to go to the
next stage or hopefully on the next stage, they have, you know, that
chance of success. You can think of hiring as a funnel, same as a
marketing funnel, where at each point, more and more people drop out and
maybe again this is coming back to overemphasis on the filtering.
But one reason I do like that visualization a little bit is, once
you’ve opened communication with someone, I feel a kind of sense of
moral obligation is too strong, just say, like, through politeness, that
now they should get a clean conclusion, right? We either get to going to
the next stage and eventually that proceeds to a higher or at some point
it’s OK, one or the other or both of us have determined it’s not a
fit, the process is now over.
And one way to do this is just tooling and con on boards are a good way
to do it where you have kind of a column for source and a column for
introductory chat and a column for interview and whatever steps you have
in your process, but part of what I like something like a trello or
notion’s compound board for is there’s an automatic kind of date for
the last update. And so it’s my personal opinion, you really shouldn’t
let them set more than a week without an update. And again this is
partially politeness, it’s partially a reflection of just you’re
hiring in an industry where talent is in demand, and if you don’t keep
that momentum up, they’ve got other opportunities. So I think a mistake
I made at the very, very beginning of my hiring process, and I’ve seen
lots of other hiring managers make is the solution for people you don’t
want to continue with is you just ghost them. And of course that’s
easier to do because it’s like sort of hard to write that email or
whatever it is where you say, listen, based on what we know so far, this
is a fit, so you know, good luck and everything. It’s kind of hard to
write that email in a way, but I think you really owe it to them.
Hopefully candidates feel that same way, if they decide, I’m taking
another opportunity, or based on our last conversation, it’s not a fit,
they can do the same thing.
00:33:16 - Speaker 1: Yeah, and it’s not just a matter of politeness,
it’s a matter of effectiveness. Here’s my number one tip for listeners
of this podcast episode.
The most unreasonably effective thing to do in recruiting is to move
quickly, especially as a small company where you have the ability to do
that.
So for example, on these initial chats, if the candidate is obviously
very strong, and I know that they’re going to move to the next stage,
I’ll just tell them at the end of the call. This has gone great. We’d
like to interview you, and I’m gonna send you an email right to this
call to schedule it.
And likewise, you can do that on every step of the process.
Ideally, you try to do it the same day, like, so for example, if they
have a starter project presentation, talk about the team meets, and you
basically make a decision right there and you email him or her right
then.
And often because of time zones or whatever it needs to be the next day,
but I see all these companies, they take like a week to respond, and
meanwhile, the candidate is like they’re hired, they’re starting at a
new job, then they get this email a week later, you know, it’s like,
we’re advancing you to the next stage. Well, that’s too bad.
00:34:14 - Speaker 2: Yeah, so then you’ve got kind of interviewing and
pilot projects or starter projects, and I think interviewing is an area
that has been given very extensive coverage by kind of blogs in our
industry. So I don’t know how much time I want to spend on that, but I
would be curious your take.
00:34:31 - Speaker 1: Well, it’s funny you say that because I think
interviewing in our industry is like is completely broken and backwards,
and there’s a bunch of cargo culting and mysticism and, you know,
superstitions around interviewing, but there’s very little first
principles thinking about what is effective. So I think it’s worth
talking about.
00:34:49 - Speaker 2: Yeah, well, my take is it’s a scaled up version
of that introductory chat slash phone screen, just getting more in
depth, really trying to understand what drives them, what they’ve spent
their time on in the past, where they want to grow in their career.
And then telling them about your company, what the role is, and what the
exact team is and what they would do there and trying to just get more
and more, as you said, information for each side in order to just make
it really obvious, wow, this is such a compelling fit everybody’s
excited, let’s go forward, or yeah, to reveal that that fit just isn’t
quite there. And that of course includes also the logistics that you
already mentioned which is things like compensation and availability,
right? It may be that you’re Really eager to hire someone basically
right away, and there’s someone who says, well, you know, I’m on this
project that’s wrapping at the end of the year and after that I’ll be
thinking about a new thing or vice versa, maybe you’re on a longer
cycle and obviously compensation is something that could vary really
wildly, both cash equity. Basis on which it’s paid, you know, kind of
salary versus freelance. Now you’ve got, you know, 4 day work weeks are
becoming more popular, and, for example, in the Muse team, we have a mix
of folks doing different total amounts of working time. So, you would
just want to make sure all that makes sense and so it’s this constant
exchange of information and you’re just trying to get the time
necessary to get that exchange happening, as well as just finding that
basic ability to communicate and whether you just sort of get along
reasonably well. You don’t have to be best friends, but you do need to
find a Good way to communicate and a good sense that you’re on the same
page, and again, coming back to the shared values, shared working style,
passion for the project area and so on.
00:36:32 - Speaker 1: Yeah, and I think that’s all good for the, what I
would call the conversational piece of these interviews. I do also
typically look for a sort of subject matter or skills piece of the
interviews.
And here’s my theory on interviewing. The best predictor of future
performance is recent performance doing the same thing, which sounds so
simple, and then you have these multi-billion dollar companies doing
interviews that have absolutely no relation to the actual job to be
done.
So in order for me to get this information, I like to use two
approaches. One, which is basically the interview and one is the pilot
project that we’ll talk about. So with the interview, I do work history
inquiries. Now, yes, you get some sense of work history from the resume,
but often this is names of like companies and maybe projects, it’s very
high level. So what I ask Canice to do is just describe to me. What you
personally accomplished in your last one or maybe 2 jobs. And the thing
is, the candidate know this question is coming, so everyone has prepared
answer for the first question. The trick is you can’t prepare
arbitrarily deep in the discussion tree. Just keep asking follow-up
questions. OK, you said you solved the latency issue with the API. Tell
me how you did that, right? What was the before and after, you know.
Were you measuring the mean or median or percentiles, you know, why? And
you just kind of keep going down. And my experience is that that’s
extremely revealing on how a candidate operates and how effective that
they’ve been. I mean, honestly, I’ve spoken with candidates who, they
have a pretty nice looking resume, but you ask them about what they’ve
personally accomplished in the past several years, and it’s kind of
hard for them to come up with something specific. Meanwhile, sometimes
you speak with candidates and there’s like knocking off stuff that
they’ve done that they’ve personally accomplished, they help their
team accomplish. It’s very concrete, it’s customer impacting, it’s
business impacting, right? There’s all kinds of things they’ve done.
So I find that that’s very effective on the interview piece. Now, the
downside of that, going back to our original theory of interviewing is
that that’s not gonna be exactly the same type of work and especially
the same type of work environment as your company, and it is definitely
a little in the past. So that’s where the pilot project approach comes
in, which we’ll talk about next, I assume.
00:38:33 - Speaker 2: Indeed, if we should talk about the pilot project,
which is, I think when I started doing these, and you and I certainly
been doing them in our various shared ventures for well over a decade,
maybe more like 15 years now, they were quite unusual. I got a lot of
surprise both from candidates but also from others in our company who
would say, well, it’s not the best way to do this, and it also costs
you money, depending on how you do it.
But for me, it’s just absolutely the way to find out what it is really
and truly like to work together.
There’s actually an older blog post on this just called 8 Simple Rules
for Dating My Business. This is on the Thoughtbot blog, and they do this
exact thing where they have the one week starter project, I think in
their case, in their office. The basic concept here is that you kind of
only get through so far in conversations, and I think everyone at this
point knows that some kind of like faux demonstrations, whiteboard
coding or whatever it is, whiteboard designing on the fly is probably
not.
Very useful. So the pilot projects is the idea of we’re actually gonna
hire you on a freelance basis. We found that 1 week is a pretty good
period of time or 2 weeks part time.
This can be tricky if they’re currently employed, but I find it’s
really worthwhile to just try to work with the candidates. To find a way
to make it fit in, or we’re really going to hire you to join our team,
come to our planning meeting, pick a thing to work on, work on it
directly in our code base or design or marketing space or whatever the
role is, and then at the end kind of present. What you learned.
And of course a week is not a ton of time at all, so there is a little
bit of a rushed aspect to it, but you still learn a whole lot in that,
and then we’ll pay you for that week, because we’ve actually hired you
to do this work, and that should be just incredibly revealing on working
chemistry and their real ability to get things done specifically to your
point, specifically in your environment.
They may be really great at accomplishing something in a bigger company
where they have a lot more resources and a little team like Muse, can
they really roll up their sleeves? There’s not a lot of structure. You
gotta figure it out yourself. Everyone does a little of everything. Some
people thrive in that environment, others don’t.
But regardless, we want to see one, can you be effective and then two
for the candidate, maybe think, you know what, I don’t want to be in an
environment like this. I don’t think I can do great work. I don’t
think I’ll be happy, so it’s really real in terms of what their
working life will be like.
00:41:03 - Speaker 1: Yeah, I find that these are incredibly effective.
We had great luck with them at Hiroku, where if I remember correctly, I
think we did maybe more like 2 or 3 days, although I think the flavor
was a little bit different. They were more compartmentalized projects
like you’re working on a specific module or something.
It’s a little bit more self-contained, whereas the nature of our
business and where we’re at with news, it’s like you’re saying
there’s a lot going on. Everyone’s doing a little bit of everything,
so you need a little bit of time to sort of dig in.
Yeah, extremely effective, and again I think it’s because you’re
simulating and indeed doing the work that you’re actually gonna be
doing with the team if you were to join full time.
And yeah, I found that between 235 days, you get an incredible amount of
information, basically all that you could really use for the stage of
the recruiting process. And again, it really goes both ways. I’ve been
surprised, basically all the candidates that I’ve spoken to said that
they really appreciated the opportunity or the perspective of the
opportunity to have this evaluation period for the company.
Like I said, you’re spending the next 2 to 4 years of your human life,
40 hours a week on this thing, you should have a pretty good idea of
what you’re signing up for, and I don’t think you get that with 4
hours of interviews at the San Francisco office or whatever, right? You,
you really need to spend some time working with the team. So I think it
makes perfect sense for both the candidate and the company.
00:42:21 - Speaker 2: One thing worth noting is that a lot of jobs,
full-time positions do have some kind of trial period built in.
For example, in Germany it’s sort of encoded in law 6 months is sort of
your maximum profit site where essentially the sort of very at will,
just like this didn’t work out, you know, we gave it a try, but we have
learned through really having you in the office virtually or actually
that this isn’t a good fit and sort of both sides can walk away, but
the important difference there is that the default as you continue.
And I like the idea of a pilot project, obviously the one week is the
shorter one, but we also do a slightly longer one, and there the default
is end. That’s where we’re starting. And then we may, if both parties
decide they want to continue, they do so.
One variation on this is Zappos, which famously had or still has a 4
week training period, and then at the end, they would basically give
them a bonus to quit, basically like a cash offer to quit, and it
started pretty low, but eventually kept going up. I think it was
something like 2000. Bucks, and it’s like pretty good, especially for
some of these roles where basically like, look, you gotta really love
this and think that this is great for you and you’re gonna be committed
to a long term. And there’s this alternative, that’s cold hard money
you can have right now that you don’t have to work for, and so that
sort of like creates that natural break point as well.
00:43:44 - Speaker 1: Yeah, I think this idea of defaults is really
powerful and moving it so that the default staying doesn’t happen until
after both sides have worked together with each other for some amount of
time is the right move.
00:43:57 - Speaker 2: All right, Mark, so we’ve been through all this
effort to source candidates, maybe we’ve talked to 50 people and we’ve
been through this mutual filtering process and getting to know each
other and building trust and finding working chemistry through pilot
projects. Now we need to make an offer. We need to negotiate that, but
hopefully again you started from a sense of knowing where they are in
their life and what they need to want and similarly, you were clear up
front about what the company can offer, so hopefully that part is not
too onerous, but then you get to their first day, and that’s it,
you’re done, right? Like that’s the end of the hiring process.
00:44:38 - Speaker 1: Well, that’s the thing you can do, and in fact
many companies do do, but I think it’s a mistake.
00:44:42 - Speaker 2: Yeah, I’m just trying to wind you up. My personal
feeling is that this is the exact halfway point of the process.
The new team members’ first day is a magical moment when they’re
excited for the potential, the team’s excited, they’re excited,
you’ve just expanded your capacity maybe by a lot, especially if
you’re a small team, you know, adding your 6th member is quite an
expansion of potential, just bandwidth you can do as well as whatever
new skills and perspective they’re gonna bring to the table.
And of course you want to capitalize on that energy, but importantly it
really does take a good while, 3 months, 6 months, longer to truly reach
integration with the team. You know exactly what you’re doing, you’re
successful in your work. Usually we have a concept of onboarding, which
is a sense of, yeah, training, getting up to speed, just learning all
the systems, just getting accounts in all the systems, getting to know
how the company works, etc. And some of it is just a matter of just
getting your first projects to work on and starting to get some wins and
starting to learn your way around the project. How do you think about,
you know, onboarding and the overall ramp from it’s your first day to
you’re a productive and successful member of the team?
00:45:54 - Speaker 1: OK, there’s a lot going on here. Maybe we start
with the simplest thing, which is the logistics. I think it’s worth
having a checklist that you accrete over time of stuff that you need to
do for onboarding. We’ve even done this and even though we’ve only
onboard a few engineers.
The first engineer, we start with a blank notion page, it’s like, OK,
they can’t log in to GitHub, add that to the list, and then you do that
for them, but also in subsequent hires or trial project participants.
You have that list, and every time you find something that’s not quite
right anymore, like there’s a new account that needs to be added and
you update, you agree to list. I also think that the personnel is really
important here, especially when you’re at a little bit of a larger
company. It’s kind of different now with M, but I found that when you
have a large enough team, you have a hiring manager, who’s like a
full-time manager. It helps to have two people involved, named people
involved in onboarding. One is obviously the hiring manager, who’s
gonna be responsible for a lot of the personnel and HR and logistics
stuff and the overall success and development of the new hire, but then
also having them paired with. An onboarding buddy, who is their day to
day person, basically the person that they can ask technical questions
about, like, you know, this isn’t compiling, I can’t install a Ruby on
my Mac. If that has to bounce up to the manager who’s dealing with all
kinds of other stuff, they’re not going to get a quick response. And
you really want someone who can respond right away. And then by the way,
giving someone the responsibility of helping a new higher on board is
very healthy for the team. It’s healthy for the individual, it’s
healthy for the team. It’s like a good growing process for everyone
involved. And then there’s sort of the scope of work piece, which is an
area that I have pretty strong opinions about. My approach is to
gradually increase the scope of responsibility for the candidate up to
their capacity given their skill level and seniority. What I mean by
that is when you’re first starting out, the only thing you can
reasonably be expected to do is follow very specific instructions for a
short project. It’s like OK, you need to install our build tool chain
and compile the project and run the test. And then the next thing might
be giving them a little bit more wiggle room, but still pretty contained
and scoped out. Like, here’s a bug. We basically know how to fix it. We
know it’ll take about half a day, but you should be able to navigate
some amount of uncertainty there, figure out how exactly to fix it, what
the test should be, get the pull request written up, merge it, deployed
to production, and then eventually, The scope of responsibility is gonna
keep growing, and I measure it in basically how many days they’re
expected to go without circling back. So first might be, you know, a
small feature, you develop the feature over a few days and then you’re
circling back and you’re getting feedback or there’s a sort of
checkpoint, but then eventually with very senior candidates, it might be
a week, a month, even longer where they’re off on their own adventure,
you know, they’re re architecting a system or they’re building a whole
new Technical architecture or they’re developing a feature from first
principles, but you got to approach that gradually, because if you jump
right to that, even for a very senior person, they don’t have enough
familiarity with the code base, the team, the customers, the business,
and they’re just gonna get lost out in the woods. So you gotta increase
it gradually. But on the flip side, if you keep giving an experienced
engineer a small bugs, it’s not going to be fulfilling. So you gotta
kind of balance the difficulty with the ability of the candidate to move
up that line over time.
00:49:08 - Speaker 2: For engineers, a great source of inspiration, I
think, is open source projects that often purposely groom a list of easy
to fix, but not very important bugs in the project, and they have them
there just as an easy on board ramp for anyone who wants to get
involved. In the project, and you get that quick win and you learn what
their processes are, the code base looks like, and then you can move
forward from there, and there’s obviously equivalence for that sort of
thing for all the other roles.
The other way I would think about that kind of onboarding side of
things, even for someone who’s, as you said, very senior, they really
know what they’re doing. They have a lot of their own ideas and skills
and everything to bring to the table, but when you get into a new team,
especially a really established team with a lot of culture or if it’s a
big team with just a little a lot of people or a building in talking
about companies with offices, heard that’s still a thing somewhere
that, you know, you need to like figure out where to go in the building
and I like the metaphor of showing up at a house party. Maybe it’s
pretty busy, maybe you don’t know very many people there, but you do
know the host, and there’s a great hack, which is you can have new
people that show up and seem a little bit sort of like they haven’t
quite figured out how to settle in yet, give them a little task like
here, chop these vegetables, something very specific and gives them like
a sense that I belong here and I have my little corner of this. event
that is sort of clearly mine and I’m contributing to in some way and
then that can expand outward from there and I think there’s a version
of this coming onto a team. It’s not a house party, it is more, you
know, productivity oriented and there’s clear processes and things like
that, but it does have the same quality of you’re stepping into someone
else’s house, especially a team with a well developed culture or maybe
one that’s In some ways different from places you’ve worked in the
past, then there’s this period of just kind of, maybe you’re walking
on eggshells a little bit, you’re trying to feel it out and you don’t
know what the customs are in this strange place and you’re trying to
learn how to fit in, in addition to wanting to obviously prove yourself
and just the kind of skills area, and so that’s place where a hiring
manager or even better yet, like you said, the buddy who’s not
necessarily your boss, but just someone to help you get acclimated, can
help you with a lot of that kind of host like, here chop these
vegetables. Oh, did you know that, you know, the hallway over there
leads to here, oh, did you know if this person’s name is so and so?
00:51:35 - Speaker 1: Yeah, and that reminds me that in, especially in
larger companies, there are a lot of invisible social structures and
relationships and work flow patterns that are very important to know the
product could be written down and it may be useful to make that an
explicit part of the onboarding process.
Because what’s gonna happen is you’re gonna need to do something and
then you’re gonna need to know what the magic incantations are,
they’re necessary to do that thing at the company and you’re gonna
want to have a relationship with the person you’re going to need to ask
for help and advice.
You don’t want the very first conversation with that person to be, you
know, can you help me with this deploy. Or something that’s just kind
of weird. So I would often give social assignments, people like, you
need to go have 5 lunches with these 5 different people in the company
and, you know, ask them about their lives and worlds and, and that
really pays off down the road where you need to interact with these
people in a more work focused transactional capacity.
00:52:24 - Speaker 2: And obviously trying to create some of those in
the virtual environments for remote teams, all remote teams like ours is
a challenge.
Now we lean very heavily on team summits where we get people together in
person periodically, not as often as we used to sadly, but still very
important because you get to see someone as more of a whole person.
Um, in a way that I think can greatly grease the wheels of your work in
collaboration when it does come time to do the more transactional side
of it. And one thing we try to do is try to schedule a team summit for
people who are relatively new on the team, try to line up a summit
we’re going to have anyways with someone who’s, OK, you’ve been here
a month now or 6 weeks, now it’s time to kind of go a little deeper
with meeting everyone and spending more time on this. More human level,
not just being a square on the screen.
Even to the point where we don’t have a summit scheduled, I think it’s
important enough. We’ll just pull together a mini summit or say, well,
you happen to be close geographically to these three people, so it’ll
be convenient to get this group together in a city, and at least then
you get partial exposure to the team.
So do you have a sense of just timeline wise, what do you consider to be
on boarding or training or getting up to speed, and when do you consider
them to be fully onboarded and they’re sort of a team member that you
sort of have the same expectations of someone who’s been there a long
time, or is there such a clear dividing line?
00:53:54 - Speaker 1: Yeah, I think ballpark, after 1 to 2 weeks, they
should be mechanically onboarded. They should know how to build and
change and review and deploy the code and operate the key systems and
things like that. And then I find it takes maybe 3 or 6 months at a
larger company to be able to successfully take initiative on large
complex projects and drive them through to completion. And for a lot of
people, that’s sort of the plateau and then often though for
executives, it might take 6, 12, even 18 months before they’ve built up
all the relationships and capital to be able to execute effectively. So
it kind of depends on what your goal is, but those are some ballparks.
00:54:35 - Speaker 2: Yeah, I do think different roles require different
amounts of context. Probably engineering is one that is possible to be
given small enough scope, yeah, fix this bug in this one library, and
you don’t even need to know what the company does to do that
potentially, even though obviously you need tons of contexts to be able
to think about the architecture writ large, for example, for the most
senior or people who have been there the longest time and are making the
biggest and most important decisions.
On the engineering side, but I think design probably needs a little more
product management, definitely does when you get into leadership roles,
and typically people hired in more senior leadership roles.
I mean, it’s always tough in various ways to be, for example, a new CEO
at an established company, but the standard technique that a person
who’s good at this sort of job will do is really not do anything to
exercise their authority for could even be months. They’re really just
listening. They’re just going to meetings, they’re meeting people,
they’re listening to everything that’s going on so that they can form
an understanding of the whole organization, what the problems are, what
the strengths are, start to build those relationships, etc. before they
come in and start making moves. And whereas an engineer that spent
months before they made their first commit, I think would be, or any
kind of individual contributor that had that long, I think that would be
a pretty big flag.
00:56:00 - Speaker 1: Yeah, it’s definitely true about roles like
product management and maybe management in general. I do think with the
engineers also you got to kind of calibrate your suggestions to the
organization, to your level of familiarity and experience. You just come
in and start, you know, basically saying we should change everything. I
mean, even if you’re right, you might have a tough time. Whereas if you
take the time to build these relationships, to understand the code base,
to get successful small wins, you have a lot more credibility when you
go to do that.
00:56:28 - Speaker 2: Yeah, one last little area to touch on and I think
would be more maybe at home in a discussion about management, but I do
think feedback, explicit feedback to people, particularly when they’re
pretty new, is important.
So the hiring manager is the one who ultimately is responsible for them
being successful, and that does include making an evaluation of whether
they have successfully onboarded at some point. And so I’m a fan of
trying to put a couple of things on the calendar. Here’s some written
feedback and here’s just really directly, you’re succeeding at your
job, keep going, or you’re struggling, or, you know, worst case
scenario, your job is at risk.
There’s a few failure states you see in companies where, you know,
everyone’s busy all the time and Part of the reason you’re hiring is
because you want more bandwidth, and so that can lead to things like,
for example, not moving fast enough with the recruiting pipeline, more
on the front end, because, well, you’re really busy, that’s exactly
why you’re hiring, and so you don’t have time to follow up quickly and
therefore you lose candidates.
But maybe at this stage, you think, oh, phew, we’ve got this person
hired, I can relax now, this huge project that was taking all my time, I
can now get back to the things and now they can be a net contributor.
And that may be true, but what can also happen is that they’re not
really fully on boarded yet. They need really more guidance to be
successful, and then as a busy team leader or manager or whatever it is.
In a way, because they’re not getting situated well, it’s easy to
almost like ignore them or in the worst case scenario, sort of lose
faith and not even realize that.
And I try to like look for that in myself. If I feel like I’m losing
faith or have this sense that they’re not a great contributor when
they’re not even really fully on boarded, then that’s really a time to
give it more attention. And of course, there’s a whole theory of
process around, you know, if someone is struggling, how you help them
improve, or eventually could lead to them getting frustrated and
quitting, could lead to you firing them. There’s this whole kind of
euphemism around managing out, which is when it just turns out that even
through all your hiring process, you still didn’t quite find the right
fit, and so now you need to have them leave the team in some way. But
the really important part of this is the feedback along the way, and
that’s where I think it is good to have some sense of timeline or some
sense of, certainly when onboarding is complete-ish, but also a sense of
when you really feel they’re part of the team, they’re successfully
embedded, and yeah, I think that can take 6 to 12 months for even in the
very good case, it just takes a lot of time to build all the contexts
you need to be successful.
00:59:07 - Speaker 1: Yeah, it’s tough. It’s a tough job, it’s a
tough process, takes months. Only a very small percentage of people you
speak with are gonna actually work out in the end, make it all the way
through. But again, it’s so important. Maybe the bright side here is
that Because the industry is so, let’s say, inconsistent about
recruiting and talent, there’s a great opportunity to really improve
your business and by the way, to improve the lives of the candidates who
find a job that’s a better fit for them. So I think it’s worth
investing a lot in and thinking carefully about it from first
principles.
00:59:40 - Speaker 2: Yeah, and for me coming back to fitting into
something holistic that you’re really building a team, not just hiring
or recruiting this one person, and for me that comes back to kind of
something very core to why I’m in this business at all.
Of course I want to make great products that say something unique about
the world and hopefully improve the state of software and computing in
the internet in some way, and I want to serve customers and have a
functioning business, but really a huge part of That for me is the
feeling of being on a really functional high impact team that shares
values, that trusts each other, that has a balanced set of skills that
all work in tandem together and just that feeling of cranking away on
that shared goal and then you’re all pushing hard and Sweating and in
some cases, not quite working late nights, but let’s say just like
putting a lot of your spirit into a lot of your mojo into it and then
having that result in that kind of Christmas morning feeling when you go
to ship a new feature or a thing you’ve been working on and that sense
of we did it together and that sense of being a team is a huge part of
what I’m in it for.
Right on. 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. And Mark, it’s been a fun journey so far, getting to 6,
and you know, we’re a slow growth team, but maybe 7 or 8 or even 9 is
in our not too distant future. And on one hand, I like being a small
team, but on the other hand, you know, having new people show up to your
party is a lot of fun.
01:01:23 - Speaker 1: Yeah, here’s to it.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: I think every platform kind of has this tipping
point where you start to see like, hey, this feature, this product is
getting a lot of traction, and people building on any platform should
realize they are doing R&D for the primary platform at all times. Every
feature you release, every experience you have is an opportunity for the
original platform to be like, hey, that’s a great idea.
00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for
deep work on iPad and Mac. But this podcast isn’t about me use the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Adam Wulf.
00:00:43 - Speaker 2: Hey, everyone. And joined today by Joe Watkin.
00:00:47 - Speaker 1: Hey folks, great to be here.
00:00:49 - Speaker 2: And Joe, you have an interesting background with
creative tools including GitHub and Abstract, you’ve had your own
startup doing calendar slackbots and other calendaring things, but
before we talk about all that, I’m very interested in your side project
ballot share. Can you tell us about that?
00:01:06 - Speaker 1: Oh yeah, yeah. Ballot share is a is a labor of
love.
It’s much less of a business than a fun project, and it really just
centers around helping people get more information when they’re about
to vote.
And so, People usually want to vote for one or two things when they hit
a ballot, but it’s all of the minutia stuff that people don’t really
have a really good sense of what to vote for or who to vote for on
really local issues, but those are the stuff that really, you know,
impacts them. And so Ballot share is just a site where you can see
who’s endorsed things all the way down the ballot to like your local
city ballot initiatives. And you can also create your own endorsement
around things that you think are important and share that with friends.
So the most common use case we see is people say, oh, like I have a
friend who’s really plugged into education, so maybe I could ask them
who to vote for for the school board president. And so they send you
their endorsement and you kind of see it in a grid where you can kind of
compare all of the endorsements that you want to compare. It was built
for the last election cycle and we’re hoping to revive it again for the
midterms.
00:02:14 - Speaker 2: I really like that idea of a sort of using your
trust network if that’s the right way to put it.
Maybe we get some of this implicitly, you know, there’s people I follow
usually like substack where they do political analysis and to some
extent I’m sort of trusting if I’ve come to trust that their analysis
is good in some cases it’s that I’m reading their analysis and better
understanding the issue, but in some cases it’s that I go, OK, this
person.
Seems to be pro this thing and I basically trust them, so therefore,
I’m gonna kind of outsource that decision a little bit, especially for,
as you said, all these finer details and local things that maybe you
can’t deeply research each and every item.
So it feels like it’s naturally what people do anyways. So as a tool to
help you kind of reach that.
00:02:59 - Speaker 1: Yeah, yeah. A lot of people end up making like
Excel sheets and then sending them around.
And it’s actually kind of funny, we noticed that it’s not just wanting
to know who endorsed it, it’s who is against certain things.
So when you see like, hey, this group is against it, you’re like,
that’s surprising, why? And sometimes it takes like, hey, of the 10
ballot initiatives, 6 seem like everyone is in agreement, but then like
maybe 3 are kind of like up in the air. And so you, those are the ones
that you personally investigate. So it kind of just puts more time to
the ones that you think are actually worth the the decision to make sure
you get it right.
00:03:36 - Speaker 2: And tell us a little bit about your background.
00:03:39 - Speaker 1: Yeah, so I’ve done a lot of work in the tech
space, but it’s not always specifically on the tech side. So my
background is I came into tech via sales actually. So I was hired at
GitHub as one of the first technical minded sales people, and GitHub was
a very weird beast where there were no managers and you kind of like had
to understand how to do a pull request to like even do anything in the
company. So, I originally did Git Up sales, focused on the enterprise
clients, but switched over to BD at GitHub, maybe my 2nd or 3rd year, as
just a hugely undervalued piece of the business.
00:04:16 - Speaker 2: And I’ll briefly unpack that BD stands for
business development, which I think itself is probably not a super well,
in my experience, it’s not even a super well understood title slash
function, so maybe you want to briefly describe what that is.
00:04:31 - Speaker 1: Yeah, absolutely. BD means so many different
things. It’s kind of funny. I think a lot of startups tend to use BD as
just another name for sales directly, like generating revenue and
talking to customers.
At GitHub, it was a little bit of a catch-all, so I was running sales
partnerships where we partner with companies like Ubico and get more
people using two-factor keys, but it was also partnering on the
technical side. So working with companies to maybe build a plug-in, and
specifically my charge was everyone who’s using the API helping them do
their job better.
And at the time it was mostly just like a ragtag group of maybe a couple
100 people using the GitHub API. They had a very open, very public
permissionless API at the time, so people just, a lot of researchers, a
lot of students, but then like a handful of companies who are trying to
build a business. So my job was a little bit more. Focused on getting
that group of people to be more successful, and the sales partnerships
happened, they were just much less of a focus, and it was a small team,
we maybe had 6 people max, so we kind of did a lot with a little.
00:05:40 - Speaker 2: And you had the same title at Abstract, if I’m
not mistaken. Tell us about that experience.
00:05:44 - Speaker 1: Indeed, yeah, Abstract is a funny company. They do
version control for design files, and BD at that company was much more
around product partnerships and mergers and acquisitions work, M&A work.
And so we didn’t do any kind of like sales partnerships. We
specifically focused on anything that would help the product be a little
bit better, and then kind of fielding the requests and inbound we were
getting from interested parties around M&A work. And so that ended up
being a lot of work when we got acquired by Adobe, but it was a pretty
fun ride as well.
00:06:19 - Speaker 2: And it seems to me version control is by
definition part of a tool chain, part of a stack, so those partnerships
and integrations are crucial because that is the whole sort of reason
for existence for the tool, and I assume there’s the technical
integration, but then making those business partnerships where you’re
doing something together, maybe that’s co-marketing, but maybe it’s
also you’re trying to serve the same set of customers together even
though you’re two different companies making two different products
just from the outside it seems to me like that would be a crucial
function.
00:06:49 - Speaker 1: Yeah, it’s definitely an important one. In both
GitHub and the, you know, abstract case, these are part of a stack like
you mentioned. People are considering entire tool chains, and so we’ve
got to work nice with everyone and also try to help the group itself be
better cause I think there is this constant struggle in the sass world
of, you see companies who want to go single suite and company offer
everything under the sun, like an Atlassian or Salesforce is another one
of those.
00:07:16 - Speaker 2: Microsoft is the absolute king of this, right? You
sign one contract, and you get a whole suite of mostly mediocre
products, but it’s OK because they fit together and, you know, you
could kind of buy one time and everything you need in the software world
is kind of taken care of.
00:07:34 - Speaker 1: 100%. And then you see the opposite swing where
it’s all best to breed, where it’s, hey, I really care about getting
the best tool for this, even if it costs more. And we see companies
swing between the two quite often. So whether it’s cost related or
maybe it’s, you know, new leadership, it’s like, hey, we really care
about developers, let’s break out of this like low cost tooling and now
give them like stuff that they want to use. So in both cases in Abstract
and GitHub we were kind of managing in the breast of breed world where
we were working with partners who are, you know, all trying to serve
similar and shared customers.
00:08:08 - Speaker 3: And an abstracts case, if I understand right, the
design files are mostly probably opaque binary to some degree, and so
they would not fit very well in a git style version control, and so
that’s where the abstract steps in for that really special case of
potentially very large, very binary. Difficult to diff files, is that
right?
00:08:31 - Speaker 1: Oh yeah, absolutely. I love talking about this
cause it’s like real deep and kind of amazing that as you exactly said
the Git is more suited for plain text files and You know, there are
things like LFS and Git that, you know, have pointers and allow big
binary files to be version controlled, but it’s really hard. And so
this is exactly what Abstract it, is that they saw Sketch was market
leader, but they couldn’t solve this one piece around versioning
because of these big binary blobs, and so they created an ingenious
solution that actually did use Git on the back end and stored this
enormous corpus of design information. And was able to kind of parse
through the binary and pick up changes. So, at the time it was
revolutionary, you know, there was literally nothing else that did this.
And so they built a very strong business on that kind of like
breakthrough in being able to take a workflow that worked with
developers and apply it in the design world and give designers just like
a huge amount of new workflow capability. You know, they could do
branches, they could do merger requests, a lot of the same things that
developers have used.
00:09:40 - Speaker 3: Yeah, that opens up so much more freedom. I’ve
worked with designers running up against this exact same problem,
probably, well, long time ago now, over 15 years ago, but it was, it was
exactly this problem of there’s one blessed Photoshop file and if that
gets messed up or there’s the classic version 1 version 2, version 2
final. Nightmare.
00:10:06 - Speaker 1: Final final, yeah, absolutely. I mean this is now
obviated by all the web tools like a figma that, you know, are building
versioning, just like a Google doc, you know, saving every stroke, but
at the time when everything is desktop based, like, these are
intractable problems, so it’s kind of interesting to see how The world
moves into a different medium that solves it, but then introduces other
problems, like now you’ve got multi-user collaboration real time, and
that’s like, you know, a big headache, but also like a huge
opportunity, so there’s always something fun to be worked on.
00:10:37 - Speaker 2: I believe that the developer workflow that is
Encoded through Git and GitHub, which is a more asynchronous and the
merger quest as a bundle and being able to look at diss.
Obviously that whole thing is way out of reach for the vast majority of
people in the world.
But I do think a version of that probably can and should be part of
almost every kind of creative tool, certainly for design tools, again,
as you say, we do see that in the real time collab and the figmas and
sketches of the world.
I think you see this, one reason why Google Docs is really popular with
writers is they have a really good versioning system or good versioning
relative to the writing tools still. Pretty basic compared to what
developers are used to, but where you can see new changes when you come
to a document, you can look at a history, and critically, you can choose
which changes to merge or reject, or have a comment this thread that is
based on a change, right? That’s one of the biggest, I think, powerful
abstractions in the mental model for something like Git, which is based
ultimately on patches, which is you can talk about a diff as its own
thing separate from the resulting code. And so that results in poll
requests and then essentially code reviews and discussions around that.
And I think probably most creative tools and fields could benefit from
that, but the way those tools work for developers, it’s just way too
heavyweight and complicated for most people.
So, stay tuned. I can switch actually has some research tracks going on
this, so I hope you’ll see some essays on the topic soon.
And then I think you heard that time zones are one of the easiest and
most fun things to do in programming, which is why you’ve worked on
several calendar products as your own startups. Tell us a bit about
that.
00:12:19 - Speaker 1: Oh yeah, my latest venture was called Eventbot,
and it was a Slackbot that provided a calendar, basically behind every
single Slack channel. And this is my 4th real calendar startup, and I’m
just a glutton for punishment here. I think that In general, I like the
calendar space because I think it’s interesting to build tools around
how we use our time. Like I think if you can make that slightly
optimized for people, it has a huge ripple effect.
But I do think it is a brutal industry that where businesses are, you
know, sitting in a large graveyard of failed to ups, so I’m not
ignorant of how crazy that world is, but it was a fun project.
I think we saw slack growing at a tremendous rate, you know, I’ve seen
a lot of different approaches in the calendar world and me and my
co-founder really saw like, hey, we could build this. tool that provides
a really important niche within Slack, and, you know, maybe it can grow
bigger than we think and we can, you know, put it into other areas, but
we just sunset eventbot after 5 years of growth.
It’s been a fun ride, but I do think that the business itself wasn’t
able to sustain the amount of work required to keep it going.
Like as you said, time zones are crazy. Little known fact, there are
thousands of time zones, not even just the familiar ones. There are many
Cities that choose not to obey daylight savings times, laws that are
passed on a monthly basis that change how you have to calendar. So that
part of the business is super boring and extremely frustrating for
developers who have to try to keep up and make sure that they’re
current.
00:13:58 - Speaker 3: I think calendaring is really interesting because
there’s a built-in moat for any new business, and if you can swim
across the moat and build a business, then to some extent you’re safe,
but it’s so easy to just drown in the middle of the moat with all of
the complexity of time zones and recurrence rules and invitations and
It’s just a nightmare of Minutia that just drags you down by the heels.
00:14:33 - Speaker 2: That’s right. Well, I forgot you spent 5 years of
your life working on Fantastic Cal. I did pretty successful kind of
gooey calendar, so you’re very familiar with the pain there.
00:14:42 - Speaker 3: Yeah, my first startup was also a web calendar
back pre-G Google calendar days, and I’ve made some pretty fantastic
slash horrible decisions in learning that, just kind of walking in
naively into the problem space and making choices that I instantly
regret. Lots of bullet wounds and scars in that space.
00:15:06 - Speaker 1: Oh yeah, there’s lots of strange edge cases in
the calendar world, you know, being able to even have a consensus of
what is now, what time is today, like, these are things that when
you’re talking to users across the globe that the internet affords us,
have just so many edge cases that we have to deal with, but Yeah, I do
agree that I think building on another person’s platform has a ton of
benefits, and we used a lot of them when we were building a bot, you
know, primarily distribution was huge. We were early on in this slack
marketplace, and so when we were building, we were finding users coming
to us, which, you know, as a business that solves a major, major
problem, just getting people to care or even know you exist.
And in previous startups, you know, you have sales motions, you’ve got
marketing efforts, and here you kind of at least, if you can solve that
piece, you can focus more of the efforts on product, on delivering
unique interesting value to customers. But like you said, there’s lots
of kind of catch-22s in that bargain.
But in the beginning days for us, we found it to be extremely valuable.
We started with a free product that was truly broken. Like, I was super
surprised when people had used eventbot to begin with. We had a calendar
product where you could create a start date and time for a meeting, but
you couldn’t create an end date and time. We launched it without that
feature because we were not even sure what we were building, and we got
some really, really gracious folks who were like, oh, I wanted a
calendar built for Slack. You should build this. And we use, you know,
the community who was adopting a free broken product to help us improve
it and actually put an end time, and then subsequently actually really
improved the product, but it was a blessing to kind of get user
traction, even at the early days.
00:16:54 - Speaker 2: And I was sorry to see it shutting down because
I’d been a user earlier on, but I was impressed by your, I guess it was
an email or Slack message. I can’t remember where I basically
described, hey, you know, we’re sunsetting this product. Sorry about
that. Here’s exactly what customers can expect, and I think how to
gracefully. Set of product which you know guess what does happen in the
technology industry and there’s lots of ways to do it that I think are
not very conscientious of the needs and even feelings of those end users
and customers and there’s ways to do it that are more graceful seems
like seems like you manage the latter.
00:17:29 - Speaker 1: Yeah, no, I appreciate that. I think I’m probably
like you all have been on the other end of that, where you get an email
saying like, hey, this service is shutting down, and you’re kind of
like, uh, like the world is worse off, and we at least wanted to make
that pain a little bit less, so, you know, we started making all the
features free, so people can kind of export data. We gave customers
months and months of notice so that they kind of knew, but in the end,
You know, we realize that we’re stewards of other people’s data,
right? And so if we’re going to be cutting our service, then we don’t
want people to feel like, hey, I made this investment and now I don’t
have my information anymore.
00:18:04 - Speaker 2: And on top of everything we talked about, somehow
you managed to be a teacher inside of all of this. I don’t know where
you find the time.
00:18:12 - Speaker 1: Yeah, neither do I, actually, it’s kind of
funny.
Teaching is something I stumbled into 2012.
Actually, while I was building a different calendar startup called
Calico, way back in the day, I ran out of money, and I started to, you
know, think about what I could teach, and I just graduated Berkeley’s
grad school, so I was like, well, you know, let me go back and Try to
teach something I know, which was, I just learned how to code, so I
taught an intro to code course. And, you know, at the time, intro to
coding and boot camps were like all the rage, so it was a pretty well
received course. So I’ve now taught two courses at Berkeley for 10
years. I’ve taught an intro to code course for non-technical people.
Which is really like a primer into how not to sound stupid in front of
developers.
00:19:02 - Speaker 2: I think that’s the, that’s the primary reason I
think people take my course, that is to say, people that want to, they
work with technical people adjacent to them, maybe similar to like a
sales role, for example, and they want to be able to speak the language
and interact and kind of reason better about that, not necessarily get a
career as a software developer themselves.
00:19:20 - Speaker 1: 100%, yeah. I think the largest percentage of
people who take the course are people who want to transition into
product management, and they’re working, you know, day to day with
engineers and they want to understand real life expectations, like, how
does this code work and what are the restraints and constraints that I
have on my job.
It’s a super useful course that we’ve got fine tuned to make it be
very practical, which is not often the case for courses in academic
institutions, but, you know, we we try pretty hard.
And then the second course I teach is sales for startups, where, you
know, I believe that sales is just an incredibly powerful skill, whether
you are, you know, at the startup phase and a founder trying to sell
people on the company, on the vision, and, you know, the funding, or
you’re selling to customers and trying to get them to make a purchase,
so.
The two courses I teach are really intended for folks to have an ability
to do something in the startup world.
You’re either building something or you are selling something.
But if you wanted to join a startup, I’m hoping that, you know, you
take some of these courses and you feel like, hey, I can join this world
of startups, I don’t need to necessarily go to a big company and try to
like find a niche.
So yeah, it’s been fun. I definitely enjoy it.
There’s a long story of like how I feel teaching, especially these past
few years where it’s been, you know, much harder, remote. I think every
semester we’ve had a fire, an active shooter, smoke, virus pandemic,
like, it’s been a crazy past 5 years, but in general it it gives me a
lot of joy. I think something that I don’t think I can replace anymore
in my life. It’s a really fun thing I get to do.
00:21:00 - Speaker 3: I think those are really interesting courses
because you’re teaching kind of each side of the company about the
other side of the company. You’re teaching the non-technical folk.
Here’s kind of the problems and the struggles that they have, and
here’s how that side of the technical people function, and then also
helping teach the technical people. By the way, this is what sales looks
like. This is why the other side of the company is a lot harder than
just Sitting behind a desk and telling you what to do with a product
sheet and timeline.
00:21:27 - Speaker 1: Yeah, I agree. I think it gives the other side a
little bit more respect for these roles and what they do and what they
bring to the companies. It’s also a lot of fun to teach.
00:21:36 - Speaker 3: Building that empathy within a team, I think is so
important when you have an extremely small team in a startup, so that
everyone knows the importance of everyone else’s role and
responsibility, and you end up, I think, just so much more efficient
than a brilliant engineer who doesn’t understand sales and customer
needs, or someone who’s really in touch with the customer, but has no
idea how long it takes to build particular features.
00:22:03 - Speaker 1: Yeah, I think it creates better entrepreneurs as
well.
Once you start to realize, like, hey, if I have to look at this idea
through the sales lens before I start, like, is this a good idea? Does
this have legs, you know, on the technical side, on the business side,
channel, marketing, like all of those things are really great to think
through early on. So hopefully I catch people while they’re still, you
know, in school and kind of incubating things. And I’ve gotten really
great letter, you know, this is off topic a bit, but I continued to
teach now for a decade because I get these incredible emails where
they’re like, 5 years later, someone will be like, hey, I just realized
that like, I learned this thing that I’m using, like, in my job. I
learned it in your class, like, awesome job, thanks for, you know,
helping me out, or I’ll get people being like, I have an interview next
week at this company, like, I think I know what these depth tools means,
but like, can we chat about it? And I’m like, this is amazing, this is
a different level of impact. So it gives you a lot of satisfaction on a
long term basis.
00:22:58 - Speaker 3: Yeah, that’s really rewarding.
00:23:01 - Speaker 2: So our topic today is building on platforms, and
especially building a business on a platform.
And we have some interesting collective experience here in this group,
Joe, you’ve been on the kind of platform provider side at GitHub,
you’ve been on the platform, let’s say, consumer or developer side at
Eventpot or building on the Slack platform. Obviously, Wulf, you’ve
been on the various Apple platforms in different forms for a decade,
more than that. So, I thought it would be a good chance to compare some
war stories here and understand better what it means, what sort of
trade-offs you’re making when you do build for a platform. But as
always, I like to start with a definitions, I’d love to hear from you,
Joe, and then maybe from you, Wulf, when you think platform, what does
that mean to you? What are some that you think of as maybe good or bad
examples, and what does that mean for a business?
00:23:54 - Speaker 3: When I think of platform, I think of A company
with existing customers that wants to let other companies have access to
those customers. And somehow takes money from both sides. And so it it
ends up being most good for the platform provider. And then secondarily
good for the companies that get access to those customers.
00:24:21 - Speaker 1: Yeah, I think that the customer focal point, I
think it’s probably the best starting point because, you know, whether
it’s a product or some sort of just customer relationship, that’s the
value that they can bring to other ecosystem partners who want to see an
opportunity, and I’ve talked to a lot of larger companies that are
considering just creating an API itself, like that is a starting point.
And part of the reason they do it is, you know, a product can only fill
maybe 80 85% of any customer’s needs, but there’s always gonna be
those edge case requirements that might not be in the company’s best
interest to build, but you still want your customers to be happy. And so
I think an ecosystem provides the ability to have happier customers
while maybe ceding some part of the pie or the product portfolio to a
third party.
00:25:11 - Speaker 3: Yeah, and ironically I think in seeing that to a
third party, you almost Entrench yourself to your customers, because now
the customers to leave your platform have to leave not only you, but
also all of these other extra companies that are building on your
platform. So it’s a lot more difficult for me to walk away from Google,
because Google is everywhere and everything integrates with Google.
Yeah. And similarly for Apple, it’s really hard to leave Apple because
of the iPhone and the Mac, and the App Store, and the TV and the, you
know, etc. etc.
00:25:44 - Speaker 1: Yeah, it really creates a second network effect,
in addition to whatever product, you know, pull you have primarily, it
adds an entirely different layer of, you know, wanting to stay, and, you
know, there’s lots of times where maybe the primary product is, you
know, maybe lacking, but the ecosystem is super strong, and so it keeps
people engaged and helps people really feel like, oh, I can’t leave,
where else can I get these very customized ecosystem tools, and it’s
hard to build. Once it’s built, it’s a machine.
00:26:14 - Speaker 2: The platform play is one that, you know, investors
love as a holy grail of money printing machine, you know, Microsoft in
their glory days, the Windows glory days was probably one of the most
prime examples of this, maybe even to your point, Wulf, where it’s not
necessarily that people loved Windows, the operating system, or would
have chosen that above other choices available in the market.
It’s just when all the programs you need run on it, of course.
You’re gonna use that, and then, of course, that’s also a nice
circular thing where if you’re a developer, you, of course, want to
build for where your customers are. And when I think of platforms,
obviously operating systems like Windows, iOS, Mac come to mind. The web
is sort of a more open, loose collection of technologies that does
represent a platform. And then maybe some more recent examples that are
maybe more specialized might be something like Shopify or WordPress,
right? Building a WordPress plugin or building a Shopify app, there’s
actually quite a lot of possibility there, especially for a small
developer within that ecosystem, and you can find customers that you
would not be able to find if you were building something standalone.
00:27:22 - Speaker 3: Almost makes me think there’s a Maybe a gradient
between an application that has plug-ins and a platform that has apps
like WordPress is an interesting example where it is a platform, but
it’s also just an app that I can install on a server and kind of do my
own thing with.
00:27:41 - Speaker 1: I think you are onto something where there is a
spectrum of how the integration happens, you know, there’s platforms
where you don’t need to even know who’s using the platform. It’s just
you provide the surface area and other people can build on top, or
there’s something that’s deeply integrated where it’s like, you know,
in the user interface. We saw this at GitHub where we had a lot of
people who used Chrome extensions that like injected UI into the screen
and It was weird for us to consider, like, are they plug-in partners
because they don’t really talk to us, but they are in our customers'
eyes, so we have to care about that, but I do agree there is a spectrum
there.
00:28:20 - Speaker 2: Well maybe that’s a good chance for some
storytelling here. So yeah, GitHub, you helped build out the
marketplace. What was the drive for that and what was that experience
like? What did you learn on the platform creator side of the equation, I
guess.
00:28:33 - Speaker 1: Yeah, so the GitHub Marketplace was a multi-year
kind of dream of mine, and uh to be honest, I think it’s because
working at GitHub made you really see how undervalued, underestimated
developer tools were as a broader category, and this is 2010.
In terms of context. So we saw that people were using developer tools
like GitHub, but we knew that we were going to be a best of breed
company. We were going against the like single suite approaches.
And so, to really shine in a best of breed, you need a lot of breed,
like you need a lot of people.
You want to let a 1 1000 flowers bloom in that space.
And devtools were a difficult thing to grow. And so, in general, they
get a marketplace was kind of like a long term intention of how do we
grow the DevTools space with the position and kind of responsibility
that we have as being on the version control side, which is a very base
layer for a lot of developer tools. So we were building a platform that
really intended to help developer tools blossom.
And take away, you know, some of the parts that they really didn’t want
to do, which was sales and marketing.
So, we can definitely talk a little bit more about how that happened. It
took a couple of years internally to get some buy-in and then externally
to build the trust, but it was a really fun project which now, you know,
get up marketplace is thriving and booming, so I look back pretty fondly
as like, ah, cool, we helped do that. That’s a pretty nice feeling.
00:30:07 - Speaker 3: Yeah, one thing I’m really curious about is That
step from 0 people on the marketplace to 1 person on the marketplace,
right? Just getting that very first use case and that very first
business to buy in and get going, to start things off. What was that
like and what was the process to kind of maybe find that business or
make sure that you had enough there for them to integrate with? What was
the minimum viable product, so to speak, of A platform.
00:30:40 - Speaker 1: Yeah, I think that’s a really good question
because we started by having an API that people were already using, so
people were able to get information in and out of the GitHub system. It
wasn’t super well loved in terms of resources, but we had people using
it, and there were businesses that were created, they were just very,
very small.
And so that the primary example when people think about the GetUp
ecosystem is a CI tool, a continuous integration tool like Travis or
Circle.
And for folks who are not familiar with what CI tools do, they basically
do a check on your code. So they are looking at your code to see if
there’s any errors, does it pass the test that your own developers have
written, and it just gives you back like a hey, pass or fail. And so
those tools existed in the market and used our API, but they were
basically totally separate entities. People would come to GitHub, buy
GitHub subscription. Use it, and then go to these independent websites
directly, you know, find them, hope, and look for a logo that said, hey,
integrates with GitHub, and be like, OK, great, like, maybe I can also
use this in addition to my version control software. And so, my first V1
was really to create something very lightweight. At GitHub that allowed
some traction and kind of proof of value to exist, to kind of build
towards this marketplace ideal. And so our V1 was really simple and
it’s kind of embarrassing, but we just did a simple static page. It was
like GitHub.com/sh apps or app directory. There was a bunch of users who
had apps, so we had to change the URL, but the original static web page
was just a single page where we just hot linked out to every single tool
that we knew that was reputable enough to be recommended, but also
integrated with GitHub directly. And it was an important first step that
I kind of didn’t really appreciate at the time. It was just mostly
like, hey, how do I make progress? Well, this seems like a good way. But
it accomplished two big things. One, it gave direct traffic to these
providers. So, you know, Travis CI, Circle CI are common ones. They were
starting to get a lot of traffic. You know, GitHub at the time was a top
10 website in the world by traffic. And so us redirecting even. In a
small sliver was able to give them, it’s a huge boost for devs who, you
know, are looking for CI tools. They’re like, well, why don’t I start
here at this GitHub app page and then go out. So we were getting a lot
of goodwill by those companies who are getting free traffic and likely,
you know, a lot more revenue from it. But it also served the purpose
internally, where we had, you know, lots of management to convinced that
it’s worth building a bigger marketplace, because now we can see how
many people click through. We actually requested from the folks who are
on that static page, like, hey, could you send us a report at the end of
the year on like, how many people bought subscriptions through you?
We’d love to know cause we’re gonna put in a referral link, so we
wanna know how much it converts. So it was twofold. It was really
helpful from the inside to kind of validate like, will people click,
like, and if so, which partners will they click on, like which ones do
they not care about? And on the external side, we gave people almost a
full year where, you know, we just drove traffic. It was also just a
really good time. Once you start driving traffic to people, then they
start wanting to talk to you more. They’re like, hey, can we be higher
up on this marketplace, and what are the rules and what can we do to
help? Do you guys talk to your sales teams about us? I guess that’s a
third benefit I kind of failed to mention is our sales teams loved it.
They used it in like every sales pitch. They pull up the page and
they’d say, hey, listen, you’re not just buying a single best of breed
tool, you’re buying into a network of tools. And showing them this kind
of wide world that existed. So, it was a good use case for a lot of
people and really low lift. We’re talking just a flat HTML page with
some links and icons, so it was great.
00:34:36 - Speaker 2: Yeah, that points to one of the first big benefits
that comes to mind for me with building on a platform, and that’s
distribution.
And that could come in the form of direct traffic driving, but it could
also come in the form of, I don’t know, you’re making a plugin or an
extension to a thing the customer already knows and you benefit from the
fact that they’re already a user or a customer of X where X is GitHub,
and so you say, OK, so this works with a product I’m already using, and
so it’s easier for me to imagine how that plugin or app or integration
fits into my life. So, just by itself, you’re already benefiting from
that, but then there’s the additional huge distribution benefit of
having some kind of a marketplace or an app store, even this static site
you mentioned, where you have really direct distribution channel right
out of the box.
00:35:26 - Speaker 3: That story is really a perfect summary of how I
think about two-sided markets and platforms like that, where GitHub was
already extremely valuable to the developer, just as source code
repository. But then adding in those extra partners, it becomes
exponentially more valuable for those developers and exponentially more
valuable for those partners, where it’s really a multiplying effect.
When you bring in those extra companies, those third parties, make it so
much more valuable than just the product alone, and it’s even much more
valuable than me going to GitHub and then me going to Travis, but having
that integration makes both of those. More than twice as valuable when
they actually integrate and talk to each other.
00:36:15 - Speaker 1: Yeah, it was definitely good timing for the
developers themselves. We had a lot of devs come to us, run these big,
you know, annual conferences that could have at the time. They’d say,
hey, like, I want to build this business, but like, nobody in our team
wants to do sales. We’re like, OK, we totally understand that. Like, we
as a company of dev tools, like, as developers, we understand not
Wanting to take care of this business, let us help you with that piece,
and at least make that a lot easier. And then you focus on building the
best developer tool and trying out something. So, I do think that
you’re right. It helps multiply efforts. And then if you have an app
store, it attracts more people to want to start a developer tool or at
the time, you know, a plug-in. And so it creates a bit of a flywheel in
terms of creating more people in the ecosystem, which attracts more
people to the ecosystem and really. Making the whole better bit
stronger.
00:37:09 - Speaker 2: And maybe if I can offer a similar origin story
from my own experience, maybe just a few years before you were working
on the GitHub Marketplace there, Joe, I was working on the Hiroku add-on
system.
Oh yeah. And this is basically a way that you can, yeah, you have the
same storefront, you can provision services of different kinds,
databases, logging and things people need for their apps through this
little store. And the way we bootstrapped that was, we went out and did
well business development.
One of my colleagues did a great job identifying some three really good
examples of this would be an incredibly useful service, and it shows the
kind of shape of Of the overall add-on system we would picture, and one
of those was New Relic, which is analytics, one of them was SendGrid,
which helps you send emails, both things that a lot of apps need, and
the third one’s actually escaping me right now, but it was like a good
sampling.
And we worked with them directly to do the integration. We didn’t have
any kind of provider API we just kind of sat down with our developers
and figured out how to plug it together, and from that, that served two
purposes. One, we could see some patterns on what we should actually do
in terms of making the API for more broad use, but second, now getting
new people on board, we can point to the.
Businesses that were already reasonably successful in their own right,
people could picture other developers or businesses could picture, oh
yeah, I can see why Sendrid and Hiroku or a new relic and Hiroku working
together.
That’s exactly as you said, Wulf, greater than the sum of its parts
saying I want in on that, and then that’s the bootstrapping point and
you go forward from there.
00:38:43 - Speaker 1: Oh yeah, Kauna’s add-ons were a big inspiration
for what we were doing at GetUp, to be honest. I think we saw the
ability for customers to like point click, and then add things to their
bill that, you know, wasn’t previously there, but went through a
different, you know, procurement model and added on to an existing
subscription, like that was just a beautiful. Way to integrate that on a
sales side but also on a technical ability just to know like, hey, these
things are all gonna work together. I don’t have to worry about
compatibility and stitching versions together. It was really nice.
00:39:19 - Speaker 2: Yeah, it’s great to hear.
Now that probably does also point to one of the risks or downsides of
being on a platform, which is potentially the platform owner owning the
customer relationship, which there’s a lot of value in that, whether
that’s the billing or just the sense of the trust kind of goes there,
you know, maybe.
Amazon for its third party sellers is a good example. When you buy
something from Amazon, you’re really trusting Amazon and you’re paying
Amazon and you think of them as the provider even though maybe the vast
majority of stuff on Amazon’s site actually comes from third party
sellers.
And so overall, you have a power dynamic between the people making the
platform and the individual developers that is pretty asymmetric, and
there’s certainly a lot of historical examples in the tech industry, I
think of Facebook and Zynga as being a pretty famous one, but also
Twitter, they at one point early on were more of a platform thing.
They had an API and building Twitter bots and Twitter clients and
things, and at some point they decided, you know, we actually don’t
really want to be a platform, we want more control. We want to be a
product, we want more control over the end user experience. They bought
Tweety, which is one of the bigger clients, and they basically overnight
essentially made their API not very valuable, and they’re explicitly
telling their business partners to go take a hike.
00:40:37 - Speaker 3: The risk of being on someone else’s platform
should not be downplayed, because Whoever is running the platform has a
favorite, and their favorite is very likely their own customers.
And so if their customers in that business model need to take a left
turn or right turn, they’re gonna do that.
They’re not gonna consult you.
And so it’s very easy to be building on a platform and then suddenly
realize that you’ve been left in the dust, either explicitly cut out
like as in the case of Twitter. Or there’s uncountable numbers of Apple
Sherlocking other apps and kind of saying thank you, that’s a great
idea. I will build that instead and taking all of the market share for
themselves for particularly successful apps.
00:41:27 - Speaker 2: And I think it is tough for platform creators
because they do have to balance things that can and should be platform
features that are built in first class things because they’re useful to
everyone and so forth versus things that are in that extended.
Ecosystem. The term Sherlock, of course, is interesting because that was
basically a search app, I think, for Mac, and at one point, Apple comes
along with Spotlight and makes it so that that app is now sort of a
feature of the platform.
And I think sometimes that sort of thing can be overrated, that, you
know, the built-in feature in a platform can be kind of like a really
simple stripped down version. And then you can, an app that does a
similar thing, but a much more sophisticated version or targets a
different audience or something like that, there’s still possibility
there.
But you’re basically always at risk for that. Yeah. Joe working on
GitHub, did you have any places where you had to balance that, like,
gosh, this should really be kind of a feature of the platform, but we
actually we have this pretty important developer and we don’t wanna
screw them over.
00:42:31 - Speaker 1: Oh yeah, yeah, I think every platform. Kind of has
this tipping point where you start to see like, hey, this feature, this
product is getting a lot of traction, and people building on any
platform should realize they are doing R&D for the primary platform at
all times. Every feature you release, every experience you have is an
opportunity for the original platform to be like, hey, that’s a great
idea.
And yeah, GitHub we had this exact same thing where We were just a year
into creating our app directories, so we got a lot of internal buy-in
around, hey, this ecosystem is important, but we noticed that issues,
GitHub issues specifically was a feature that was left behind in a lot
of the development we did on the platform, so it hadn’t gotten a lot of
upgrades it needed, and specifically, there is a way to view issues in a
combo board that people really wanted and were flocking to these
external providers.
I mentioned some of the providers were plug-ins. These plug-ins were
Chrome extensions that injected information onto the screens, and we had
lots of big customers say like, hey, we love this feature, but we can’t
have people injecting into our employees’ browsers. Like, that is
dangerous, and we don’t want to continue doing it. So we want you to
build it. And so that was one of those moments where GitHub realized
like, hey, we’re gonna have to build something in this space, it’s
hugely important to all of our customers. And I’d like to say that we
did a great job, but I’d truthfully say we did an OK job of letting our
ecosystem partners know that this was coming. Basically, when it was
halfway realized on an engineering front, we reached out to that team
and said, listen, I’m just telling you now, we’re going down this
path, we’re gonna build something. And of course it wasn’t the months
of advance notice that they would like, but it was at least some heads
up. And I think this is part of what The responsibility is for platforms
that are trying to really encourage growth, is that you kind of have to
take communications and transparency as a really important value. So for
us that meant just telling them this existed, this is the feature set,
because it allows ecosystem partners. To adjust. It doesn’t have to be
the death of their business, and in in our case it wasn’t. The
ecosystem partner that we told was like, OK, thanks, we’re gonna create
communications just for this new release, so that we can talk to our
customers and say, listen, this is a good thing, we’re happy. And it
allows them to adjust their roadmap. Now if they’re gonna make more
investments for the next couple of months or years, they can now say,
hey, this base product might be taken, but what advanced features can we
do? And that’s exactly what this provider did. They created a ton of
new premium features that we knew we were never going to build. Like
that was a full-on project management suite, and we couldn’t, I didn’t
want to build that. We just needed to have some of the visualization
stuff taken care of. So they created a fully thriving business, they
ended up getting acquired down the road, but that heads up has a lot of
value in terms of just goodwill, honesty, and then just better
investment and resource allocation.
00:45:43 - Speaker 3: Makes me think that, especially early on in a
platform’s lifetime. A lot of the Businesses and players on that
platform are not necessarily building businesses, they’re building
features. And so then it’s easy for them to get kind of obliterated by
the platform maturing and implementing those features, as opposed to
what you just described where it was someone who had a business. They
were project management business, and they happened to also implement
this feature. And so when GitHub kind of pulled the rug out and stole
that feature from them, Well, they still had a viable business and so
that, yes, of course, things changed. But they were able to continue
adding value on top of the platform.
00:46:28 - Speaker 1: Yeah, and I’d say for us, those early days when
we were trying to create this ecosystem and eventually the marketplace,
a lot of it is rides on goodwill and people seeing that you can create a
business, that it won’t just be, you know, outsourced R&D that just
gets gobbled up.
So having some kind of shining lights and Good examples where like, hey,
we did something that was in our ecosystem, but also that provider is
saying good things about us, like, that’s a really strong signal that
makes people feel like, oh, I can spend the time and build something on
this.
So in the early days, transparency is so critical, and I will say the
other thing we did was, we were really human about it, so we started
doing these in-person meetups with our ecosystems.
So we got to know them personally, they got to know each other, so that
kind of glue was really helpful when we were doing something like this,
cause they knew us as people, not just like the other end of an email
address, so I think Also, you know, as many other things comes down to
like human relations, and I think this is just a piece of that. I’ve
been on the other side, you know, on the slack side, and maybe it
hasn’t gone as well, but there’s definitely moments where that human
side is just critical.
00:47:41 - Speaker 2: Well, maybe that’s a good transition to talking
about event pot and your experience building on the Slack platform.
So Slack’s a good example of something that was an incredibly
successful product. It had reached kind of market saturation, even
certainly among certain kinds of power user and technically oriented
Silicon Valley teams, and they came along with not just an API but a
marketplace and a way to essentially build a pretty full featured app on
that platform.
Did you start with the idea for the business and then think maybe we
should build it on this platform, or was it actually the other way
around is seeing this new platform rising you saw as a business
opportunity and then thought about what to build on it?
00:48:21 - Speaker 1: For us, it was definitely more seeing the platform
exist and do very well, and then just having the context of having so
many calendar startups, you know, behind me realize like, hey, I can put
these two things together and maybe create something unique here.
There’s always these moments where I would go home for like Christmas.
I’m from the East Coast, I’m originally from New York, but I’d go
home for Christmas and be like, oh man, I’m like in slack all day, and
like, you know, people my age working at other companies would be like,
what’s slack? I’d be like, wow, the difference between me in the
valley and like people in slack overload between like 10 different slack
workspaces and then coming to the east coast and having to explain what
it is.
I was like, wow, there’s still a lot of opportunity left here.
So I think that was a good prompt for like, hm, if we’re gonna build a
business, this might be a good place to go. And so that we started down
that path and realized this was an area that was overlooked and highly,
highly valuable.
At the time there was like some basic integrations for calendars that
Slack themselves had built. This was an interesting tactic as well. They
were seeding their own ecosystem by creating their own plug-ins, so they
created a plug-in for Outlook and a really bad plug-in for Google
Calendar, among many other tools that they built for, but they did these
things as a way to Cover the kind of product needs that their customers
would have until the third party themselves built that tool, and I think
that was a really interesting thing to see.
I also had a lot of, to be honest, a lot of GitHub employees went to
Slack, and so they would be like, hey, like this is going really well,
this business is is booming, and so that’s not gonna say that that
didn’t affect a little bit of my, you know, choice of where to build.
00:50:05 - Speaker 2: On the point of a platform creator making their
own apps.
Obviously Apple does that, Microsoft does that, game consoles do that,
but we did a bit of that at Eroku, and it was partially the seating, as
you said, where we would see there was just something needed, that was
pretty foundational, and in some cases we would go find entrepreneurs we
who that we thought would be qualified and essentially talk them into to
start. maybe the first Redd add on was kind of done that way, but in
many cases we would build ourselves, but trying to use the discipline of
we don’t get any privileged access, we’re working through the same API
as everyone else, that team is a The business unit would be a strong way
to put it, but we kind of try to envision them as a little in-house
company that is on the platform and then learn from that.
What are the frustrations, what are the pain points, what are the ways
that this is not a good experience for the developer.
So, in doing so, we serve both those purposes, kind of plugging a hole,
but also dog fooding our own platform.
00:51:05 - Speaker 1: Yeah, absolutely. I know that on the slack team
they did this where they built the calendar integrations and then
regularly sent usage reports to those companies being like, here’s how
many people are using it, like, is this worth it now? Is it worth it
now? And I think, you know, eventually it works, but it takes a while
sometimes.
00:51:23 - Speaker 2: Now you spoke about trying to be a good
communicator and be human and all that sort of thing and when you were
on the platform creator side of the equation, being on the other side of
that, how do you think Slack did or what was your experience like?
00:51:35 - Speaker 1: Yeah, I think Slack had a lot of great things that
they did, and overall were very net positive as an ecosystem and
platform creator. They were able to allow a lot of businesses to thrive,
but I mean like all companies, it’s not all great and they had some
missteps. I think for us specifically we experienced, you know, this
exact kind of like encroachment into our space that every kind of
platform creator.
Fears. So we were building a lot of features, especially around the
Google Calendar product, and kind of unbeknownst to us, Slack had been
working on their own second Google calendar integration. I think I
remember this very vividly cause we actually were invited to speak at
their conference. It was called Slack Connect, and I did my panel and it
was great, and then later that day they unveiled this calendar
integration that Really, really was a bit of a gut punch to us. I think
these are times where, you know, you wish communication were a little
bit more open and trust was built up, you know, we know that we are one
of many. At the time there was probably 4 or 500 apps in their Slack
directory. So we knew that we weren’t, you know, the only folks there,
but These are the moments where having a little bit of goodwill goes a
long way, cause we saw, you know, our installs dropped huge percentage,
and customers were reconsidering cause they were like, well, maybe I
don’t need eventbot. So it kind of put us on our heels, and it took us
a very long time to readjust our roadmap to figure it out. I mean,
we’re a team of two at the time, so you can imagine like, If you are
changing any investment in roadmap, like, you can only do a couple of
features at a time. It’s really hard to do, to be resourced and strap
right there. So, it was tough. I do think Slack has gotten a lot better.
Their ecosystem team has done a really great job now of literally
creating a combo board of features they are building, and they’re
pretty public about this, so they are at least giving folks a heads up
into spaces they will go. They also do this for infrastructure, you
know, hey, to be on the slack platform, you’re gonna have to have this
technical back end, and so they’ve given people a lot of notice that
these things are gonna change. We had an incredible experience with
people finding us organically, and then being able to take that interest
and create products around it. But I think it’s always been a challenge
to see further than a couple of months or 6 months down in the road map,
because you don’t know what Slack is gonna do. They’re under deep
competition with Microsoft Teams, and so you kind of are hoping that
like, hey, I hope my niche isn’t too interesting to them, that they
want to take it over, but interesting enough that they think that we’re
valuable and want to like help us out on the sales side. There’s a fine
line there, but Overall, I think that they did a pretty good job of
allowing entire businesses to form, and many of them, you know, have now
been acquired and have spun out to very large things. I was just talking
to the folks who ran Disco, which was acquired by CultureAmp. And then
Troops, which I think was maybe the largest Salesforce add-on, got
acquired by Salesforce directly. And so there have been definitely some
strong successes that came out of that, and Slack was smart about it.
They even had a fund, I think that’s probably one of the more unique
things I saw. They created a venture fund attached to their ecosystem,
so they would definitely try to be financially aligned with their
ecosystem as much as they could.
00:55:04 - Speaker 3: I’m curious about your experience. Building on
Slack, but also building a Google calendar. It almost strikes me as
building on two platforms at once, to some degree.
One very stable, it’s been around a long time. Google Calendar is
probably not gonna like shift underneath you.
But do you see that being very common? Maybe in the GitHub world as
well, or in other interactions you had with creators on Slack where they
had feet in multiple platforms, and if any one of them changed. Then
they were in a tough spot. Does that increase the risk, or do you think
in that case, well, Google Calendar is stable enough, it really didn’t
increase your risk. The momentum of slack and the dynamic nature of that
platform is really where all the risk was anyway.
00:55:49 - Speaker 1: Oh no, I think you’re right, it dramatically
increases the risk.
You’re, you know, toxing your ability to keep up and even just to do
maintenance and keep it running, like you have lots of risk of it
blowing up from either side of the connection.
I will say that it’s actually pretty common in a lot of the bigger
ecosystems to have these kind of two-sided integrations.
They’re essentially just like really beefed up zappier plug-ins, like
this could be, you know, something you could automate, but like, here’s
a tool that does it.
We actually took out a lot of that risk, because what we did is we
integrated with Slack directly via their API.
But then when we integrated with every other calendar, we used the dot
ICS kind of Cal format, which is an international standard that almost
every calendar can integrate with.
So we kind of intentionally didn’t go the even deeper route with Google
Calendar, knowing that it was going to be much more difficult to like
maintain and increase, and customers every year would give us these like
top requests, and that was probably one of their biggest requests is I
want it auto populating.
Instead of like, hey, you just have to connect this ICS calendar and
it’ll populate in under an hour. So we kind of took the customer
dissatisfaction to give ourselves a little bit more breathing room. But
yeah, it’s a really good point that those two sided integrations can be
a gold mine if you find a really good niche and build it out, but it’s
a risk that, you know, either side ends up saying that’s a great idea,
we’re gonna do it.
00:57:20 - Speaker 2: And coming back to what I mentioned in the
beginning, which is sort of the technical side of a platform to build
on, and the business side, called the distribution aspect or the
partnership aspect.
I’m curious for the case of building eventpot.
How much was Slack’s API and the technical infrastructure and the fact
that maybe you don’t need to worry about user identity or you have a
bunch of existing kind of UI concepts like channels, for example, that
your users already know and you can skip forward to some unique value
that you’re providing versus, you know, making basic login pages or
onboarding flows, how much was the value in that versus Either one,
you’re in their marketplace and people just search there and find you,
or even just that they Google Slack group calendar and they find you.
00:58:08 - Speaker 1: Oh yeah, we ran a lot of those ads too, very
successfully in the beginning, but the ability to not have to deal with
common overhead for us was a really big boon to creating our company.
Knowing that we didn’t have to worry about maintaining user databases
and Keeping track of like every workspace and all the details that
essentially Slack takes care of because that’s their products, bread
and butter. We could essentially use that and bootstrap off of that.
So it saved us countless hours of time, and also I think for a lot of
our customers, some of them are, you know, very big businesses, they
would have really deep requirements if we even wanted to build that for
ourselves. So, knowing that Slack like has the resources and has the
kind of edge cases filled out, great, it allows us to focus on much
more.
Unique value adds on top.
And I think also channels as a concept was new to people. I mean, they
understood threads of email, and then when you move to a channel-based
kind of topic discussion forum, they didn’t know how to react and so it
allows you to take that space where it’s not defined on what it should
work like, and then add to what it could work like. As an example, a lot
of people had a Happy hour type slack channel that they would just use
for happy hours. And so we would say, oh, we can create a calendar
behind that, and every channel gets its own calendar, so everyone can
create their own events that live inside of that channel. And so we
started pushing the boundaries of what people thought a channel was. It
wasn’t just chat, it’s also a calendar, and we introduced a visual
calendar system in our second year, where you could see a visual
calendar of that channel’s activity. So people were like, oh great,
every Monday morning I know exactly what’s going on for the rest of
this week as it relates to this topic. So I do think that Slack’s kind
of basics gave us the jumping off point to build some really cool stuff.
Even if we wanted to build it, we wouldn’t have been able to recreate
it, but seeing that it was there, it gave us just, you know, nice
constraints to create some innovative stuff.
01:00:16 - Speaker 2: And certainly our experience on news and well you
probably also can speak to this for other apps and companies you’ve
been a part of, but, you know, the Apple platforms at this point,
particularly the iOS, is just one of the most filled out in the world on
that, you know, thousands of APIs you can use, they dictate programming
language and essentially you basically have to use their IDE or or close
to it. And then on the distribution side, the App Store obviously is the
one place, one and only place you can get iOS apps, and there’s very
tight controls there and you have a storefront there.
But yeah, that is something where I think when the App Store came along
in those early developer kits related to it, you would see the cases of,
I don’t know, a talented 16 year old somewhere that could Write a
useful app pretty quickly, and something that adhered to the platform
conventions and felt very professional, and they put it in the app
store, they don’t even need to make a web page for it, they just put up
some screenshots in the description, they sort of automatically get this
presence and this distribution.
Maybe this comes back to where the platform as a metaphor even comes
from. It’s the idea, it’s a thing you could stand on that starts you
in a higher place than you would have been starting from something
lower.
01:01:32 - Speaker 3: Yeah, and I think that higher place comes, like
you mentioned, all the APIs and all of the foundational code that Apple
provides is a really big piece of that. I think the second really big
piece is trust. Everything inside of the Apple ecosystem runs inside of
that sandbox and there’s kind of privacy built in, and users know that.
So the harm of a bad actor is dramatically reduced, and I think that’s
true of, you know, almost all successful platforms is there’s important
guardrails. So if I install something on Platform X, I know that I’m
only giving it permission to do A, B, and C. But the really dangerous
stuff, it can’t even see, can’t even get access to.
01:02:18 - Speaker 2: So installing a Chrome extension, for example,
which potentially could have access to everything you look at your
banking website, all your passwords, etc. and I think the review process
for most of the browser extension stuff is a lot lighter touch than than
say Apple’s review, but they do have those permission systems. So I
know, for example, that I have to answer that question about this can
read and write data on all the websites you visit.
Do you want that? And then I can pause for a moment.
Question, do I trust this developer? How important actually is this plug
into me versus something that asks for more restricted permissions.
It only is modifying data on this one site because it’s designed to be,
for example, on board for GitHub issues, to take an example from
earlier, and so then I can go, yeah, that’s all right with me. I’m
willing to extend that level of trust to this otherwise unknown piece of
software I’m downloading from the internet.
01:03:14 - Speaker 3: Yeah, and just forcing that visibility, I think is
such an important piece to maintain trust, not only from the platform’s
perspective, for the platform maintaining trust with their customers,
but then also building on that platform, you kind of immediately gain
that exact same trust that you would otherwise have to build from
scratch as you’re just some random no name company trying to sell me
something. Which is a lot more tenuous than, oh, yes, if I install this,
I see that you get these 3 checkboxes, but not these other 3 checkboxes.
Great, sure, let’s try it out, who cares? And that freedom, I think is
a really important piece of that foundation that the platform can
provide.
01:03:58 - Speaker 1: Yeah, that trust by proxy is something we felt
exactly the same when we were building eventbot where, yeah, we have
some of our like Fortune 500 customers would be like, well, you know,
you seem to be a top rated app in the Slack directory and you’ve gone
through their checks cause they do a review, but like, OK, they know who
to call if something breaks and so I can trust you because they trust
you and yeah, it’s an incredible. Ability to kind of use and not have
to start from scratch, like you said.
My theory is that if you’re a first time founder, I highly suggest
working on another platform, because the amount of jobs you need is
lower. Like I remember for us, you know, we were two people, but we
didn’t have to hire a salesperson or marketing person because we were
using the app directory. We didn’t have to hire a designer, because the
platform itself dictated, like, here’s what the UI elements can look
like. And there wasn’t that much we could do, so we knew like, OK,
we’re not gonna have to do any kind of designer hiring.
And the same thing, if you keep going down the list of things that the
platform takes care of, those are literal jobs you don’t have to hire
for, which lets you be smaller and try to build something unique with
just the pieces you have. And I think that’s a really valuable part of
Starting a company and not having to feel like the full weight of every
part of the business on your shoulders, but maybe a lighter load at
first to kind of get people situated. I think it’s a really great way
to start as an entrepreneur.
01:05:33 - Speaker 2: That’s a great point. Those constraints could be
frustrating for a more experienced set of entrepreneurs or just a bigger
team or they want to hire for those roles, they want to do that bespoke
design, so they’re annoyed that they’re limited what they can do, but
if you’re a smaller team and or have less experience in whatever that
particular space is, those constraints are basically awesome. Yeah.
01:05:58 - Speaker 1: We were terrible designers, so when we found
Slack, we’re like, great, we can just put text and buttons, like,
that’s all we want to know how to do.
01:06:05 - Speaker 2: Maybe on the eliminating a potential early job on
the design and marketing side, one thing we’ve grappled with quite a
bit on Muse is the essentially what your primary storefront or what your
primary first touch point is for customers.
So, you know, we have a pretty extensive website where we try to
describe the product in detail and provide videos and Linked to this
podcast and all that sort of stuff. We also have our app store
storefront, which is very important for a lot of reasons.
First of all, we get featured there. Secondly, people search for stuff
and find us, and thirdly, in some cases, people are just used to linking
to the app store, so we’ll get a mention in some article somewhere and
someone will actually link to our app store entry. And for me, that’s
been a challenge because we’re very limited what we can put there. They
have very strict rules about what go in the screenshots, the screenshots
themselves are very specific kind of sizes and ratios, the description
text is basically totally unstyled and so making it kind of flow well
without section headers or whatever is kind of a whole trick. You just
have way, way less control. So again those limitations are great if
you’re a solo founder or a smaller team, but for us who do have that
kind of design and marketing capability for us, it can sometimes be a
restriction, but we do really need to think hard about we have users or
potential customers who will enter from either of. Use places and they
need to both make a good first impression, they need to both do their
best to explain what the thing is and pitch you on why you might want
this. They cross link each other naturally, our website is gonna link to
the download thing in the app stores as a matter of necessity, and of
course the App Store as well as our app links to our website. But yeah,
maintaining both isn’t awesome, but then at the same time, there is so
much to be said for a more developed business having more freedom with
their own web storefront. Curious, yeah, how that was for you with
Eventbot or Wulf, how that’s been for you for some of your other
businesses.
01:08:08 - Speaker 1: Yeah, there’s definitely been times where we wish
we had more ability to customize anything.
For us in the app store, they allowed mark down but, you know, not
images, and so we’d be like, OK, we can style text exactly like you
mentioned earlier, like the way we want, but we have to be really
thoughtful about, OK, what’s above the fold and what categories of text
do we want to put in there.
I remember early on we had a couple of clones that basically were just
eventbot by a different name, and they even copied our app directory
description format, and we were like, wow, this is, you know, an
impressive flattery and impressive determination by these cloth makers
to really get every detail right.
And I think that it ended up being a way for us to say, all right, like
if they’re gonna compete with that, let’s change up our very
constraint driven. Marketing and do that in a slightly different way
that allows us to kind of show that we are better.
So we did route people a lot to our website, we linked out to like
external people who talked about our app that they couldn’t link out to
and I think Slack has a really incredibly good onboarding for new users,
and so we started doing the same thing, where we would onboard them on
the website or the app directory wherever they were looking at us, and
then have that follow all the way through the actual usage.
That was our way of trying to make the experience a little bit better
and different than our clones, and then also better for our own tracking
and kind of experiments that we would run ourselves.
I’m curious, were you able to do that in the Apple app store? I know
that they’re notorious for locking down the differentiation in those
descriptions and initial experiences.
01:09:51 - Speaker 3: Yeah, the Apple app store is interesting because
they’re very restrictive on screenshots, on text and screenshots, or
lack thereof, on kind of the format of the app description, which
doesn’t even have a markdowns, so it’s very, very plain.
I think another interesting thing that’s restrictive on the Apple
ecosystem is the business model restrictions, and that’s become better
over the past number of years, but especially early on, it was, you get
a price and that’s it.
And so, if you’re not free, it’s really gonna be a struggle to get
downloads because they have to open their wallet before they even tried
the app. And overcoming that trust to say, please give me your money, by
the way, the only thing you know about me are these 3 screenshots and a
paragraph, is really tough.
It’s a lot better now, I think because there’s free trials, there’s
subscriptions, there’s in-app purchase, there’s more flexibility there
on the business model side. But surprisingly, there’s still very little
flexibility on the actual storefront, on the store page itself. I think
there is some, the blessed hand coming down and anointing you from
Apple. There’s some exciting pages and, you know, more features and
things like that that they give to very specific partners, but for the
overwhelming majority, that storefront page is the same as it was 15
years ago, which is surprising, I think in many ways.
01:11:21 - Speaker 2: I think the pricing limitations as well, which now
that they have subscription pricing and in app purchases and so on is is
pretty good, all things considered. It covers the common cases, but one
place that interacts with the storefront that I think is a basically a
bit of legacy baggage from that history is that apps like ours that have
a essentially a free trial, but more of a storage limited trial. rather
than a time limited trial and then it’s a subscription purchase, but it
just lists as it’s a free app and then it kind of mentions, oh there’s
an app purchases and if you scroll down somewhere, there’s a little,
you know, divot thing you can open that it has the various plans that
are available listed in really small gray text, and it also includes
legacy plans that actually still have some customers on that you’ve
actually sunsetted for new. Customs, but it lists those out and so it
can be just that part of it, which is so important, right? Like most
websites, our website, the pricing page is one of the first links. We
spent a lot of time trying to explain exactly what you’re buying, what
do you get for free, what do you get in the lower tier, what do you get
in the higher tier, what’s the dynamics with your data, once you cancel
that sort of thing. That’s just so critically important. And the
ability to explain that on the app store is basically nothing, which
actually results in bad reviews as well, which is people come in and
expect one thing, oh, it’s a free app, I guess there’s an app
purchases, I mean, I’ll be able to buy a $3 emoji sticker, and then
they see it’s actually a pro. you know, prosumer subscription price and
they hate subscriptions and if they had known upfront that they would
probably just not install the app or not try it, which is totally fair.
You want to have that information before you start, but then you feel
tricked in some way, but there’s actually nothing we can do about it,
that’s just how the storefront is set up.
01:13:12 - Speaker 3: Yeah, I think there’s a lot of, like you said,
baggage that comes from the Apple ecosystem 15 years ago, where it was a
one time purchase for $1.99 and now you have lifetime access to that
app, and so it really encouraged kind of a race to the bottom on
pricing, and then once subscriptions were added, once free trials were
added, once there’s More ability for professional pricing, raising
those expectations of price for the customer is always way harder than
lowering the expectation for the price. I mean, like I said, it’s been
15 years, but I think that weight is still pulling on developers and
pulling on prices from its lowest price wins legacy of 15 years ago.
01:14:00 - Speaker 2: Well, Joe, since I know you’re a teacher and
you’re good at summarizing complex topics for your students, maybe for
me and Wulf and for our listeners you could briefly sum up what’s the
overall if you’re an entrepreneur or a software creator, how do you see
the pros and cons of building on platforms?
01:14:19 - Speaker 1: Yeah, yeah, I do love to summarize. I mean,
thinking about all of the aspects of platforms that we’ve kind of
talked about today, there is some real truths that I think creators have
to go into building on top of a platform and just be very clear eyed
about those risks of, you know, either being overlapped in terms of
product or being restricted in terms of pricing. And those things, some
of them come, you know, with success, so they’re good problems.
They’re things that happen, you know, if you are making a product that
people want and are trying to really grow, and then some of them are
just existential, right? Like, is this app gonna be around? Will they
shut this down? Will I be able to keep a long-term business? So I think
those are very real and, you know, you’ve gotta have real conviction,
not just like, hey, I read a blog post and it told me that it will. So
you’ve got to like do that diligence, but I think the Incredible
positive attributes that come with building on a platform, you know,
allow for tons of experimentation, tons of real strong businesses that
could only exist in an ecosystem that’s already provided.
I think not just for full-time founders, but just for entrepreneurs who
are looking to like make that dent in the universe and have it be
sustainable.
Those platform businesses where you can find that exact match, is just
an incredible opportunity. And it’s also just a really great experience
to build businesses with another company.
There’s some part of entrepreneurship that is quite lonely, and so
being a part of an ecosystem gives you a kind of like built in friend
founder network where you’re all kind of go through this stuff at the
same time.
So, I’m very much pro platform building as long as it’s done, you
know, with clear expectations and good opportunity.
01:16:11 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, you can write us on Twitter at @museapphq
and via email, hello at museapp.com. And Joe, thanks for sharing all
these great stories, and I’m really curious to see what comes next in
your career.
01:16:28 - Speaker 1: Absolutely. Thanks, Adam. Thanks, Wulf, it was
great to chat with you all.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: You want to achieve mastery in some sense in your
life. So all these things come together and for some people, community
becomes very addictive. I’ve certainly been in communities about
products and games, where the game or product became a. And the
importance because the community in itself just became my main driver to
come back to this group of people nerding out about something that I
wasn’t even using or playing all that much, but I love the ideas about
it.
00:00:35 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product. It’s about the small team and the big ideas behind it. I’m
Adam Wiggins, joined by my colleague Mark McGranaghan. Hey, Adam. And
our guest today, Ramsey Out of LogSeek.
00:00:54 - Speaker 1: Hi, Adam, I’m Mark. Great to be here. Thank you
for having me.
00:00:57 - Speaker 2: And I understand you started your professional
life as a Spanish teacher.
00:01:02 - Speaker 1: Yeah, that’s correct. When I finished my
associate degree, I was about 16 years old here in the Netherlands.
You’d leave high school very early, so 16 years old, I started my
associate degree and then finished when I was 18. So I enrolled in
college, did a double degree in Spanish language and culture, and then
also teaching it, and that is basically what, yeah, triggered. The
obsession with learning and specifically learning languages, so both
natural languages and computer languages. That is how it all started,
all the sleepless nights trying to figure out why something is not
working or why I don’t understand something.
00:01:43 - Speaker 2: Can I assume you probably fell down the space
repetition on key rabbit hole at some point.
00:01:49 - Speaker 1: I’m still hooked 15 years after discovering it,
so I just finished before we started this call, I just finished my 100+
Italian repetitions, which I’m now doing, so I’m learning Italian
through immersion, flashcards, and a lot of TV shows, so, yeah.
00:02:07 - Speaker 2: Netflix has definitely been a very big boon to
language learners, particularly with their very solid audio and subtitle
selections and the ability to rewind and relisten when you didn’t quite
catch something, and so on.
00:02:19 - Speaker 1: And the tools build on top of that, so there are
actually tools that will let you capture subtitles with a screenshot. I
think there’s even options to capture the audio, like a piece of audio
with it. So, yeah, definitely the tools in the last decade have
definitely made language learning easier. Obviously the flashcard tools,
but also note taking tools, obviously, as you dive deeper into a
language, really make it a study project. That is basically, I started
with the flashcards and then I moved more and more towards the personal
knowledge management nerding out over the more intricate parts of the
languages that I was learning.
00:03:01 - Speaker 2: I guess I can see the path there. This is the part
where I’d normally ask what was the path that brought you to lugs seek,
but I think that almost answered the question a little bit, especially
when you talk about the, is it the Think stack Club is your kind of
online learning platform that maybe bridge the gap between those two
endpoints.
00:03:18 - Speaker 1: Yeah, so in like very quickly run through my
curriculum, so basically after graduating as a Spanish teacher and
teaching for several thousands of hours because internships are very
early in the Netherlands, I couldn’t find a job as a teacher. Teacher.
So I ended up actually as a telemarketer for 2 years on the phone with
IT managers, mostly decision makers or stakeholders in IT departments
trying to get appointments like physical appointments for colleagues of
mine.
And I would just cold call people each and every day. That’s where my
hunger for learning came in very handy because I had to learn a lot
about the IT space so what companies operate, what technologies are
there, so not just from a software perspective, like I knew obviously
operating systems, but also servers, networks, complex systems, so I had
to learn a lot. So note taking became more of a focus for me as I was on
the phone, taking lots of notes.
Finding basically little rabbit holes to go down to as someone would
mention something like a technology on the phone, I would just say, oh
yeah, oh yeah, sure, sure, and and the meanwhile I would write down some
terms and then spend half an hour researching that, taking some notes,
like we had an internal wiki as well because there were more guys like
me who didn’t know anything.
Too much about the IT like certain parts of the IT ecosystem, like the
corporate IT ecosystem, and we’re eager to learn, so we’re just a
bunch of guys eager to learn and practicing our skills and that ended up
laying the groundwork for me becoming more and more technical, advancing
through the corporate IT letter, basically joining Oracle, becoming a
customer success manager.
And that helped me listen more and more to customers, figure out what
are the issues they run into, so obviously, interviewing skills, note
taking again, very important, came into play, and that’s how in the
end, I ended up with Lux seek as I was doing more and more online with
Community just because it’s a passion of mine. I like it and I got into
community when I started with language learning. And I just kept at it,
learning through community as I progressed in my career.
I, again, found my way back to community and then see, OK, what have I
learned in all these years? What have I see. Not work like communities
that I’ve been a part of that went like south that became very toxic,
and what are the communities that still thrive now that I look back 15
years later, there’s some language learning communities that have
become super toxic, nobody is there anymore and other communities thrive
and there’s some clear markers I would say that show, OK, this will.
More or less predict if a community will thrive in the future or if it
continues on this path, if it’s going to basically die out at some
point.
00:06:24 - Speaker 2: Yeah, I think language learning is uniquely suited
or perhaps I should say tends to be something that really benefits from
community.
I think a lot of things do, many different interesting skills and career
things and so on, but maybe language we’re learning can be just so
continuously frustrating.
And you just need this, of course you need the internal motivation, but
there’s something about others going through it at the same time. As
you, I continue to think that the community aspect, almost the like
group therapy aspect of Y Combinator is actually one of the things that
makes it successful in the Silicon Valley entrepreneurship world is just
being around some other people who are going through the same thing as
you experiencing the same struggles, and then when the going gets tough,
as it always does, you can kind of find strength in the others who are
going through it with you. So yeah, I could see where language learning
would be just ideal for that in some sense.
00:07:16 - Speaker 1: Yeah, it’s both for learners, so there’s a lot
of knowledge in the language learning community.
Obviously, there’s also drama like in any other nerdy niche, there are
people very contentious about flashcards versus no flashcards or grammar
focused study over just watching TV shows.
There’s always some reason to have discussions, but it’s not just
useful for learners, but I’ve also found it useful as a teacher and I
think that’s how I got into community in the first place.
I as a teacher, most language teachers that I know and also myself
included, we don’t really do rigorous academic research into what works
and doesn’t work in class.
We work off a lot of anecdotal evidence, so trying stuff out in the
classroom, sharing that with colleagues within the school, but then
there’s also, especially here in the Netherlands, there are many
programs to connect through universities, connect teachers and have
teachers share experiences.
And then also connecting them online. So there’s a lot of useful work
happening there, that’s also how you see innovation happening in
language learning products.
So, Duolingo is a very simple example of making something like space
repetition. Mainstream, even though before people would never mess with
Aki, it can offer a way for teachers to say to their students, hey, use
these different tools to get more input. And then as learners become
more fanatical, hopefully they will discover unki other methods that are
more suited to their style of learning and how they like to get fluent
in the language.
00:08:59 - Speaker 2: And why don’t you tell our listeners what is
Loseek?
00:09:03 - Speaker 1: Yeah, so LogSeek is a tool that helps you organize
knowledge and make that knowledge your own. So what does that mean?
Let’s unpack it a little bit. So when you open Loxy for the first time,
it looks like just another outliner tool. So just a tool that you write
in bullet points and you can in dense or out dense blocks.
00:09:24 - Speaker 2: And the classic outliners here would be Emacs, or
mode or workflowy maybe.
00:09:29 - Speaker 1: Yeah, so the less technical ones would be
dynalyst, work flowy, on the more technical spectrum you would have
Emacs, for example, that are well known example I think for many
listeners would be Rome research.
And then in the spirit of Rome research, Lexi is an open source
outliner, but it’s built like Rome and some other tools like Obsidian,
it’s built on top of a database.
So even though you work with just plain text, it’s all stored in a
database as well, so all your data is also stored in a database. So
there’s a lot of data about the data, a lot of metadata about the
individual blocks, like the outlines.
And that including the data that you add yourselves, that yourself, for
example, through links or tags or some other simple database structure
that you create, which we call property. So if you use properties, you
can basically give information about the data and that will help you.
Build processes, so basically pipeline systems you can use Lexi, which
is very popular for project managers who take many notes and then want
to reservice those notes in a single dashboard or students who want to
reservice all the notes related to a class and then easily turn them
into flashcards. So here again, the flashcard thing is coming back, so
many students use. Logs seek, also because it’s free, it’s very easy
to write just your notes in the outline as you’re sitting in class and
then add a few simple hashtags to turn something into flashcard.
And that is, I think the true power of Luxeek is that obviously it’s
free, which for many people is a plus. It’s open source, so it’s very
hackable, but also it for many people it breeds some trust that even if
we decide to stop with the company or go into a direction that our user
base doesn’t like that then they can continue with the app and continue
developing it themselves if they want.
And then obviously, also the ease of use because it’s in the end just
an outliner, I think that has attracted many people to logs seek to use
it, at least as a scratch pad for stuff that’s on their mind that they
don’t want to forget and that they want to have an easy way to find
back their notes.
00:12:01 - Speaker 2: And it’s interesting that you sort of lead with
the outliner, the indented bullet points, and then you mention links,
you know, when I think of Rome, which obviously is a source of
inspiration, it makes me think of almost the category I think they sort
of invented, which is what I call, would usually call a knowledge graph.
Now obviously there’s a history, a much deeper and longer history of
linked. Databases, the web with hyperlinks is sort of the ultimate of
that, but also something like a team wiki, like you mentioned using in
your previous career steps, but also, obviously something like notion,
how important do you think of linking as being in sort of the logseek
product?
00:12:39 - Speaker 1: I think linking and indentation, so basically the
Document as a mind map, so instead of having a text document or just a
paper where you have a linear piece of text, you have more like in a
mind map structure in computer talk, call it a tree-like structure, you
know, and programming language.
So That I think is the root also of the web.
So those are two things that are root of the web. So if you look at a
normal web page, HTML page, the documents that you look at, the code is
structured in a tree-like structure, so it’s basically an outline.
Every web document is basically an outline. So, that is one principle
that many people are not aware of, but that I think once you rock that
idea. Then you can become much more flexible with your knowledge. You
don’t have to flesh out an arguments linearly. You can just choose to
upload your thinking and then branch out. So just like as you would
design a web document, you would first maybe start with some headings,
then you start filling those headings in the same way in an outliner,
you would start with the top level blocks. And then as you become more
and more nuanced, you add more and more blocks underneath and then
linking helps to link to any data that is not part of that same block of
information, so that same tree like branch, you can then link to other
branches basically. So that will allow you to hop from branch to branch.
So that’s why I lead with the idea of an outline structure because
Understanding a graph database, like graph databases were around before
Rome existed, like far before, so it’s not a new concept, but many
people are not familiar with it. Whereas if you say there’s no taking
tool, it’s like a mind map, you just create a collection of mind maps
and the outline is nothing more than a mind map. For many people it’s
much easier to understand, even though I still use terms like tree-like
structure and traversing the tree, for example, or branches. I still
think you should learn that as a user, if you’re serious about
knowledge work, then you should definitely become more familiar with the
language. But the first principles of it being a branch, your notes
being just a bunch of branches, I think that’s the most important
thing. And then obviously there’s nowadays also the meme, oh, I will
just use Apple notes, why do I need a complex note taking tool? I think
if you think that way, probably Apple Notes is good for you, but if you
want to think very thoroughly over time, if you want to refine your
thinking, you need to have some tools to support that. So if you don’t
have some deep intellectual projects that you’re working on, Maybe
designing a product or mastering a language, for example, that in itself
I would count as an intellectual endeavor that takes a long time. If you
don’t have that, just use Apple notes to scribble down your grocery
lists and stuff that you don’t want to forget, but don’t
overcomplicate things. So I’m really focusing on the people who are not
familiar with this, but who have some kind of yearning to organize their
knowledge and are willing to put some time in it to learn the basic
principles of a tool to help their thinking.
00:16:09 - Speaker 2: The term note taking in some sense is overloaded
and even we pushed back in the muse kind of positioning, messaging
basically what goes on our homepage describing what it is. I always
pushed back against the note taking or didn’t love that because it does
make you first think of scribbling down a grocery list in the default
notes app on your phone.
And I do that, and I think it is correct to call that note taking, but
it’s also correct to call it note taking that you’re developing a
large body of work over a long time in the process of a deep
intellectual process like learning a language, writing a book,
developing a software project, building a business strategy.
So it’s a little tricky that both of those use the exact same word.
00:16:53 - Speaker 1: It’s not taking the act of taking notes. I think
that is correct, even if you do, if you work on a super deep project
trying to figure out a piece of software that will help people unlock a
way of thinking, for example, in the case of Muse. You want to help people
think through something, right? But the act of writing something down,
that is taking note, but then what do you do with it? How do you process
that knowledge? How do you connect with it? What is your inner dialogue?
And then obviously a tool can help you have that inner dialogue, but
then obviously you first need to set up the tool in a way that it can
fire up the inner dialogue.
So very concrete example. In Oy would be you can create templates and
many users create templates for maybe a project there that they are
running. So they have just a bunch of headings, maybe a query that
automatically picks up some kind of data from a graph, but in the end,
it’s just a piece of text that is structured. But first you have to
think through that structure. You first need to know how will my way of
thinking lead to something like how can I make it more likely that I
gain insight.
It’s not about taking notes, it’s about getting to an insight.
It’s about solving a problem, then exposing yourself to ideas and think
through a problem to then come to a solution. And taking notes in that
process is part of the process.
So you’re collecting maybe potential solutions. And then you structure
those notes in a way that it becomes more likely that you come to a
solution because you process those notes, you don’t just Write them
down, you then also prompt yourself to look for other related nodes or
for contradictory points.
And in the case of, for example, a software project, you would look for
a solution for a problem, but then you would also look at what other
problems with the solution cause, like what would break and what are the
trade-offs in, for example, UI decision and do we have to rework in the
back end. That in itself, you take notes, but you come to an insight
through those notes and you need to have some kind of process to get to
that insight. It’s not enough to just note something down and then I
see also many people mention, if only I had some kind of AI reservice
notes for me as I’m writing something, then I can just automatically
link all those notes. Like, no, you are here to do the creative work,
you’re revisiting your notes to feed that brain of yours. It’s
basically almost a black box. At some point something comes out and let
you know down again, and that becomes basically the entire cycle until
you come to that insight that will help you, that solution to a problem.
00:19:48 - Speaker 2: Completely agree.
00:19:49 - Speaker 1: Well, I think this could be a segue into community
because at some point, so let’s talk about this from the standpoint of
a tool creator. Like you are more builders than I am. I’m just the
community manager. Like I use Loxik myself, but I am not technical. I’m
not an engineer. I’m not a designer, I’m not a products person at
all.
So I have to distill. Learnings from the community in some way because I
want to use Loxy in a specific way. Obviously I’m interested in the
feedback on the products, but I’m way more interested in how people use
the products and then distill patterns from users because that’s in my
position, the best thing I can do. So you were talking about what is it
that our user base wants to get done using our tool. Then you can
discover that in many ways. You can do one on one user interviews, which
often are a little bit more artificial. Like I see the best things in
office hours where people are sharing their screens and like I’m trying
to get this working and then they share the screen and you see the
structure of their notes and you ask why have you structured it that
way, what does it help you with? and then you get insights into how
people use it. You see YouTube videos where people share it. And that’s
basically the beginnings of a user community where people are starting
to share how they use a tool, and then an outsider may ask, why would
you create a video about how you use a tool. Well, can be many reasons,
maybe you’re just very nerdy, you want to share how you use something
and because it makes you happy. Like I’ve done that, certainly, but I
see also many users who create a video about the workflow and say, well,
this is what I’m trying to achieve. This is the compromise I’ve made
so far because I couldn’t get this to work, and then you get other
users to chime in and say, oh, maybe you can use this, or here’s a
plugin to do that, or in our case, here’s a proposal for a feature
request and the more votes something gets, the more buzz there is about
a feature request, the more we learn. About what workflows people are
using. So it’s very valuable. We as developers learn about our user
base, how they use the product and how we can improve it, and then users
learn from each other and create a network where knowledge is going
around about this tool. So that’s outside of basically the tool
creators control, like me as a community manager for Lexi, I try to
capture stuff like I try to curate stuff from the community. I try to
encourage people by meeting regularly by having events and stuff like
that, little mini courses that we do with the community, but in the end,
the community is just doing what it does, it’s like trying to get stuff
done for themselves and then sharing knowledge how to do it, asking
questions. And then I think the job for us as a tool creator to listen,
to see how is our tool used, like we can basically hear from our
community, what is our user archetype or archetypes and then how can we
better serve those user archetypes? Like what features do we need to add
or what UI improvements, UX improvements do we need to do? To better
facilitate this group of users and then maybe as your features improve,
have more people from that niche, from that type of user come in, and
then obviously your feedback becomes better and more refined over time.
So you’re not trying to create a tool for everyone, you’re really
trying to look, who do we resonate with, and then we focus on those user
group first, like to serve the community as well.
00:23:38 - Speaker 2: Yeah, a good segue and good kind of context for I
think how a product company, especially a tool creator, would use
community.
So yeah, our topic today is community and why one reason I thought you
would be a great guest to talk about this is first of all, LogSeek has a
great community, very vibrant, and part of that’s the open source
element, but part of that is just, yeah, that sharing of workflows and
so on, but also of course your background as you said with the language
communities.
We were also in the Rome community for a while and I think in the kind
of tools for thought world generally, so you have experience with a
number of those and maybe a good place to start here is I think you’ve
teased it a little bit, but it’s sort of better defining what we mean
by community.
It could be a group chat or it could be a forum, but I think that
probably is a little too mechanical. I’d be curious to hear for both
Uam and Umar, what to you is the core of what makes a community or a
good community might be a way to put it.
00:24:37 - Speaker 3: Yeah, well, I think there are different types of
communities, but when I think of community in the context of tools and
companies and interests, it’s often just a group that shares an
interest and it sort of grows from there, and there are all sorts of
emergent behaviors and patterns that we tend to see that we can talk
about, but to my mind, it’s the foundation is having a shared interest
in acting on it together.
00:25:01 - Speaker 1: Yeah, so shared interest, to start that as a
starting point, I fully agree. So there’s a shared interest, but
there’s also a need for each individual. So what you see happen
nowadays is especially as community is seen as a moat for products like,
oh yeah, this will guard us against our competition.
I’m a little bit skeptical of that because especially if you talk about
the tools for thought space. The hardcore first adopter group, they will
go from tool to tool and like rip it apart and say what they like and
don’t like. So those are very vocal minority. And then often as a
product matures and a community matures, you have a few people that
derive a lot of value from a tool and they have a reason to show up in
that community.
So if I look at Luxy, Luxe is not the easiest tool to use. We don’t
ship with a nice polished handbook like Muse ships with. So just our
feature overview for that, you would need to have a community.
Obviously, you can use blockseek just as an outliner, you don’t need
much to get started with that. There are some YouTube videos that will
show you exactly how to get started, but then to get deeper into a tool.
So once you derive some value from a tool and you think, I want to
master this, I want to see what else is possible. I think that for
people is a strong driver to join a community and keep showing up.
And then like in social psychology, it’s over time valuing what’s
yours and uh part of your identity will be that community, so you start
to value it more over time and that’s also tied in with another thing
from social psychology. Is this need for mastery. You want to achieve
mastery in some sense in your life.
So all these things come together and for some people, community becomes
very addictive. I’ve certainly been in communities about products and
games, where the game or product became. Of second importance because
the community in itself just became my main driver to come back to this
group of people nerding out about something that I wasn’t even using or
playing all that much, but I love the ideas about it and I always try to
learn things from communities that would then benefit me in other parts
of life, like bringing my learning obsession for languages to note
taking. And then thinking what other skills can I learn using the tools
that I’ve already learned. So I think for community to thrive, you need
to have an influx obviously of fresh insights of people coming in.
So it needs to be a welcoming, friendly place, doesn’t scare off people
or people check out your product and then they see a bunch of toxicity
on Reddit or Twitter or wherever, so I think that is important. And then
obviously, also, can you make your product stick in some ways, so can
you deliver value from a community about your product and maybe some
users, they will get to a point where they know how to use your product
and that’s all they need, they will use your product but not go to the
community because they don’t need to learn more. They don’t need to
figure out more how to use the product. So there’s less of a need for
them to keep showing up to the community.
So even these people, they will still be connected to your products.
They have not abandoned you, but they may have become dormant in the
community because there’s just not a need for them. They don’t need to
achieve more mastery. They are already busy, they already have some
connection in other parts of their life. They don’t need to come back
to the community and that’s fine. So community changes and I think that
it’s fine, and it’s an illusion to think, oh, people keep the same
interests, will keep the same needs, yeah, and the rent.
00:28:57 - Speaker 2: Yeah, I certainly think when you think of a
community connected to a product, which obviously not all and even most
communities are that, but in that specific case, now you have a kind of
a Venn diagram of people who currently use the product and get value
from it, and then there’s people who are in the community and then
there’s overlap, but actually you have people who are in each group,
that’s certainly the case for Muse. I know we have folks who either
listen to this podcast or Follow us on Twitter or otherwise in our
sphere of discussion that just feel like we share values or like to
follow along or we’re just friends with somehow, but they just don’t
happen to have an iPad or don’t happen to have a specific use for the
product or maybe they did in the past, but they don’t at the moment,
but they’re still sort of interested in the people and the culture.
Around it and you certainly have the other way around as well, but I
think certainly most products and tools will always have a much bigger
user base who are just more transactional. They just have a problem to
solve. The product solves a problem for them.
Maybe they pop into the forum or whatever the community location is just
to get some information, but again it’s very transactional.
00:30:02 - Speaker 1: Yeah, and I still think there is for these types
of users, there’s still a reason to come back to the community every
now and then and maybe another segue because we prep like a few points
and also you ask what are communities that I see as a successful example
of a community, like as an aspiring example. One community I keep coming
back to is Reed Wi, so Rewise. It’s a niche tool, I would say not
everyone takes highlights from books and wants to revisit them.
So it’s definitely for a specific type of person, like person who wants
to, you know, the more PTM person.
But in the end, it’s not a very complex tool, it helps you achieve a
few very important things, and then that’s it, so you can get started
with rate wise in the afternoon and then have it give value to you for
years, whereas you don’t even dive deeper into the tool, you just use
it.
00:31:02 - Speaker 2: And I do wonder if there’s often a connection
between communities and more complex or customizable or challenging to
use.
You mentioned for logseek, I think this was true for Rome in the
beginning, lack of documentation in a way can actually create a stronger
community in a way because you’re helping each other figure this thing
out, but Even putting that aside, even with good documentation, if
something is complex and customizable, then that naturally leads you to
want to talk to others about what they are doing with it and see their
setups and so on, whereas a product that’s kind of only used in one way
or a tool that’s very simple and can only be used in one way, probably
not that much to talk about.
00:31:44 - Speaker 1: True. And at first sight, you would think, oh,
read wise, why would they have a community? Their community is pretty
young. They started with a discord and the way they used it was they
would approach people who were in the community for a long time who had
spoken about Loseek at some points. Obviously they had to find some way
to identify people.
A good example of how Readise uses community, even though at the
service, the product doesn’t look so complex, is how they test drive
new features. So one thing they do really well, I think with their
community, which is still quite young, but already very thriving is
because they reach out to users, ask them if they want to test drive new
features.
The way they use community is by first onboarding a batch of testers
themselves, so they bring them into Discord, they bring them into an
audio or video room, showcase the new functionality. Tell people how to
get access to that functionality, the basics, and then they use that
group of testers to onboard other users. So they basically say if you
want to have access to this new feature, you have to onboard one other
tester, and that way they have little cohorts of people using the same
functionality, they have a reason to come back to the community to give
feedback, but also to ask questions from other users, so that’s how you
see.
Little cohorts of like community cohorts exist to test drive
functionality and you see them. You meet these testers in different
other little cohorts as you’re test driving maybe feature A but not
feature B, and then you have some time to test feature C.
So you come in again, you see people you already know, and like, hey,
weren’t you working on a dissertation? Yeah, yeah, I finished and then
now I use Readwise for this, like my use has changed and like, oh,
interesting. I’ve just started learning X, Y or Z. Interesting to hear
how you use Readwise, so that’s how people connect even though in the
beginning.
They might not show up to ask something or to share something, but
there’s a reason for them to show up in the community again, that is to
test something out. And I think that is a very nice way to reach out to
your veterans in your user base of people who may not come into the
community every day because they’re just busy using your tool, but then
because they know your tool so well, because they know already what’s
possible with it. You ask them to test drive new functionality and that
brings them in contact with other people from your community. So there
are several ways you can still activate community. Even when your
documentation is awesome, like the product is relatively simple, your
feature set may on the service look like it’s locked. There’s still
reasons for people to show up, even veterans, I think, in the community.
00:34:43 - Speaker 2: Mark, what are some examples of great communities
in your experience?
00:34:48 - Speaker 3: So I keep going back to this more network oriented
community. I think as a proprietor of a business or employee of a
business, we often initially think of a community as like the space that
we bless for people to talk to each other about our thing. And that has
an important place and for some companies it’s a very big deal. But to
my mind, a lot of the most interesting communities and a place we can
learn a lot is more network-oriented ones. So let me give you two
examples.
One that’s sort of halfway in between would be the communities that
form around specific games. And these are huge, you know, there are
millions of people, a bunch of people who make their full-time living in
them, for many people it’s their main hobby, and so on. And these have
varying degrees of support and guidance from the central commercial
entity, but a huge piece. of it is just people talking to other people
about their interests.
At the base of it, that’s what a community is, is people talking to
other people about stuff they think is cool.
And then you can go kind of fully networked, and I would give the
example of econ Twitter. So this is the group of people on Twitter who
talk about economic topics, and obviously that’s not blessed or
controlled by anyone. It’s just people talking about stuff, but it has
these incredible emergent properties where people find all kinds of new
interesting ideas and data and theories and find cool people to follow
and it’s kind of its own whole thing.
00:35:59 - Speaker 2: Yeah, for me, communities, at least my favorites
that I’ve been a part of over the years, and many, most of them
actually are technical or entrepreneurship oriented. I was part of the
Linux world kind of late 90s, early 2000s. Ruby on Rails was a big one I
was part of later on.
Silicon Valley, you could argue. A type of community. It’s also an
industry and a field which has its own qualities, but also on a smaller
scale things like, you know, when I adopted a dog going into the kind of
subreddits for raising a puppy and you have people who are again going
through that same struggle as you, you’re trying to learn from each
other and trying to get empathy for your challenges, but also find
solutions.
So each of those in their own way contributed to my life, but for again
solving problems I have personal growth, that sort of thing. But also
then yeah, you make connections with people that can turn into lifelong
friendships or just be very rewarding in and of themselves, almost kind
of separate or removed from that core shared interest.
00:37:00 - Speaker 3: I think the puppy Reddit is actually a really good
example of how, to my mind, the two fundamental driving forces of
community on which all of our stuff is based is searching and sharing.
So searching is, I have a problem, which is a new puppy, I need help. So
what you do is you go into T. go and you type puppy Reddit and you go on
YouTube and you type puppies.
00:37:18 - Speaker 2: Well, realistically, it’s probably even more
specific than that. It’s, you type in puppy won’t stop barking or
something to that effect, you know, I’m at my wits end and then you
suddenly find this place where all these knowledgeable people are
gathering and sharing their stories and sharing their solutions and
suddenly you have this sense of, oh, I’m not alone in the world in this
challenge.
00:37:41 - Speaker 3: Yes, and eventually you get there, but that
emerges from these two. In the end, it’s just individual people doing
individual stuff. They’re searching for stuff and they’re sharing
that’s the other fundamental urge, which is I’ve accomplished
something, I have some insight. I want to share it, you know, I’m the
puppy whisperer, so I make a YouTube video or whatever. And then from
that you get all these emergent properties up to it, including people
who make their full-time living supporting these communities.
00:38:03 - Speaker 2: Yeah, the pet example also shows how you have
people who contribute to the community who are Call them like gurus or
they’re just professionals.
So for example, professional dog trainers, there are some fantastic
YouTube channels where people do this stuff for a living.
I think for them it’s probably a, you know, a lead source for their
business or they’re selling a book or something like that, but they’re
very genuinely making these videos showing them, teaching about a
specific thing you might train a dog or a specific thing you might need
to deal with, showing it with.
Real dog talking about it, you know, in this live way and in doing so
providing you some value and then of course you can follow them and
maybe that leads to their business.
So they’re a very knowledgeable person sharing because that benefits
what they’re doing in their career, but then another category is often
someone who just solved the problem and they’re so relieved and they
want to go and share that maybe in some cases with the of the community,
right? You see these posts where it’s update this problem I wrote about
that was destroying my life. We found the solution. It was, you know, I
combined a few ideas that you folks shared. Here’s where I landed, they
share their solution and in that moment of breakthrough, as you said,
they want to share, they feel excited and compelled to share with
others, not because they think, yeah, just because I think it’s a
natural desire when you’ve had that moment to want to pass that
knowledge on somehow.
00:39:24 - Speaker 1: This is interesting also, Mark, that you say most
communities are made up of searching and sharing.
00:39:33 - Speaker 3: It’s my argument is that that’s where they
start. And then you get like higher order behavior that we would more
typically associate with community like, you know, collaboration and
real-time discussion and belonging and leadership and you know, all
these things, but I like to study the emergence of these phenomenon,
that’s all.
00:39:49 - Speaker 1: Yeah, and I think that is also to maybe segue into
the platform discussion because I think for many community builders, the
perennial platform discussion is very interesting. What is better is a
Facebook group better than a subreddit or a proprietary forum like that
I host myself better than Discord? I think first the discussion is what
kind of medium do you want to facilitate, so. Obviously, there are
emergent communities where there is no driving force from a brand, and
you see those often pop up on social media. So Twitter, now Twitter also
has community, so you see users create in the case of loxy an unofficial
loxy community. We obviously as a company started a Discord, which we
promoted. We started a subreddit which we promoted, but that’s not
always how it goes for many projects, especially open source projects.
Like it’s almost as if the community sneaks up on the creator. I’ve
spoken to open source creators who said, I didn’t expect this project
to blow up. I don’t have time to manage it. I hope to just pass it off
to someone as soon as possible, so we have other maintainers, so that
can happen.
00:41:09 - Speaker 2: And a canonical example of that one is the notion
TikTok. I think this was a couple of years ago.
Notion actually was having some scaling problems because I think it was
mostly students that were sharing their personal dashboards and how they
would put it together and it was a lot about aesthetics and things like
that.
The overlap of the sort of people that work at Ocean and the people who
are on TikTok, especially a couple of years ago, was not big and so they
were totally caught by. Surprise, where is all this new usage coming
from, but that’s a good thing.
You want to invest in that or double down on it or support it because
community that emerges is even better than when you’ve seeded yourself,
but you may also be in a position, I think I suspect they were, where
they go, wait, what is this weird new way of communicating? We need to
learn the language of this platform that’s TikTok, where we see that
our users have emergently chosen to gather.
00:42:01 - Speaker 1: Yes, and I think it’s very important as a brand,
once you see that there are communities about your products that you tap
into that and that you support those existing communities instead of
saying, oh, we’re going to start a competitive platform and then siphon
off all the members. I think that that will not do you a lot of good in
the community, especially not as people put in time and effort into
cultivating those early communities outside of the brand.
At some point, I think you’ll have to. Manage it a little bit as you
see needs pop up within the community.
So very concrete example within Loxy that our Discord is now growing
towards 20,000 people, so 200, and it’s becoming a wild west because
you see people ask questions all day every day, and many of the
questions have already been answered. So what Mark pointed out, so many
communities, they come by because people are searching.
If I look at Discord communities, it’s often the default is asking
instead of searching, and that is I think because searching in Discord
communities is so like search and discord is not good, it’s flawed in
many ways, and then also how it organizes discussions unless people say,
oh, I’m going to open a thread now, it will be like scattered around,
other discussions will be going through. So as long as a community is
small, I think chat. And basically the scattered nature of a community
are fine because people like little packets of people, they are finding
each other and they’re small enough that there can be real time
communication and people can benefit real time from each other.
But as the repository of knowledge grows, you want to have some way to
capture that knowledge so that people don’t have to ask the same
question over and over again. So that is a conundrum that we are in
now.
Where we have a wealth of knowledge in Discord, it’s almost impossible
to search and to avoid more knowledge from leaking basically through, we
are trying to direct more and more people to our forum, and it’s a
little bit of a confusing name, but discourse is a very good forum
software, so not Discord with a D, but discourse is really good forum
software that has Many of the principles that also the modern note
taking apps have built in like bidirectional linking, they have built in
and mentions and stuff like that, so I can link to a post and the
creator of that post will get a notification that someone has linked to
their post and at the bottom of that post will appear all the other
posts that have linked to that one post, so you have a sense of
bi-directional linking.
It has wiki functionality. So what we are now trying to do is encourage
more people to write on the forum and then that our moderators curate as
much as possible, moving, finished and answered posts to a section of
the forum where they’re easier to find, helping people search the
forum. So that’s where the knowledge in the community becomes. Like
you’re creating a canon of all the knowledge in your community by
providing a platform where it becomes easier to sort through that
knowledge.
So in the beginning, I think you want to make it very easy for people to
ask and to share. Chat is a great way, but then at some point you will
see that people are asking the same questions over and over again. And
then I think that will become a very Good impetus to look into other
platforms that will help you manage or at least make knowledge
searchable instead of having that big mess on social media, like
Facebook groups, Reddit, Discord, and then have it centralized and
indexed by search engines, preferably.
00:45:56 - Speaker 2: Another company that went through a similar
transition just recently is Kraft, and they also had a Discord or a
Slack, maybe I think it was, got quite busy, and they recently set up on
Circle, which is another kind of, yeah, forum style product, and yeah,
same thing where they can curate it much more and you come in and you
have A help section, but also an inspiration section.
Here’s some workflows. Here’s where you post feature requests.
There’s a lot of curation beyond just the very most basic, like let me
pin a thing to the top and that it’s just a, you know, a flowing feed
of, you know, real time information that is sort of very hard to sort
through if you’re new to it.
00:46:40 - Speaker 1: Yeah, and that knowledge, I think also when it
comes to a platform because you’d mentioned Circle, I’m not too much
into the loop of Circle in recent months.
But I know for example, Discourse, it does really well in combination
with Google, so the posts are really well indexed so when people search
online, it’s very likely they will end up on a forum post on the
official Lexi for.
So I think that is also an important consideration.
So Google or Dotao or any other search engine, obviously, but I think
for Taking your user base into consideration, like what are the tools
that people use to find knowledge? Are they inclined to look in your
app, so not go on any search engine, but just look in your app for
guidance on how to use the tool.
If they do, then you can, for example, say you want to connect with our
community, here’s a link to our form and then you send them to circle.
So in that case, even though if The platform is not indexed by search
engines.
If the majority of your users access your knowledge anyway outside of
search engines, just by going to it directly, that may be a good
choice.
In the case of LogSeek, we have a very big subcommunity of programmers,
coders.
What do programmers do? They use search engines. They’re not going to,
oh, I go into this menu in the app and then click on help and then
scroll down and oh, here’s a link to commute. They don’t do that. They
just search like problem, help log seek, and then they find a forum
post, and that could be their entry into the community. So, I think it
really depends on what kind of user do you have and what are their
behaviors. So again, coming to the user archetypes, what are the
behaviors of your users outside of Your products, like how do they
interact with technology in general? Are they independent curious
people? Maybe in that case you want to create a different type of
documentation or community or knowledge repository than you would for
maybe a less tech minded person who likes to scroll through windows and
visual menus instead of searching for something, for example, using
text.
00:49:04 - Speaker 3: It’s interesting to me that video hasn’t come up
yet, because I feel like increasingly, the default behavior for people
looking for stuff is to type it into YouTube, because a lot of the
search engine results that we get now is just algorithmically generated
trash.
But on YouTube, for whatever reason, the results still are pretty good.
I think that has to do with, it’s kind of hard to fake a video and
there’s a certain proof of work that comes with highly produced video.
And obviously video is very high bandwidth. So I’m just kind of curious
how that resonates with your experience with the logs to community is
video and YouTube is that a big part of it or people are just all text
all the time?
00:49:39 - Speaker 1: I think it depends on the type of user.
So our early user base, we’re definitely mostly programmers hanging out
on GitHub, reading read me files, just testing stuff out.
I think now that we’re slowly attracting so adventurous users, but
maybe not the coder types, I think that has spurred the creation of
videos. So obviously we ourselves are producing videos by recording our
sessions. They’re long sessions, so again, it attracts a specific type
of user who is willing to sit through a one hour demo of Fluxy queries.
Some users just want to have a 2 minute video, but that’s generally not
our user base. And then obviously you see more and more users just
create videos themselves, I think, as Adam pointed out, it’s also
experts who have maybe some business adjacent to Lockek, so maybe they
don’t sell Loxy courses, but they help professionals or teams, small
teams, manage knowledge. That is definitely something I did when I was
freelancing, so before joining Oxy, I was helping small teams. And I
think that is an excellent marketing material for those individuals to
provide value to individuals, get to know a tool, and then what we do as
a company is to really give those creators a platform. So we have a
weekly newsletter, which is a curated newsletter, contains plug-ins and
themes created by our users, but also videos and other walkthroughs. And
there I definitely see 90% of user generated content are videos, and I
think also because it’s the nature of the tool. It’s a text-based
tool, obviously, but the way you use it is very much obviously tied to
an interface. You’re not just working with text, you’re working with
text in a specific interface in an outline format. So it’s much easier
to just show how you do something than to create screenshots of
different steps that you take. It’s much easier to just show it in a
video. So I think that is really something that has boosted the energy
in the community where people are just sharing off the cuff videos, like
many people just, they don’t put too much. Thought into it, they just
show, oh, this is how I annotate PDFs and then turn them into flash
cards, for example. And then other people respond to that. It’s like,
oh, interesting. I have now created a plugin that supports this workflow
of yours better and that’s how you see the energy started to become
more and more as people are learning from each other and spotting
opportunities to make things easier. And the video is definitely one of
the most driving factors in that.
00:52:26 - Speaker 2: And Mark, I think the point you made about the
proof of work where it is more effort to make a video, even a pretty off
the cuff one like you just mentioned thesis, which is, you know, a quick
screen recording or something like that.
Still, the bar there is much, much higher than typing some text into a
real-time chat or even a forum.
And so for me, I guess you could say there are YouTube communities, but
I feel like there’s more like YouTube channels. And I like to subscribe
to certain channels and maybe I read the comments sometimes, but not
usually. I’m not sure if it gives me the sense of that’s where I go to
meet other people with similar interests, the same way that I would for
something like a Reddit or a discourse or a Discord.
00:53:12 - Speaker 1: I think one interesting development is maybe not
people posting stuff to YouTube, but answering for posts or chat posts
using a loom video. That’s what I see a lot.
Obviously those are not easy to find as a YouTube video because they’re
not indexed, and I think as a community manager, I see it as my job to
reservice that knowledge, so I see maybe a loom video mentioned or
posted in the Discord. I will save that video and then mention it in a
newsletter.
So that’s how I resurface it because the newsletters also posted to our
blog, then that video suddenly becomes indexed by search engines.
The way I see it, it often starts by answering chat.
Maybe then in a forum, you get people who are maybe not an expert yet,
but they are growing expertise and then they think, oh, I’ve seen this
question 5 times already. I’ll just quickly record a Loom video without
me in the screen, just my screen, and then I talked to the screen
basically for 5 minutes, show my workflow, very unpublished because, you
know, Loom doesn’t have any editing features in the free version, and
then you just post it.
For many people, I think that is. Like an entry to content creation, so
it becomes more likely the people that do this at some point they will
then post something to YouTube.
But in the intermediate, in the meanwhile, you can already help and
facilitate people because maybe. The community is not even aware of
something called loom, and you just have a one page here where you say,
hey, you want to answer a question, instead of typing it out, here’s a
cool tool. These are 3 steps to use it and then just paste the link to
the chat to the forum and it will show the video itself, like a very
quick walkthrough.
To help your community share knowledge by helping them understand how
they can share knowledge, because maybe they want to share, but they
have no idea how they can share and then nobody has to become a
YouTuber, they can already create videos very easily.
00:55:20 - Speaker 2: Yeah, screen recordings are great because maybe
you want to tidy up your desktop a little bit or something or tuck away
some information you don’t necessarily want to share publicly, but by
comparison, filming yourself and or your room, which creates a much
higher sense of, I don’t know, production value or a better comb my
hair or better like tidy up my background a screen recording so it feels
much more within reach at a casual level or for someone who’s not
already a creator.
00:55:50 - Speaker 1: Yeah, I’ve once attempted doing YouTube videos
where I would talk into a camera and then I found that so nerve
wracking. I just kept editing the video that I thought, how can I still
do this without having that anxiety on me? And weirdly enough, for me, I
know it’s not for everyone, but for me doing live sessions and then
just really framing it it’s a live session, stuff can go wrong and then
do no editing, except for maybe cut off the beginning and the end.
And then just post that, that somehow took away, that sounds very weird,
but took away social anxiety because I thought I frame it as something
that can go wrong and I’m still putting out the contents and I’ve
noticed also with people who may not be recorded, we facilitate that as
well by having office hour sessions where we just come together in Zoom
and then I ask people just share something that doesn’t work. And then
they share their screen, maybe not even their camera, and them knowing
that it’s not being recorded, will not end up on the web, that already
takes away some anxiety from people to share their stumbling blocks or
what they’re stuck with.
So they’re not even sharing their knowledge, they’re taking a first
step by stepping up and saying, I have a problem, please help me. And
then I noticed that over time, the more someone does that, next time you
see them in office hours, they have their camera on. Next time they’re
in the office hours, they’re maybe answering stuff in the chat. And
I’ve seen people that were super shy end up in YouTube videos where
they’re being interviewed by other people. So it’s a journey that
people go through.
Some people are just very outgoing and they’re comfortable on camera.
And they just do this without a problem, but for many people who are on
the internet and want to participate on the web, want to become part of
a community, at some point for many communities, it’s normal that you
show your face or that you at least some people like you dox yourself,
quote unquote, and you are putting yourself out there.
I remember for me it was super scary because once I started to record
some videos online about language learning. Some colleagues found my
videos and they were making fun of me. I was like, oh yeah, I’m putting
my face on the internet, and now it’s so normal, and I think for many
people, the more you do it, the easier it will become to ask stuff, so
starting by asking stuff and then just sharing what you know.
And some people made their careers out of it. And even if not their
careers, I’ve definitely heard of people who have become active in
communities, on forums, on chat, in live sessions, and now they have
made a promotion because they have become more assertive, they’ve
become more comfortable presenting. So it has all these secondary
effects that you may not go into a community with because you go into a
community because you have a need or because you want to bond with
people who are interested in the same things you are interested in, but
it has secondary effects as you hang out with people and talk about
something you become better at articulating your ideas or explaining
things to people or asking questions to clarify things. That really
becomes a valuable skill in itself. Which many people I think also for
but especially in this digital economy where people will have to turn on
their cameras and explain things via the internet, this will become an
invaluable skill and most communities are safe spaces to practice this
skill.
00:59:27 - Speaker 3: This reminds me of a pattern that I often see in
communities, which is like power levels or character progressions or
skill trees.
No, no one starts being a Keystone member of the community. You start by
logging in for the first time and saying hi, and then there’s typically
a progression.
Maybe you ask a question, maybe you answer a question, maybe you’d be
someone who becomes recognized as providing good answers.
Often with the communities and people get promoted to become moderators
where you have additional enumerated powers.
And then often in big enough communities, people can get, you know,
further promoted to becoming a paid contractor and eventually full-time
paid staff of the kind of lead content creator.
In the same way that we do hiring with, I really like that model of
there’s this kind of gradual ramp where you have increasing levels of
responsibility and commitment and demonstratability that kind of ramps
over time.
01:00:17 - Speaker 1: Yeah, I think it’s interesting that this has
become an opportunity in recent years where you come up through
community and then join the projects that you’ve been a fan of for
maybe years. Because before, like when I look at community, I’ve been
part of communities for almost two decades, again, from video games to
note taking tools. And I never had the intention or the expectation that
I would make my career out of that, that I would hang out in forums and
life Zoom sessions with people just nerding out about my favorite tools
for a living.
But now, in recent years, that has become a possibility. For me
personally, that possibility opened when pandemic started and we went
into lockdown in the Netherlands and my whole company. We basically went
remote from one day to the other, and then after 6 months, I thought I
am still tied to this one place where I work, even though the stuff that
I do, I could do anywhere.
So why not branch out on my own? Why not dedicate my time to stuff that
I really enjoy talking about and then see if I can make a difference
there. And that’s how I in the end landed this this job at at Loxic and
I’ve seen this more. Where people, maybe not even with the companies
that they are fans of or that they’re writing about, but other
companies that see, hey, the way you write, and it can be just on
Twitter, or the way you explain this products on video, we want to talk
to you because we’re looking for maybe educational content creator or
we’re looking for a support person because obviously people coming from
the community. For companies, it has so many advantages to hire someone
from the community. Obviously, it also has some downsides, especially if
there’s drama in the community, obviously with that baggage that can be
negative. But then on the other hand, you have people who know
everything about your tool and they’re passionate about it. We have
started hiring people from the community. I am an example. We’re now
having several contributors who are basically a part-time contractors
because we support them every month. We have a commitment to them that
we pay them a certain amount from the community fund because we have
donations. That we pay them to create specific pieces of functionality,
and maybe they have a gig with us for 6 months, and then they move on to
another project that they’re passionate about. But in the meanwhile,
they’re really sharing their knowledge, they’re interacting with the
community, and then after. Even if after they have finished that
project, they are part of the community, so they keep getting that
feedback. I think that is very valuable and it’s really changing how
people work, and I think more people, especially with technical
capabilities, will find their way into professional work through these
communities and maybe not even set out with that idea because I think
like you said, Adam, you need to show your worth and you cannot. Just
come in and claim your stake. You have to prove yourself, you have to
help people, and then at some point you will get noticed. I really
believe that this will, for many people replace their CV. They will get
offers from companies who are impressed by the work that they’re doing
online already.
01:03:46 - Speaker 2: Well, certainly we see this in the open source
world or if you work on open source projects or side projects or things
like that, that can be absolutely a path to employment and yeah, you’re
building career capital essentially. That leads me to actually another
question that I think is specific to your company, but I’ve seen in
plenty of other places you mentioned plugin developers and there’s
obviously the developers who are working on the code itself and I know
something that’s common in many open source communities, you really
need to bifurcate.
A community or a discussion place for users of the product from
developers of the product because they have very different interests,
concerns, maybe even the ways that the developers talk about the inside
of it doesn’t even make sense to users in particular and it becomes
clutter and again if you have plug-ins that almost becomes a third.
category there I think you mentioned or maybe at some point we mentioned
obsidian. They have I think a pretty strong kind of plug-in ecosystem
and community around that. How do you think about the segregation or
integration of those three classes of people involved with the product?
01:04:52 - Speaker 1: Hm, yeah, that’s a good question. This is
something I’m struggling with and that is a constant discussion. And it
actually just gave me an insight through that question because now I
realized why Tencent, our CEO is so adamant about keeping our code
contributors on GitHub as much as possible and use, you know, the GitHub
functionality like comments and the issues and the boards. For the code
contributors as much as possible and then have the beginning and I would
say also power users in another community, so the forum and the
Discord.
Obviously, we have Discord channels where our developers are, where we
interact with plugin developers where we answer questions. But it’s
funny because if you look at our channel list, it’s all the way down,
it’s not where generally the average user would go, like we have all
the help channels and all the more mainstream workflows, we have all at
the top, all those channels are at the top, and then somewhere at the
bottom, you have the development channels and then when people report
bugs and they come with very intricate bug reports, we always send them
to GitHub because we say that is basically where our developers hang
out.
Yeah, I think there’s something to say for that and then also for
combining everything because I think the question you should ask
yourself is what kind of user do you want to attract? Like maybe you
only want to have that hardcore technical user. In that case, maybe you
will not even create Discord, you’ll just completely do everything on
GitHub. That will be. Basically be where your community lives because
you can create a wiki there, you can have boards, you can have
discussions, so it could work as a community platform, but obviously,
only very technical people, programmer type people will hang out there.
So if that is your focus, I think that would be all right.
Then on the other hand, we also have users who even though they are
siloed off from all that code stuff, they still feel to become a power
user and lexic, I need to become a coder because they see, for example,
the way to create a table with your notes, you instead of a notion you
would point and click and just filter your tables. In lexic, you need to
write a query code and that can be very daunting for people. So in that
case, you want to have people find educational materials, have a channel
where they can ask questions, but then when you look in the channel
where the people hang out that have the answers, they tend to be very
technical people and say, oh, don’t bother with this query, just write
some data log query and then they come with uh 20 lines of code and
people are like, OK, I’m going back to notion. So it’s very
difficult.
So this is something we struggle with, like a company like Kraft, for
example, you already mentioned Kraft. As far as I know, it’s not open
source and it’s a different type of community where they are more
focused on the end user, whereas we as a community are not just focused
on the end user, we have also open sourced our code and we have open
sourced our documentation. So we want the more technical. People to
definitely come in and we also want to have a path for the less
technical people to have some kind of progression where they become
progressively more technical, hopefully to a point that they can
contribute to the product. So either documentation, but there are even
people who made the step to creating plug-ins and then from plug-ins
becoming a core contributors where they actually push code for the core
products. And anywhere in between, but I think you have to be conscious
about it as a brand and then really stick to it.
So maybe some people, like a very vocal minority of non-technical users
will say we need to have a point and click interfaces for this type of
functionality, but maybe that’s not where the majority wants to go. So
as an open source project, obviously the people who code, they decide.
So you can scream a lot as a user on the sidelines, but many people at
some point realize if I want to support this specific workflow, I will
need to build something. And we’re unapologetic about that. Some other
products will say, no, we don’t, we want to shield off all the
technical part, all the technical stuff, and just focus on people using
the product as we intended it. And we have a different philosophy where
we say we want the user base to influence how the product works and
where it goes and how it’s shaped.
01:09:32 - Speaker 2: Well, before we go, I thought it would be nice to
tease a little something that’s coming. We’re now working on a muse
community, and of course we want to be thoughtful about how we create
that and make sure it’s something that’s in tune with our values and
our approach, but one of the reasons we are Speaking Ramses is that you
gave us a few tips on how we might think about the best way to get
started with that. So I’d be curious if you could summarize for the
listeners some of what you told us and maybe just general advice for
creators that want to kickstart their community.
01:10:07 - Speaker 1: Yes, I think the most important thing to keep in
mind uh when starting a community is that the community is for the
community members.
So it’s very easy to step in the trap of thinking this is our
community, it’s our brand’s community, it’s not your community, it’s
the members’ community.
And then they will come in with questions and they will share their
knowledge. So I think it’s very important as a community facilitator,
so you as a brand, you facilitate that community. To highlight useful
things from the community, so useful answers or tips and tricks,
workflows. I think that will be very useful.
Also looking at how you’ve already structured your knowledge, the
knowledge about your tool where you showcase work flows. I think that
could be very useful where you showcase some things from the community
and then actively involves your community.
With testing new features, so maybe you can consider the people that
showcased the most proficiency with your tool, like based on the answers
they’ve given to people that you invite them maybe in a beta tester
group.
Obviously, you need to be careful with this because it can create some
jealousy. I’ve definitely seen that in communities where people say,
oh, how do I get access to this beta program? So you need to be careful
with that, but I think it’s a very good way to involve your community
to have a reason for your community members to keep showing up, to keep
coming back, because especially for the veteran members at some point
will be less appealing to come back because they will answer the same
questions over and over again.
Use that and then as you grow, keep curating those useful nuggets of
information, find some way of making them easy to find either in your
knowledge base, documentation, and then really provide a platform to
community contributors.
So in your case it will be mostly knowledge that is shared on how to use
your tool and just keep that positivity going where people just share
how they use the tool.
Be very mindful of criticism, so that in itself can be a very powerful
marketing tool, how you react to criticism when people maybe are
blessing you in your community might be very attractive to silence them
or going against them.
I would say thank you for your feedback and then just ask questions to
clarify what they mean and what they run into and what are the downsides
and what would be the potential upside if it would work the way they
expect the product to work. So really engage in a dialogue and that for
you as a tool builder, I think can make it a very valuable learning
experience as well, not just for your community members but also for
you.
Secondary effect will be that the conversation between members will give
you insights on how to improve your product. So those are my main
starter points. Make it easy to find stuff, listen to your community to
improve your products.
01:13:08 - Speaker 2: You make it sound so easy. I think in practice it
is not, but as with a lot of things, the core principles that make
something good are simple enough when laid out, but sticking to it over
the long term is the challenge.
01:13:22 - Speaker 1: Human relationships are always messy, so I’ve
definitely come across as a jerk, where I had to apologize to people and
say sorry I misunderstood you.
And yeah, it’s an old cliche, but I think you should be humble as a
product creator and listen to your community.
If you value your community, obviously, you can also think my vision is
the only thing that counts, and I don’t want to listen to my users even
on how to build my product.
That’s a choice you can make, but then obviously the question arises,
why do you have a Community.
It’s like why would you want people to figure out how to use your
product if you’re going to dictate anyway how they should use it, then
just create kick ass onboarding materials and ignore the whole community
aspect and let people just congregate on their own on social media
without you meddling there.
But if you value your community, you have to listen to them, you have to
engage with them. And then I think it can be a very valuable
relationship between your user base and also the team.
01:14:26 - Speaker 2: Excellent advice. 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 muapp.com. Ramsays, thanks for helping
us all be more aware. I think as product developers we are pretty good
at twiddling the bits inside the computer to do what we need. The
community, as you point out, is a very human, almost a fundamental human
endeavor and takes a very different set of principles and skills to
bring that to fruition, but I think one that’s very worthwhile.
01:15:00 - Speaker 1: Thank you for having me. It was fun talking about
community and also how we can shape our products.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: This ends up becoming a question about file
standards more than it does about application functionality. I can take
a notion document and fairly easily translate that into a text file, a
very linear document format. There’s currently not really a file format
for spatial canvas. Right now there’s just not a good way for Muse to
talk to another spatial canvas app.
00:00:30 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Mark McGrenigan.
00:00:45 - Speaker 2: Hey, Adam, and another colleague, Adam Wulf.
00:00:48 - Speaker 1: Hey everyone.
00:00:49 - Speaker 2: And Wulf, I understand you recently spent some
time in prison.
00:00:53 - Speaker 1: That’s true, and it’s so good to be out with
everyone again. I, of course, was not technically in prison, well, I
guess I was.
I volunteer with a program called the Prison Entrepreneurship Program.
They actually help felons who are near release go through and kind of 3
month entrepreneurship school. They do character development and then
learn about starting their own business, and really help them get their
feet under their ground again, find their sea legs when they get
released.
So they do a lot with employment. And housing and support, and a lot of
education on the inside of the walls, and a lot of support on the
outside of the walls and family reunification, and it’s really just a
wonderful program that helps. Inmates helps their families, and ends up
helping society.
And so the, the big number that matters is national recidivism, which is
the number of people who get released from prison and go back into
prison, is extremely high. It’s somewhere around like 40 or 50% end up
going back into prison.
And graduates of this program, it’s as low as like 5 or 7%, and so it
just has a dramatic effect for these men and for their families. And so
it’s been really fun to volunteer with the past. Gosh, probably 5
years, something like that.
So, yeah, if anyone ever wants to be locked in prison with me, then give
me a shout out. We’ll make it happen.
00:02:18 - Speaker 2: Sounds like a really worthy program. Well, we’ll
link them in the show notes. I’m definitely a believer that how a
society treats the people that need to be removed for sort of justice
reasons and what you do when they’ve, you know, fulfilled their debt to
society, as the saying goes, and how you make a transition back to
normal life says a lot about it. It seems like a really great program
you’re involved in there.
So we can jump straight into our topic today, which is listener
questions. This is our second mailbag episode. Mark, you and I did one
year and change back, and I think it was quite a lot of fun to go
through all the questions people submitted. And now feels like a good
time to me just because we’re 2 months or so out from the launch of our
2.0 product and the dust is still settling, but in many ways we spent a
lot of the last two months just answering questions through all channels
Twitter. Hacker news, but most especially through our support channel,
that’s [email protected] and the in-app thing. So we’re in a question
answering mood and we have a lot of common questions that we thought
would be good to kind of address on air as well as we put out a call on
Twitter for folks to submit questions. We’ve got lots of really
interesting ones, more than we’ll have time to answer, so we’ll do our
best to get to as many of them as we can. You fellows ready? Let’s do
it.
Yeah. So I guess we’ll start with roadmap just because that tends to be
the biggest or most numerous questions are in that category, what
features we building and when, but we can go from there and how people
use Muse or how we use Muse, things about the broader ecosystem, tools
for thought, as well as more even broader than that, some things about
how our team works and even some things about Ink & Switch. So the
nuts and bolts of roadmap doesn’t work for you. You can jump forward a
little bit and things will get more far ranging. But yeah, starting at
the beginning here, so I think a broad question many people ask, but
here I’ll quote from Penny Chase who basically just said, I’d like a
glimpse into the Muse roadmap, and we answered that question mark, I
think a year, year and a half ago, and I think it included, you know,
going local for sync and going multi-device and having desktop apps. So
check, has that roadmap changed other than what we’ve accomplished
since then.
00:04:30 - Speaker 3: Well, the good news is that with this launch, I
think we’ve got a lot of validation on the direction that we’ve been
going since day one, really, which is this idea of a tool for helping
you have better ideas that spans your iPad, Mac, iPhone, eventually the
web, and is very rich.
And what we’ve heard from our users, I think, is, yes, and let’s see
the rest of it. And just to give a few buckets there, I think one
building on the local first sync, you have the phone, that’s a pretty
obvious gap for us right now, a more complete phone app, both in terms
of making the phone a better tool for getting things into and out of
your corpus, and also being able to look up stuff on the go.
You can also see something with the web, sharing on the web or even a
full blown web client. and also building on sync. We talked during our
tech episode how that’s really the foundation for collaboration, both
synchronous and asynchronous, so I wouldn’t be surprised if we see
something there. And then back in the what we call like app features,
there’s some pretty standard stuff that I think we’re missing. Better
search, linking, these are things that people ask for very often.
Another one I would say is more rich tech support. That’s a really
foundational content site, and I could see other content types like
videos and better support for free ride web pages and so on.
And then there’s a few more things I think we need in terms of like
organizing and managing your content, stuff like non-spatial collections
we’ve had on our list for a long time, a better inbox, which might be a
variant of that. But those are, I think the main buckets on the horizon
and then I still have on my medium to long term was this idea of end
user programming or like scriptability, programmability more generally.
I think that’s incredibly powerful and we have a really compelling
foundation for that. I think we need a little bit more on the core app
first.
00:06:11 - Speaker 2: Yeah, one way I’ve summarized it to myself and
others is Muse 1 was a multimedia thinking canvas for iPad only. Muse 2
goes multi-device.
We’ve got the desktop and iPad, the local first syncing between them,
phone, I think is going to be part of the 2. X series, at least that’s
my hope, kind of it’s part of that vision.
It’s everywhere you need it, and then Muse 3 is where you get into the
sharing collaboration, making it more than.
It will always be first and foremost a personal tool as something that
is better connected to the outside world, both other humans, but also
other tools through integrations and things like that.
And then yeah, maybe the end user programming feels like the, I don’t
know if that’s Muse 4 or just kind of the finishing move that ties it
all together.
00:06:58 - Speaker 1: In some ways I see use one as use the teenager and
Muse 2 as used the college graduate, and now we have all of the
education and skills and life foundation to be able to bring Muse to this
great career beyond in collaboration and teams and end user programming
and text formatting and we finally entered adulthood, I think, ready to
go out into the workforce and make a difference in the world?
00:07:23 - Speaker 2: Absolutely. Now on some specific features folks
have asked about, a big one here is Zoom, being able to zoom in closer
on some things, usually images or PDFs, and being able to zoom out
further, especially boards as your boards get bigger and more complex,
and a representative tweet on this is from our friend Marsen Igna, who
says, where can I read more about why Muse has no zoom out for bird’s
eye view of my board? Yeah, it clashes with the navigation gesture, but
I’d love to work at 50 to 75% zoom.
00:08:01 - Speaker 1: When I think of Zoom, I think of solving at least
two different problems.
The first problem is on a very large board, I want to zoom out and still
be able to work and move selections around to kind of reorganize a very
large desk or very large workspace.
The second problem is I’m working on a very large board, and I want to
quickly jump to a different location. Scrolling is currently just kind
of wandering around in the wild, and I’d really like to be able to see
a map and quickly go from the bottom left to the top right or the top
middle.
So I think whenever we do build Zoom, we need to think about it in that
kind of context of which problem are we trying to solve? Do we find a
solution that maybe can solve both problems? It’s not obvious to me
which of those is the most important to start with, or the right lens to
look at the feature through.
00:08:55 - Speaker 3: Yeah, Zoom is a very subtle challenge in Muse,
just mechanically speaking, say you want to zoom out, OK, you pinch to
zoom out on a board. How do we know that that’s different from wanting
to zoom out to the next level up? That’s a problem we can solve, right?
And you can have a quasi mode to toggle between the two, or you can have
a detent in there somewhere or something. It’s just it’s quite
subtle.
Another challenge with Zoom that we’ve known about since our research
in the lab is with these freeform canvases, especially if you have Zoom
and especially if you have infiniteness, you have this real risk of
becoming lost. Like you’re looking at this solid off-white thing and it
looks the same regardless of where you are and how far you are zoomed
in, and people just get totally discombobulated. And so we’re trying to
push back against that a little bit.
And this isn’t just a challenge for boards. We’ve also got a lot of
requests for zooming into PDFs and images. So there’s a lot of stuff
going on. You got zoom in, you got zoom out, you got navigation versus
the document, you got different from document types, got temporary
versus permanent. There’s a lot of stuff to figure out. So the answer
is we just gotta sit down and do it. I think it’s very doable. It’s
gonna take some time and some design work, and maybe some cutting of the
Gordian not as Adam would say, you know, just get the 80% in there. I
think we’ll get it done eventually.
00:10:05 - Speaker 2: We actually even discussed that as a potential
thing to work on post launch. We were looking for things that would be
more smaller projects, quick wins, crowd pleasers, just things to
refresh our palettes after working so long on this big massive release
with big data migration and so on.
And actually the conclusion we came to is it was too big of a project
because we do want to think about all that stuff holistically and even
if we do just carve off a small piece of it to do first, just doing a
kind of boring and obvious way to do it like there’s a zoom level drop
down or something like that we think will quickly create the problems
that I think make a lot of other software not that enjoyable to use,
which is disorientation and so on, and it’s particularly bad in the
infinite canvas setting, but yeah, we need it, we badly need it as
people’s boards get more sophisticated, as people are bringing in more
different types of PDFs and images as they just want to do more things.
Yeah, you need the ability to zoom and we’ll solve that hopefully much
sooner than later.
00:11:03 - Speaker 1: I think Zoom is also related to accessibility and
potentially text size and text formatting, which we’ll talk about in a
little bit. But tech sizes for some users can feel a bit small in use,
and being able to zoom into a board or into an image in PDF mark, as you
mentioned, is also related in some ways to allowing for custom text
sizes or larger headers or text formatting, just generally being able
to. See content no matter what your screen size happens to be, if
you’re on a small iPad or a large iPad or a big screen.
00:11:37 - Speaker 3: Yeah, then we’re getting into the real Pandora’s
box on the implementation side of when do you rasterize this content. If
you only have one zoom level, you have a lot of flexibility and kind of
do it whenever you want. But if you’re zooming all over the place, you
either need to rasterize later or essentially suffer the effects of
rescaling, so it’s quite gnarly.
00:11:55 - Speaker 2: A related one that’s challenging technically is
dark mode. Again, another one we’ve gotten many, many requests for over
the.
Well, years now, and one of my favorite stories actually, actually one
of the best ways to ask for features is to tell a story, as we would say
in our podcast episode about storytelling, attaching something to a
story makes it much more memorable. So one story I remember well was
someone writing that they were on an international flight, you know,
overnight flight, 10 hours, 12 hours or something, and they spent the
whole session basically with Muse and they had a bunch of PDFs loaded up
and deep reading and deep thinking, perfect opportunity for that, right?
But they’re in this darkened cabin. They turn their screen brightness
down, but it’s just still too bright and they’re kind of afraid of
waking the other passengers and so on.
00:12:44 - Speaker 2: Oh, that’s such a vivid image just blasting the
cabins, but many folks have asked for it for similar reasons or just
because they like dark mode.
But because we have the zooming interface that uses what we call
internally snapshots, which are basically those thumbnails you see of
the boards that give you this, you have this scaling transition, this
sense of seamless zoom and traveling around in this kind of open world
where you’re never loading a document or what have you, and that’s
very nice, but the snapshot rendering. actually pretty CPU intensive.
You see this also, if you log in to a new device like an iPad with an
account that has a lot of data in it and it downloads it all, the
downloading it may take a while, but then generating all the snapshots
actually will also cause your device to be pretty busy for a while if
you have a lot of boards and deeply nested boards and so on. And so dark
mode has the problem that, OK, now we basically need to generate new
snapshots for every single board and do we keep both of them all, you
know, do we make two all the time and slow down every regeneration every
time you change something for a feature that maybe most people won’t
ever use. Or is it when you switch modes, do we turn on the regeneration
and suddenly your iPad is heating up and you grinding the CPU for 5
minutes while it tries to re-render everything and maybe you just want
to check it quickly and then you switch it back and now it’s grinding
again for another 5 minutes, so totally solvable, but I guess it’s, as
with many things because we have this unique zooming interface and
nested boards, that’s something that sets me apart, makes it unique and
pretty special to my mind. But it also can make what seem like basic
features much harder.
00:14:17 - Speaker 1: I use Zoho mail for my male client and their dark
mode. It was an interesting choice because they need to be able to
support dark mode for attachments that anyone can send and so it’s not
only their own interface, but they’re trying to create a dark mode for
the content of the email itself and what they settled on was for those
attachments to literally invert the colors, which was functional but a
bit jarring.
00:14:51 - Speaker 2: When greens turn into purples and everything else,
and so there’s er colors can be really funky, especially like a picture
of a face, for example.
00:14:56 - Speaker 1: Yes, exactly, yeah, photos or anything else, and
so I’m not sure what their heuristic was for when to invert the image
and when to lead the image in plain color. There were certainly some
surprises when I first turned that on.
00:15:12 - Speaker 2: Another frequent request is search. A
representative question here was asked by Josh Job, who asks, Are there
plans for search inside the app, i.e., text? I worry I won’t be able to
find anything if I can’t search the contents of blocks if I go big on
muse.
00:15:28 - Speaker 1: I look at search As a navigation feature, almost
more than anything else.
Back in the very olden days of the internet, there was the Yahoo
directory, and you just manually search down into homeownership, lawn
care, to find the nearest nursery to get some plants, whereas now you
just go to Google and you say find me cheap plants.
I think the same thing for M where a lot of navigation is pinch in,
pitch out, pinch in, pinch out, trying to find. Where you want to go and
muse and search. Has this ability to jump very quickly from one side of
your tree to the other side of your tree and back, and Supporting the
content, both PDF content, text block content, and really making as rich
of a search as possible. I think it is really gonna open up new
workflows inside of Muse, and something I’m particularly excited about.
00:16:26 - Speaker 3: Yeah, I would emphasize that I think search is
really important for navigation as well as the more obvious use case of
finding stuff, especially on the desktop where you have a keyboard.
So if I want to go to my to do list and muse, it should be like command
PTO enter all in one flow, 100 milliseconds or so and I’m there. And by
the way, search should be. Much faster and better in use because of
local first data.
A huge issue that you have with search on most apps, traditional SAS
apps that they got to go to whatever Virginia and, you know, query the
database and then come back. And then when you load the actual page, you
gotta go all the way back again and get the data. This should all be
able to happen locally within a few tens of milliseconds. So there’s
really no excuse for searching out to be awesome and you just need to
spend a little bit of time on it.
00:17:10 - Speaker 2: Yeah, definitely slop that one as it’s important,
we definitely want it.
Everyone asks for it. Now it’s a matter of when does it, you know, when
does it bubble up on the priority list of all the stuff we want to do.
I will go ahead and reference something you and I have talked about
before, Mark, just because it was, I think pretty foundational.
We started Us, which is a book called The Science of Managing Our
Digital Stuff where they do a pretty thorough academic survey of
basically how people use computers over the last 20 to 30 years.
And looking at files and search through things like Google and searching
on your local computer and so forth, and there’s a lot of predictions
of either tagging or search or other things kind of killing the file
system and well if you kind of maybe hinted in that direction, which is
we don’t need a Yahoo style directory of the internet anymore because
we have Google.
But I think the total sum of human knowledge of Google or Wikipedia or
something is a little bit in a different category from my own stuff and
spatial navigation and particularly the sense that things live in a
place.
This was one of the takeaways from the research in that book as well,
which was things like symbolic links, for example, outside of file
references where you basically can have a pointer.
To file in multiple places, the vast majority of even relatively power
users didn’t use these or didn’t use them much because it actually is
very powerful for our brains, spatial memory to say I know where this
lives. It’s 3 folders deep. I get to it from here.
And certainly I think that can be heavily supplemented by things like
search or tagging or other ways to get at your data and providing more
approaches is good, but we felt like the foundation of the spatial
navigation is actually going back to something that has proven to just
work incredibly well for personal data sets.
00:19:02 - Speaker 3: Yeah, I do think the main use case of search is
going to be, I basically know this thing exists and probably even know
where it is. I just don’t want to traverse the whole mind palace. I
want to teleport with my search command right to where I know what it
is. There will be some cases where you are actually doing a legit
keyword search and just I’m not sure what, if anything, you have in
your corpus about that. Yeah, the navigation is really important.
00:19:26 - Speaker 1: Using search to jump into a document, feels very
natural to me, and I’m switching context and starting a new task, and
then once I’m in that task, I think it’s more natural, uh, Wiggins, as
you mentioned, to walk around the mine palace and just pinch in, pinch
out and stay in that context because A search result in jumping through
search feels very jarring sometimes to switch context so suddenly inside
of the app, and I don’t know, we’ll leave it there because it’s not
fully baked in my mind.
00:20:03 - Speaker 3: I do think there’s a very interesting question
around what is the flavor of search.
The default way to do it is that search is a feature. It’s like this
little box up in the corner and you type things and then a medium sized
box appears with links and you click on a link and then you go back and
tap.
We’ve long had this idea, again, going all the way back to the lab. of
search that’s more integrated into the flow and capabilities of the
app. So just to give you an idea, you can imagine, I’m not promising to
do this, but you can imagine you have a search view, which is like a
card and can be saved and persisted and moved and shared and resized
within your corpus. It’s like a magic card. You type in the top of the
card, and as you’re typing, the view changes to present different
subsets of your corpus, which you can then teleport through to go to
those rooms, if you will. But then you can do stuff like save this
search, you know, I want to save all my long chair references on a card
so I can go back to them later. That’s pretty cool. And you can also
start to imagine. All the things you’re building around search, like
the results for you as being a capability that’s general to the rest of
the app. Things like seeing a view over your data is something you want
elsewhere. So for example, we’ve talked about the idea of an archive.
That should just be like a different view. It’s like search is the lead
equals true and you might have some sugar in the app around that to make
it easier and more standard to access that. But I like the idea of
searches as building powerful generalized views versus a very
specialized feature and wanting to get that right is I think why we’ve
Delete a little bit on implementing it.
00:21:36 - Speaker 2: Daniel Rivera writes, uses my new go to for
brainstorming, love how simple it is for quick ideas and sketches on the
iPad, but I do wish it had inking for desktop. Is that coming?
00:21:48 - Speaker 1: I would love for it too. There’s no technical
reason we can’t have ink on the desktop.
All the code is obviously shared between the iPad and the Mac.
I think the big question is, what does that input mechanism look like?
Is there a way to Use the trackpad for ink input. Is that something
where the the mouse is generally very bad at organic ink lettering if
it’s anything beyond just a simple line or a simple arrow. Another
thing we’ve talked about is using Wacom tablets and stylus tablets that
I think could be very promising, but is obviously fairly niche use case
for a subset of users, but I think it would be a very powerful way to
bring ink into the Mac.
00:22:36 - Speaker 2: You know, one interesting thing is we already
support that, not kind of on purpose, but we’ve had a number of folks
write in to say, hey, I see that I can ink on Mac with my Wacom tablet,
but I can’t, I don’t know what, get out the inkwer or you know, it’s
sort of like partial because it just so happens that the input events
that it sends is the same as the Apple pencil and we respond to that.
So we’ve done nothing explicit to support it and it’s kind of doesn’t
work great. You could imagine if we had a lot of demand there, we would
put the effort in to make that work.
Yeah I agree drawing with a mouse is just the worst freeform drawing
even with a trackpad.
What I do think we might want is first of all, just highlighting, which
could be highlighting of text, highlighting of cards. Craft does a
really great job at this. Just a very simple way to add colors. Colors
can give you context or they just brighten up your document, which is
nice. But I think you can also look at something like a diagramming tool
where you’re drawing, say, arrows between elements or you’re making a
connection between them like an OO. So I think those things would make
sense on the desktop, the idea of just being able to kind of circle
something or try to handwrite something really hard for me to imagine
there’s anything we can do there that would have a feel that would be
acceptable from our perspective.
00:23:50 - Speaker 1: I’m glad you brought up the mind mapping because
that’s, I think the most common scenario for me on the Mac. is wanting
to draw just a very quick line between two cards, or a very quick box
around a couple of cards.
It’s a feature Leonard has been experimenting with some various designs
to start connecting cards and create a bit more of a mind map and I
think there is a way that we can create some of these features in a
mouse friendly and Mac friendly way.
That’s also balanced with not trying to create too many tiny little
features or expand Muse into a grab bag of a billion features. I think the
simplicity of Muse is extremely important, and so balancing what each
platform is able to do and what each platform is designed to do, is a
very delicate balance between supporting literally every use case on
every platform. And optimizing for specific use cases on specific
platforms.
00:24:46 - Speaker 2: If it starts to feel like a technical drawing tool
with a huge toolbar and lots of options, and let’s see, I just want to
draw an arrow between two things. Do I use the loose, you know,
wire-like connection? Do I use the structured arrow? Do I use ink and
draw an actual arrow? And if you find yourself making choices like that
in the moment, I think that’s really gets in the way of your thinking
process. So yeah, it has to be balanced against our kind of overall
mission and design values.
00:25:15 - Speaker 3: Also part of the thinking here is about inking on
the desktop as in Mac and inking on the desktop as in your office desk.
And part of the original idea with Muse was that you have these different
complimentary devices, and they’re not only used at disjoint times, you
might actually use them at the same time.
I was actually just rummaging in my archives from like 5 years ago
yesterday, and I was looking at one of the original presentations I did
about what would eventually become used, and we had this idea of you
have A desktop like a Mac, and then right in front of you, basically
where your keyboard is, you have an iPad and you’re using your Mac for
the big heads up display and seeing all these PDFs and so on.
And then when you want to do a little drawing that you insert into your
presentation, for example, you just draw that on your iPad because
that’s the device that’s better for that.
So, that’s not to say we shouldn’t have some sort of inking capability
in the map, but I would also just point out that there’s this
possibility of running two devices at the same time.
We might need to add a little bit more kind of smoothness to make that
even better, but that’s a possibility as well.
00:26:17 - Speaker 2: I do that with some frequency, actually, I’ll
kind of convert my desk chair from the sitting upright mode, good
posture, you know, 90 degree knees, feet flat on the ground, which I’ll
use when I’m typing and using the mouse, and I’ll kind of convert it
to the leaning way back mode, stick my feet up on the desk and have kind
of my iPad and my pencil in my lap, but I still have muse up on the big
monitor. I can see it live updating as I’m going and often see a bigger
view, just have a much bigger monitor of the board I’m moving around.
But yeah, if we wanted to put more effort into supporting that
simultaneous use case, one for me that would take a lot of friction out
would be having the iPad be on the same, you know, when I open it, it’s
on the same board that my desktop is on, but maybe not everyone wants
that feature. Maybe you actually want to keep them on different ones, so
I don’t know that would need some thought.
00:27:05 - Speaker 3: Well, maybe you should be able to make a search
card that’s recently seen boards and put that in your inbox.
00:27:12 - Speaker 2: Smart. So another category of feature request is
web sharing, and we’ve got a few examples here, including InterPlato
ask or board shareable and navigable on the web with a shared link, and
then Nikita, who asks, I wish to have notion like level of control on
which canvas and which depth I want to share a link. My biggest barrier
to using Muse is that I want to share my research as I do it.
00:27:37 - Speaker 1: This is something we’ve experimented with
pre-sync that was very useful for a number of users, and I think
post-sync we’re finally in a place where we can start thinking about
this again.
One of the limits in the presync era was the web share was fully static,
and there was just no ability for anyone reading it to add comments or
certainly to add content, whereas now post-sync.
We can imagine a web viewer that is a full client of Muse that is able
to interact with and sync content back up into your corpus, and so you
can share feedback, get comments and content from your team, and have
that go straight back into your muse. And so I think that’s a powerful
team and collaboration feature that we’re certainly thinking about that
sync has finally given us the foundation to support.
00:28:32 - Speaker 2: I’ll note from that earlier very brief beta test
we did where we just gave it to a few folks, the ability to kind of
share a pretty static, basically they kind of dumped your muse board to
Kind of like static image, static HTML page was not the lack of
interactivity or not even being able to add comments, but actually just
that it wasn’t live.
So I think one of the things we get with the modern web conception of
real-time collaboration, Google Docs, figMotion, etc. is that a URL
becomes a place where you know you’re always seeing the latest version
of something. So we do quite a bit of news board sharing internally. And
actually a lot of times folks send us news boards either as, you know,
PNG exports or full board bundles with feedback on the app or other
comments, which we love. So it’s a great format for sharing work in
progress and thinking with your colleagues, but it never fails, right?
You go to share it, you know, I’ll just post it in a slack as an
upload, which is a little clunky, but whatever, and then I realized I
need to change three things that I left out or that are wrong. And I’m
going back and deleting it from Slack and hoping that, you know, no
one’s downloaded it yet and uploading it again, and this of course the
whole world of email file attachments and finalfin2. doc and so on. So I
think to me that’s why we kind of sunsetted that little experiment, the
early shared web experiment, but now we do have the technology
foundation for a live, even if it’s completely static, all you can do
is navigate through it and maybe copy paste stuff in and out. If it’s
live updating and you know you’re looking at the latest version, that
is a game changer.
Alright, so one last roadmap question here is about linking hyperlink or
wiki or Rome style linking. So one example of someone who asked us is
Robert Haysfield, who says any plans on enabling users to place the same
board in multiple boards? I struggled before trying to use Muse because
I don’t know, hierarchical organization without an ability to bridge
trees makes it difficult for me to find things and pick up where I left
off. So I think for sure linking you know Ted Nelson’s excellent
branding with hyperlinking in the web is obviously hugely empowering. We
saw it in wikis. I think Notion is the modern version of a team wiki and
then Rome with its kind of invented the category of, personal knowledge
graphs, back linking. Now there’s a whole profusion of apps that do
this really, really well, often with the double bracket kind of linking
format. And yeah, I’m happy to say on that one, we’re actually working
on it right now. So for those of you who are prom members, keep an eye
on your backstage pass, some goodies coming up there soon.
00:31:04 - Speaker 1: The Backstage pass on this one is gonna be a
really helpful piece of feedback for us to hear from customers what they
think of this linking feature, cause there’s a few different ways
we’ve looked at building it.
I know Yuli and Leonard are taking the lead on this, and It’s a lot
more complicated than just, oh, put a link down, you click it and you
go.
There’s a lot of nuance in how those links are presented and How the
content appears in a link and in a backlink, particularly because, at
least for me, a lot of my boards don’t have titles.
That’s probably a personal failure of myself, but linking to something
that does not have a title, there’s not much metadata there, and so,
showing a piece of the board you’re linking into is important, but then
it gets a little confusing because it looks like a normal card, and so
how do you tell the difference between a linked card and a normal
unlinked card that’s not a mirror.
So there’s a lot of nuance and kind of how these things are displayed
and so the Feedback we get from customers in the Backstage Pass is
really gonna help us to iron out all of those little details to make
sure that this is not only as powerful as the linking features we all
expect, but really fits within the music universe and fits within all of
the rest of our content in a tidy way.
00:32:25 - Speaker 2: So another big category of questions is using
Muse, and this is a place I feel we’ve underinvested, which is that you
can’t get a lot of information beyond the mechanics of how to use the
app, but in terms of how people use it, and we have some projects in the
works on that to try to better showcase what people’s boards look like
and what the different kinds of uses you might use muse for and what
things Muse is not a good fit for, but a few questions here that folks
raised. The first one is from Alex Antozek. Who says, how often do you
guys use Muse for non-muse related work?
00:33:02 - Speaker 1: Most recently, I started using Muse for custom
keyboard organization.
So I’ve entered the rabbit hole of mechanical keyboards and building
your own keyboards. I’ve recently come up for air, and I’m just using
my regular laptop keyboard, but I think I’m gonna fall back down and
fight the dragon again soon.
But Muse has been very, very helpful because there’s 1000 parts and
there’s 1000 versions of each part, and Linking to a random Amazon link
just does not give enough context for what it is that I’m actually
looking at. And so Muse has been very helpful. I can put it in a photo, a
short description, a link, and some context about each of the different
parts and each of the different steps of construction. So using Muse to
organize all of those different parts and be able to physically see
photos of them next to the link next to the description has been a
really helpful way to map out that rabbit trail that I have found myself
getting lost in.
00:34:02 - Speaker 2: You’re just looking over my current news home
board, I think it’s about a 50/50 split, kind of depends on what big
personal projects I have going on.
You know, on the work side I have things like a little editorial
calendar for the podcast, upcoming guests and things. We’ve got the
chapter plan board that basically Leonard led the planning session and
produced the shared board.
I’d like to be able to go back and reference that things about Twitter,
I draft all our shareholder updates there.
I have a whole board that’s not news related, but it’s kind of career
related, which is I which held a lovely un conference recently, and I
have a bunch of notes from all the talks there and so on.
Then on the personal side, I have things like, I don’t know, the Kita,
that is to say the kindergarten daycare that my daughter attends, you
know, they sent out a PDF that’s, here’s the days we’re off this
summer, and you know, in some cases I excerpt out the like coming up
month, especially when it’s a critical, OK, we’ve got the summer
holiday, and how does that match up to our summer holiday and this sort
of thing.
But also holiday planning for sure. I mean, travel planning. It is, you
know, in some ways a fairly basic use case, but it’s really helpful
though you have pictures and maps and PDFs of tickets and it’s all in
one place.
I do personal journaling, you know, just classic daily pages, sit down
and write out what’s on your mind in the morning.
And then bigger projects, for example, when I was searching for a home a
couple of years ago and eventually made a home purchase, but that is a
place where the sharing and collaboration capabilities would be a big
help because there I was doing it with someone else, my partner, and so
I kind of have my personal world that’s inside Muse, but at some point
we need to share and I can’t really share it directly with her, so then
we kind of have some stuff stuck in an ocean or a Google doc somewhere,
but that’s really awkward. So, yeah, when I have a bigger project,
something like that, home improvement, yeah, personal hobbies, that sort
of thing, that tends to occupy a big portion of my home board.
00:35:57 - Speaker 3: Yeah, I also really like Muse for personal
projects, and one of my favorite pieces of it is that you can use it
from the very beginning, where you’re just literally sketching out,
you’re jotting down ideas, you’re taking little scribbling notes, and
that board can evolve over time as you add text and PDFs and web links
and images, and that rich multimedia is so important for these projects
I find I can’t imagine going back to a world with just one content
type. I also use Muse just for my to do list, that’s probably my
heaviest use case.
I’m in there every day, and that’s mostly just text, but it’s not all
texts, you know, every once in a while there’s like, whatever, you
gotta call the plumber, so you put the link for the plumber’s page on
your to do list or what have you.
And also just like that it’s two dimensional so that you don’t just
have one. Huge multi-page linear list, which is, I don’t know
demoralizing for me. So I have on the top left, it’s like today’s most
important stuff, and then way off on the right side is, you know, longer
term stuff, and you can just kind of move stuff in two dimensions. So, I
like it for that. I also use Muse as my reading buffer. So for links and
PDFs, I have a big per month reading board, and I kind of queue up stuff
there and then maybe once on the weekend, I go and read it all and then
archive that board and go back next month and so on.
00:37:08 - Speaker 2: Mm. One I’ve seen from a number of customers is
making a daily reading board where it’s actually a link or a PDF and
some notes or thoughts that was generated by that. It could even just be
like a half a sentence scribble, nothing too complex or this made me
think of this other thing, or here’s a tweet that’s connected to this,
and they just make one per day and it just scrolls vertically or
horizontally, and then they just like kind of accumulate these over
time. And it’s a way to synthesize ideas and get more out of what you
read and pull together the sparks of inspiration that you’re getting
from consuming the information hot fire hose.
So when we’ve heard frequently and I think we even addressed this in
the last listener questions episode, but maybe it’s worth touching on
here is basically about the home board and how you structure things or
organize things there without explicit work workspaces. So a lot of
apps, notion, craft, even Apple Notes or something like that will have
kind of top level workspaces where you say, here’s my daily notes, and
here’s my to do’s and here’s my stuff for work, and here’s my home.
Improvement projects and you kind of bucket things that way and they
find it surprising maybe that you have the top level home board, it’s
just like any other board, it’s a free form thing you can put stuff
however you want. You can make neatly organized, you can scroll
vertically, stroll horizontally, scroll both ways, you can have a lot of
stuff, a little stuff, it’s like completely up to you. What’s our
answer on that one?
00:38:39 - Speaker 3: So in terms of home organization, I tend to have
two dimensions going on. The first dimension is more obvious, which is,
it tends to be organized by projects, ish or domain.
But there’s also an organization along the dimension of like recency or
proximity to the cash. It’s like the things that I’m currently and
actively working on.
So what I end up having is I have a few boards, both work and personal,
that I’m very actively working on. And then I have a few more like
archival boards that are more defined in terms of the domain. So I might
have a board for my today’s to do list and a board for today’s
reading, and a board for whatever my personal project is for this week.
And then I have my muse board and my personal board, and I might even
have, if I’m just a little bit discombobulate that day, I might even
have just a few things blasted on the top level, like here’s a PDF that
I want to read, and here’s a, you know, repro case from a youth book
I’m working on.
And what happens is things filter down through this cache hierarchy over
time. And this is a good example of how we didn’t want to have too
prescriptive a setup in terms of workspaces. Like if we just said you
have to divide your corpus into workspaces, it wouldn’t work for having
the second dimension of the cash hierarchy.
Also just kind of go into the philosophy of why we don’t have a
separate construct for workspaces. It’s kind of echoes the thing I was
saying earlier about search cards, like we wanted you to have the full
richness and power of muse to be able to organize your top level in the
same way that you would be able to organize your individual boards. Like
you have all these capabilities around, you know, freeform boards and
inking and multimedia and different sizes. Like why should you have to
throw that out the window just because it’s the top level? That seems
exactly backwards.
00:40:16 - Speaker 2: I’m reminded of we talked about a very similar
philosophical point with Pallo a couple episodes back where basically on
sketch they originally had kind of an art board template editor that was
a standalone thing but you quickly realized you wanted to do all the
things to the templates that you wanted to do to a regular art board, so
eventually they made it so you could just name an art board as a
template and then whatever you do to that art board.
Goes into the template and then you don’t need to make a duplicate
editor but worse.
And I think there’s something similar where if we’d make a top-level
workspace, OK, you need to be able to move stuff, delete stuff, you
probably want to duplicate things, and at some point you go, wait a
minute, I want to just do all the same things I can do in my subboards.
00:41:00 - Speaker 3: Yeah, now in fairness to them, many, many users
who keep requesting this, I don’t think it’s just that people don’t
understand this possibility of generalized boards being used at the top
level.
I think there is some sense in which the current freeform spatial boards
aren’t the best fit for some top level use cases.
If logically, you just want to split your space into A, B, and C, and
you want that to be Coherent regardless of what device you’re on or
what size you’re looking at or whatever, or as you add and remove top
level spaces that having to manually manage that on a spatial board
isn’t exactly right.
And this comes to the topic of spatial collections, which we’ve had on
the radar for a long time. And you can imagine a spatial collection
working as follows. You put end things into the non-spatial collection,
it’s like a folder basically, and then Muse automatically sizes and
arranges these objects as appropriate, sort of like math finder.
You can imagine it it sizes and arranges them and lines them up or
whatever in a nice way. And if we had that primitive, I think a lot of
users would opt to use that at the top level where they’re currently
asking for the separate workspaces feature.
But importantly, such a non-spatial collection could also be used all
over the place. For example, my reading board should probably be a
non-spatial collection, it’s a little goofy to have to manually manage
literally 100 PDFs on a board.
Um, there’s kind of like weirdly overlapping in places and whatever.
And also, by the way, coming back to our search discussion, that should
probably just be. A view that dynamically produces a non-spatial
collection. So this is another example of how you get the right
primitives and they can apply in a lot of different places, including
this top of workspace idea.
00:42:32 - Speaker 1: I think one thing that’s interesting about the
way I’ve organized my home board is.
I have all of the projects that I care about visible when I’m fully
scrolled to the top left corner, and then the priority is based on kind
of the size of the card, and so my personal card is fairly large for
family and that sort of thing, work, I often go into that, that’s a
larger board. Then I have lots of much smaller boards.
But then I’m able to actually hide less important boards outside of the
scroll visible area, which is nice because some of those boards are
important, but they kind of stress me out because I just don’t want to
think about that project right now. And when that project shows up, I
think, oh my gosh, I haven’t finished that project, and my heart starts
racing.
00:43:14 - Speaker 2: And so if I just hide it out of view, tuck it off
camera, exactly.
00:43:16 - Speaker 1: It’s, you know, out of sight, out of mind. I
don’t have very much object permanence for some of these projects that
are a bit more discouraging that they’re still around. And so, that’s
been another nice thing for me, it’s just a trick to be able to focus
on certain projects that I can see, and then when I don’t want to focus
on it anymore, I can put it physically out of my sight, but still very
readily available, and so that’s a nice thing.
00:43:44 - Speaker 2: Yeah, you point to some interesting column folk
behaviors there that now I realize I do, but up until you just described
how you do it, I didn’t realize it’s something I do almost
unconsciously, which is, yeah, the size and the position of the board
reflects how roughly important it is or how large it’s looming in my
consciousness and that as something is still kind of current, but maybe
it’s in a monitoring state, I’ll tend to shrink it down a little bit
and move it kind of down lower, it’s down more towards the bottom.
And then eventually, once I decide it’s really not relevant to me
anymore, then I’ll move it to a board called archive. And I think Mark
you said you have her kind of project and category boards, I kind of
just go to the Gmail route, which is archive everything. If I need to
find it later, I’ll just scroll through all of it.
Which I think brings us to another question on use use and also connects
a bit to the roadmap, which is this one actually comes from our support
channels. So since it was a private correspondence, I won’t name the
person. I hope they’re all right with me quoting their words here since
I think it’s representative of the common question. So they say, what
is your recommendation for archival of old news boards? I find that
currently my main board is getting clustered and I have a number of
ideas that can be archived. I like to export the new board and add to
Devonthink database for storage. Yeah, I sometimes do the same or I’ll
periodically take my archive board when it gets kind of big and I think,
OK, all this stuff is pretty old news now, just kind of historical
interest and maybe I’ll just export it and save it on the Dropbox or
iCloud or something. But I thought this one was interesting because a
feature I’ve wanted from you is an archive button similar to what
GitHub has this for repositories. Gmail obviously has it for email.
There’s other examples, and I asked Leonard about this before we
recorded just because I know it’s part of his vision for the user flow,
and he basically says that he doesn’t think it’s useful to keep
everything you ever have worked in in one giant space and sort of it’s
nice to put something away when you’re done with it. Lets you focus on
what’s currently important and you can think of it as kind of the muse
home board is your desk is the stuff that’s active and current and
important right now, but then there’s a longer term personal library,
things that represent your knowledge work and thinking over the longer
term, and so we may eventually have just, you know, a context menu
option for archive, but then you can pull it up in some kind of a search
or. A non-spatial collection or something like that, or maybe just
automatically adds it to a board named archive, but it’s a sort of a
nice way to decide you’re done with something and put it away, but no,
you can still get to it when you want it, do the much more drastic act
of deleting, which always just feels really wrong, especially for
something you spent a lot of time thinking about and working on even if
it’s not current anymore. What do you both think? How do you do your
personal archival of boards and what do you think about potential
features in that direction?
00:46:36 - Speaker 3: Well, there’s actually a lot going on with
archiving, so there’s archiving in the sense of removing it from your
desk, which I do through this cascading hierarchy ending in what are
basically archive boards.
There’s archiving in a sense of persisting the data in a file format
that’s likely to be around and call it 1020, 30 years, which for me the
only thing that I trust for that is like playing files on a Unix
directory, so TXT, PDF, XML and JSON and so on. There’s archiving in
the sense of like freeing up disk space, and there’s archiving in the
sense of moving something into a third party knowledge management
system. So the last one I don’t do, so I can’t really comment on it.
In terms of persisting to stable file formats, I try to do that for all
of my work. I basically cascade everything that I ever do into One of a
half dozen file formats into a big directory called data, and I try
really hard to never lose that directory, you know, I back it up in all
kinds of different places and so on. That’s a nice forcing function. I
do that occasionally with Muse, basically export to a muse bundle, call
it, you know, Corpus-2022, whatever, month, day, and just save it and
forget about it.
00:47:39 - Speaker 2: A quick note for our listeners here actually,
because you’ve used the Corpus terminology, we use that internally to
talk about a one person’s muse database, the collection of everything
that’s in it. I think more publicly speaking we’ll typically say your
muse, put something in your muse, but yeah, corpus is, I think it’s a
Latin word for body, so it’s just the body of your knowledge, data,
what have you. So we use that to differentiate from board or set of
boards or a bundle export or one subset of data, but it represents one
user’s complete. Yeah, use database. Now do muse bundles fulfill that
kind of flat file format desire for you because they are zip files
containing flat files?
00:48:21 - Speaker 3: Yeah, not completely ideal, but certainly if I
ever needed to go back and get something, it’d be easy enough.
00:48:28 - Speaker 2: Certainly not as browsable as, for example,
exporting everything to PDF or even images if you wanted to take the
effort to work through the hierarchy and do an image of each board.
00:48:37 - Speaker 3: Yeah, and I can actually imagine a world where
both for this persistent durable archiving and for integration with
third party apps, you really lean on the scriptability and
programmability. You could have a little bot that says, whenever I see a
new PDF, send it to my PDF manager. That sounds awesome, but I don’t do
anything like that myself yet, I see.
00:48:57 - Speaker 1: Whenever I want to archive something, I think that
the ark has already hinted at this.
I think the Muse bundle format is a really nice one because it’s a zip
file, you get some JSON, you get all the attachments, and so you know
you always have all of your data there, kind of no matter what, and very
simple to open formats that are gonna survive for the next.
50 years, and I’ll generally save that right next to a PDF export, and
so I can open up the PDF, look at everything. If I really want it back,
I can import it into Muse. If I’m 85 years old inside of my robot body
in the future, then I can just open up the zip file and look at things
that way, and so I know that I’ve got the future safety of those
archive formats.
00:49:43 - Speaker 3: This is a bit of an aside, but I read a fair
amount of history and you always read about these historical figures,
papers, and like, basically everything is in there for a lot of these
folks, like their drafts and their correspondence and their bills and
whatever. And I asked around a little bit like, how do we have all this?
Like, how do we have all these papers? And the answer that I got was
basically people had a big box and they just, whenever they wrote
something, they put it in the box or a copy of it in the box. And it’s
not super useful the day, month, or year after you do that.
But it over a course of a lifetime, it builds up and it’s nice to have
all one’s papers. I wish I had known this when I was younger, so I
could start archiving it, but as of a few years ago, I started building
this set of documents. So hopefully that accrues over time.
00:50:22 - Speaker 2: Yeah, I’ve looked at the accumulated papers of
Darwin, of Alexander Humboldt, Marie Curie, and other kind of famous
thinkers in the past. It’s yeah, it’s a huge amount of content, right,
because it’s, yeah, every random scribble and letter they wrote to
someone, but of course very valuable for people that did do these
breakthroughs, understanding how their minds worked and how they came to
those conclusions, what their interactions with others in the field were
like.
But I wonder if there is also some function of just people didn’t move
that much back in those days, because at least for me, who’s done a lot
of moving in my life, including across continents, you know, hauling
giant boxes of papers, feels kind of infeasible.
Happily, hopefully digital archiving should be easier again if you take
the steps that you describe, Mark, because there’s many ways that
digital stuff is more ephemeral.
00:51:14 - Speaker 3: Well, maybe now we’re getting to the whole theory
of information persistence, but I think not only are we moving more
often, but I think this digital stuff is fundamentally more brittle.
Certainly the very bespoke and fast moving apps, but even basic file
formats on Unix directories, if you don’t quite actively maintain
those, they go away after 5 or 10 years, like the disk corrupts and the
media format is no longer readable and so on, whereas with a book, if
you just like don’t light it on fire, it’s gonna be there in 100
years. I don’t know, it’s a very interesting property. I think we
still haven’t fully confronted the consequences of trading off dynamism
for durability in the computing realm.
00:51:51 - Speaker 2: And for interested listeners, I’ll point you to
the Meta Muse episode on software longevity, when we take a deeper dive
into the very topic.
So one example is another question from Petty Chase, who asks how you
and maybe customers who share their use cases and workflows with you use
Muse with other tools of thought.
And so typically we see a lot of people linking from knowledge graphs.
This is where we do seemuse as complimentary to Rome, Obsidian, Logsick,
and so forth that you can link out to Muse board.
People often do that by getting the deep link.
You just basically hit copy on the board and that will give you a muse
app cola slash link.
And also you can like, of course, the other way around.
We’ve also seen folks use shortcuts to put, for example, news boards
directly on their home screen as kind of like a launch point then
obviously something like screen share, which I guess is less of a tool
for thought, but I think is important in modern work, so using use as a
real-time whiteboard or a kind of a presentation live presentation tool,
including teachers, they use it for their classes kind of Choctaw
style.
We obviously use that for presentations and planning sessions on our
team. As well. So I think those are some of the simple ones. Can you
both think of other examples?
00:53:05 - Speaker 1: Yeah, for me personally, it ends up being more of
an archive question than an integration question.
I find myself almost purposefully keeping apps separate, and when I work
in Muse, kind of process the information and create some sort of an
output, and then I’ll take that and just physically export it into
Notion is the other common app that I use for storage is kind of my
knowledge graph, my personal wiki. And so I end up exporting from notion
into Muse, processing around, doing some thinking and then exporting
from use back into notion.
But beyond that, I think links to and from are also a very nice thing,
Wiggins that you mentioned, because then it’s integration agnostic, no
matter what other apps people use, you can always create a link to and
from things and so it becomes a very lightweight interaction point. I
think there’s some risk for creating very heavyweight integrations.
Maybe we’ll talk about that soon, but it can be very limiting,
ironically, to create a very deep integration with some other app
because it forces that workflow, as opposed to allowing a lot more
flexibility with very lightweight integrations with lots of different
apps. I think there’s some balance there, but I’ve found the very
lightweight integration slash archiving export to be very helpful for my
own use.
00:54:25 - Speaker 2: That’s a great point. Copy paste, drag and drop,
shares sheets, you know, files in and out, that kind of quote unquote
integration that is basically using standards rather than needing a many
to many API integrations heavyweight thing I think is most always
better.
That said, that is certainly a place I think we can continue to get
better.
We’ve invested a lot there, but you mentioned the case of copy pasting.
In and out of notion and weird things can happen with line breaks and
some stuff comes across that seems like it should be left behind and
other things sometimes get copied in or things get omitted, so I think
continuing to improve that which partially is just the tricky challenge
of trying to kind of work out what the other app is expecting in terms
of line breaks and format content and You know, if you send the text in
one way, you get a bunch of individual blocks, and if you send it
another way, you get one giant block with a bunch of line breaks, for
example. But yeah, I think that’s important and something we can
improve a lot.
It’s a fascinating question we get from our friend Tim Lloyd. Tim
writes, text first tool for thoughts. Is that a noun tool for thoughts?
Yeah, why not. Like Rome and spatial first, like muse. So he’s
comparing text first and spatial first tools. Do you think these will
converge? To tools that are great for both. Are the current differences
more about technical feasibility and interaction challenges, or is it
actually an incompatible vision or just two different kinds of ways to
aid thinking? And if it is the latter that it’s sort of incompatible,
the sort of spatial first is fundamentally different from text first,
does that mean there’s things Muse would never do? That’s the end of
Tim’s quote, but I’ll just add on, we’ve already talked about adding
things like linking and search. What you expect from the text first tool
for thoughts. So you know what’s the limit on that? And yeah, is there
some world where both the text-based stuff grows to be more spatial or
visual and use grows to be more textual, or is there a limit on that and
they’re just sort of fundamentally different kinds of tools.
00:56:31 - Speaker 3: Well, OK, I think there’s some abstract sense in
which we’re on a multi-dimensional tool space and there’s different
points in those spaces for all the different tools like notion and Rome
and uses and so on, and theoretically you can imagine those tools
traversing the space to meet up somewhere. I think in practice. You make
foundational decisions pretty early on that tend to strongly suggest
which region of the space you’re going to tend to move around in.
So I guess I would expect some convergence among these tools, but not
100% overlap in the future.
I expect Rome, for example, will remain quite text focused and use will
remain more free form and spatial, but You will get more tech support,
you will get non-spatial support, and so on. I don’t think that
they’ll exactly look the same in the end.
00:57:21 - Speaker 1: For me, this ends up becoming a question about
file standards more than it does about the application functionality.
And I say that because I can take a notion document and fairly easily
translate that into a text file, a very linear document format.
There’s currently not really a very good file format for Spatial
canvas, and so converting a spatial canvas into a linear document.
It is currently a very difficult thing and depends very much on the
tool, and in some ways taking a document can translate literally into a
very tall spatial document in air quotes there.
But being able to convert to and from different formats, or even just
have a standard format for what a spatial canvas document is, I think
will really help.
Bridging these two worlds together, because right now there’s just not
a good way for Muse to talk to another spatial canvas app. There’s just
not a language that we both speak to describe what a spatial canvas is.
00:58:28 - Speaker 2: It’s a great point that For example, for the top
to bottom text oriented documents, I use now and basically always have
used lots of different tools. At the moment I would say I use raft and
Notion fairly equally and I use still quite a bit of Google Docs.
I think there’s a lot of things for kind of multi-writer editing
workflow that Google Docs is still the very best at. And those are all
pretty similar. You can really copy paste between them. There’s
annoying incompatibilities and little formatting things sometimes, but
fundamentally they’re the same document type. And so it would be
logical if this infinite canvas as a category or a document type does
become a thing as it seems to have been, you know, figmented the space
with fig jam. You’ve got Miro who’s doing very well. Apple is now
coming into the space with free form. And is there a dot infinite canvas
file format that you can move stuff around, or could I select everything
on my canvas and TL draw, hit copy and go over to view and hit paste and
vice versa and expect stuff to come across reasonably well, and is there
value in that? Or are these tools ones where you would expect someone to
use. Multiple of these things in their daily lives and want to move
between them versus just a more simple ejection of like, OK, I’m tired
of this one kind of canvas app and I want to bring a bunch of stuff
I’ve been doing there out into another one that I at the moment like
better. I think that’s something we’ll see as the space evolves. It’s
just still so, so new. I think my answer to Tim’s question is that Tool
for thought nerds and personal knowledge management nerds like to really
focus on very specific features and cheer for their favorite team in the
sense of which product they like best or whichev casting or getting
things done, you know, creative process, productivity system they like
to use, and that’s all good fun. But in the end, I kind of think that
all personal knowledge management and even team knowledge management.
are generally kind of in the business of essentially the same thing,
which is letting you put things into the computer, you rearrange it in
some way and you retrieve it with new insights. So in a way we are, I
consider that we are not only in the same space with the realms and
notions of the world as well as the more infinite canvas style murals
and Digital notebooks, you know, iPad inking oriented sketchbooks like
good notes, but I would also count Evernote, you know, more classic sort
of notebook keeping stuff app or even Dropbox. Honestly, Dropbox for me
for a long time was the core of my knowledge management because I do use
so much flat files and certainly back in the days when I was spending
much more time at the terminal, less these days and indeed Muse has
replaced a lot of things that I would use Dropbox for. So in a way
there’s some 27 dimensional space that you could somehow draw all these
like knowledge management tools, including just a file system, right, or
like a plain vanilla notes app that sit in this space and as apps become
more successful and they add features people are asking for. In general,
moving between apps, much as we like kind of multi-app workflows and
small sharp tools and whatever. The reality is like people like to just,
if they’re doing 80% of their work in one app, they want to do the rest
of it there as well and if you just add a couple of small features,
sometimes that’s good, so. Yeah, I kind of imagine that Muse does
actually, you know, we’ve already done a lot more with text, for
example, things like search or linking, even back linking. I don’t
know, is there an outline view someday, you know, I could imagine us
doing 20% of the things maybe that an outliner text-based linking back
linking knowledge graph would do, but never the host of it and as you
said, foundationally, that’s not the core of it, it’s not how it
feels, it’s not the core DNA to use a hackney piece of jargon.
And similarly, I expect the same elsewhere, right, that you know more
text-based tools might adding whiteboarding and diagramming and visual
features and but it probably would never be more than 20% of what Muse
does and will always be a kind of added in thing that’s maybe a little
secondary. So I think that works fine because there’s people who are
very squarely in the space of, you know, the text oriented stuff and
they just maybe want a quick whiteboard and so for them that’s fine and
muse would basically be overkill or not a fit for their needs. And
similarly, there’s people and I count myself in this category that I
don’t find myself particularly drawn to the big complicated knowledge
graphs and assembling, I guess like really long term kind of archival of
my active work is not as important to me. I’m really about like what am
I thinking about right now? It’s the project that’s on deck right now,
it’s the active thinking and as you said, Wulf, in some way there’s an
artifact from that, you write that. Article and put it on the web, you
ship the product, you finish the home improvement project, and it’s
good to have that stuff as a record of what you did and your thinking
and just for basically nostalgia reasons, but it’s not something I need
indeed would be a distraction to be kind of popping up top level in my
work all the time. Maybe I’d feel differently if I was spending 5 years
writing an epically long book or something, something like that.
01:03:32 - Speaker 1: The risk of terrible metaphors, carpenters have
hammers and they have saws, but they don’t have a hammer saw. I think
there is value that tools define the problem that they’re solving and
make sure that they solve that really, really well, and don’t try to
solve too many problems within a single tool.
01:03:53 - Speaker 2: So coming a bit to the Muse team and how we work,
we had a couple of great questions here.
Ben Shelford asked one about how we decide what features to add and what
we don’t add, what the inputs we use to that and the thinking and
conversation, and then Ruben asks, what’s your internal structure for
making decisions, which I think is kind of getting at a similar thing,
setting road maps and ultimately shipping the work. So briefly, I can
kind of describe that we have a very unusual way, I think, and I’m not
even sure if it’ll scale in the long term, but I really like it. It’s
very consensus driven and in my experience it doesn’t normally work
that well, but for some reason on this team it works. Maybe it’s
because we’re a small team, maybe it’s because we’re just kind of all
on the same page and what we want to do, but for whatever reason, we
essentially can do kind of two levels of planning. One is the Team
summit that we do every 2 months, we try to make in person when we can,
although the last couple of years, that’s been not so often, we
actually have one of those coming up here very soon in Portland, Maine,
but there’s where we really zoom out, look at the big picture, kind of
spend time on little workshops, we dig in on subsets of the technology
or the design and then essentially make proposals for what we think we
should work on, big or small, but then the chapter discuss that and then
have the The making proposals and discussing it is the fun part, then we
have the later meeting, which is the make the decision, which is always
the agonizing part because it all looks so good and we wanna, we want to
do all of it. And ultimately the consensus is not just sort of let’s
all vote but is more a sense of, I think we really let individuals who
are highly motivated. To drive a project where they say, I just really
think we got to build this thing. I have a specific vision for it and
then one of the persons says, yeah, I’m on board with that, and then
those two people are gonna be the one to go do it. And so the rest of us
say, yeah, I think customers will like that, let’s do it. And maybe it
needs to fit into a bigger strategy if we have a longer term roadmap,
you know, what’s Muse2, what’s Muse3, etc. but still. We try to be
pretty opportunistic and just follow our instincts and our hunches and
the inputs we get from customers. We are all on their support channels.
Every week and talking to dozens of customers, each of us individually
talking to dozens of customers, so in aggregate that’s probably
hundreds, and we’re in close touch with what the pain points are and
what people are trying to do, and what would add value to people’s
lives or solve problems for them. And we go from there to a weekly
planning meeting where we just basically look at that chapter plan and
say, what are we going to do this week? And that’s kind of the whole
thing, I think. Do you both feel like they captured that well?
01:06:32 - Speaker 3: Yeah, and I would emphasize that it’s very energy
oriented, but we’re really looking for who has the energy to
articulate, motivate. Design and execute on these projects. And it’s
not consensus in the sense of all 5 or 6 people need to Agree, or, you
know, everyone has a veto or anything like that. It’s more just like
the thing that has the most doing behind it gets done. And there’s also
a very large amount of trust, so by default, if Wulf here thinks we
should really do something, I tend to, you know, believe that versus
needing to go in and second guess everything.
01:07:12 - Speaker 2: Part of that is certainly creative trust. Hillary
Maloney, when she was on the podcast, pointed out her time working with
us. She was struck by how much creative trust we have, but another part
of that is context because we all have been around the business for a
good while.
Relatively speaking, and we have pretty broad insight into everything
that’s going on and we’re all serving on support.
There isn’t a lot of siloing, which is natural on a small team
generally, but I think we take that even further, so everyone has the
full context to make decisions and that doesn’t work if you have
someone who says, you know, I love to scale databases, you hired me to
scale the database. I’m going to do that. I don’t want to think about
your conversion funnel or You know what the marketing strategy is for
this week or you know what the design challenges you’re struggling with
and adjust your space.
I care about my domain. We specifically select for folks who are very
interested in everything. All three of us, for example, have been
entrepreneurs multiple times in the past and that kind of it’s fun and
enjoyable to have your hands a little bit in everything, and then you
have the context to make decisions within your domain.
And you make a great point there also, Mark, that it’s definitely not
someone can veto it, and it very often happens that, yeah, 1 person, 2
people, 3 people say, yeah, there’s this thing we’re going to do,
it’s going to be great, people are going to love it, and maybe 1 or 2
other people are even kind of scratching their heads and going, yeah, I
still don’t really get it, but you 2 or you 3 seem really driven by it
and I trust you, so go do it and maybe it’ll come clear later. It was
that way for me with the text box, spatial text. Stuff and Julia started
working on that. I really didn’t get it. I didn’t understand how it
was different from the little text cards we had currently, the early
versions didn’t work very well. It’s just Texas is really hard, and it
took me a while to fully download the vision, but once I saw it, I
realized it was awesome.
01:09:08 - Speaker 1: Yeah, for me, I think the combination of the
proposals that we write up every summit is also very helpful, not only
for the current summit, but for all future summits, because we very
often revisit that same idea over and over.
The past number of times, sync has obviously been at the top of the
list, so that’s what we focus on, but the spatial collections has been
in our thought process for a very long time, and so the team is ready
and motivated to work on it.
It’s just about finding the right time.
And Wiggins, another thing that you mentioned is we all work on support
and having That shared experience as a team, seeing the same support
tickets come in, the same requests from users, the same problems, really
helps us stay on the same page about what are the major things that our
users are asking for and running into, and that gives us a shared
priority for a number of issues that are on our to do list when we all
see the exact same urgency from the users, and that shared brain space
over the past months and years working together really helps that
consensus-driven approach.
We’re all playing the same ball game and we’re all on the same journey
together.
01:10:17 - Speaker 2: Yeah I’ll also note that even can create energy
in the short term. A good example from recently was, I think Julia did a
sport shift and I don’t know, again, there’s been such an unusually
large volume of support requests coming in post launch, or at least I
hope it’s unusually large. I don’t know if we can sustain this
forever, but Julia had seen just quite a number of people getting
confused when they navigated away from a board, came back and couldn’t
undo.
You know, if it’s deleted card, we have the restored deleted cards
thing, so there’s there’s some recovery from that, but she realized
that something that had been a technical blocker before, which is the
way that core data, the persistence system we were using before,
interacted with the Ndu manager made it really hard to Like an undue
stack per board.
Now that we have our own persistence layer written by you, she realized
that that was more feasible and just got motivated to just work on it
essentially one day, I think it was like when she was on the plane on
the way back from a trip or something like that. And so, you know, we
just ended up kind of doing that and QAing it and shipping it because
yeah, she was motivated by direct contact with customers, saw an
opportunity that before was more challenging or had more blockers in the
way and just went for it. So coming to a question about the lab, that is
the ink and Switch Research Lab, which many listeners will know is the
the place where Muse was born, Ruben asks, is MUS the product already
fully financially supporting Ik and Switch? So I found this question
fascinating. I’m going to give three answers here, short, medium, and
long. The short answer is no. The medium answer is, I probably should
explain the relationship between I Switch and Muse because I think not
everyone realizes it. So I and Switch is a research lab. Essentially a
not for profit kind of entity whose goal is to fund research work,
publish papers, and then at some point spin out things that are ready to
be commercialized and Muse was the first of those, but hopefully not the
last. So Muse is a separate company, a for-profit, C Corp, uh, but Inc
and Switch took an equity stake in Muse for their role in helping gate
it. So in that way you can see the relationship between Muse and it can
switch as being similar to the relationship between a YC company and Y
combinator. So really it’s not possible for any one. Spin out to make
an accelerator and I think it’s going to be the same thing for I and
Switch if the spin-out strategy works, there will be a portfolio of
these. Also, logically you can just look and see that you know I and
Switch is a bigger organization just headcount wise than you, so you
know it just logically wouldn’t make sense that the smaller
organization supports the bigger one. But I do love that this points to
an even longer answer, which indeed perhaps at some point we’ll have to
get Peter van Hardenberg back on the podcast to talk about how the lab
finances work, because it’s a very interesting and challenging question
and something they’re actively developing. But sort of there’s the
spin-out strategy, spin out companies that can earn money and then
potentially that goes back to and switch for more research. There’s
also some lab for hire work if there’s an area your your company needs
some the specific expertise of ink and Switch and you want to hire on
kind of a consulting basis, ideally something they can get a paper out
of that’s on the table. There’s other kinds of grants and things like
that as well as even potentially like public money and so on. So I think
like a lot of research organizations, it’s a matter of pulling together
revenue from a number of sources including just straight up patronage.
So I believe the automerge project is now generating a pretty good bit
of patronage through different sources and that also goes to fund
research work, but we very much hope that you can think of that the
portion of the proceeds when you buy Muse go to support more work from
Inc and Switch, and if that model proves itself to be viable both for
use. For the lab that there would be more examples of that in the
future, and it produces a nice flywheel of a lab that can do innovative
research, think about the future, not think about commercializing, but
when they do stumble over something that has good commercial potential,
they can take some of that while not distracting, you know, not
converting to a startup or something and distracting away from the
ultimate goal of always being looking to the future and just adding to
humanity’s total knowledge rather than commercializing any particular
piece of its findings. Well, maybe a good question to wrap things up on
comes from Ilia Wulf, who says, would be curious to hear what you want
Muse to be 2 years from now.
01:14:49 - Speaker 1: Very eager for not only muse, but the spatial
canvas thinking canvas category to continue to grow.
I think some of that I’m looking forward to is the file formats for
interoperability and better archive storage.
I’d really also love for Muse to be able to open source some of our
work, maybe with a sync engine or with some of the other things we’ve
done, because there’s the spatial thinking category, and there’s the
local first category, and then there’s the overlap of those two
categories, and I think out of all the interesting things Muse has
already done. It would be great to be able to support a lot of the other
products and companies and Pieces in this growing forest that we find
ourselves in.
01:15:37 - Speaker 2: Yeah, I found the question interesting because
they didn’t say muse the product or the app or the thinking tool. Muse,
of course, for us, has a lot of meanings. It refers to the product, of
course, but it’s also the company, team, and even the brand.
And so I I find myself thinking a bit about the company itself being an
example of a sustainable kind of small giant indie company, like some of
the role models we like to see, for example, Panic is a kind of indie
studio example or sketch, as kind of a bigger company that’s carved out
a really good niche for themselves in the design tool space.
And I think being in this middle ground between we’re not bootstrappers
or indie hackers, we’re a bigger team, we’re investing in more cutting
edge technology and design approaches, but at the same time we’re keep
staying really capital efficient, staying small, small team, lots of
trusts, everyone does a bit of everything, and that is a model I would
both like to see because it just reflects the kinds of workplaces I’d
like to be in, but I also wonder if it fits with maybe the way the
technology industry is changing that we might be a little bit.
Getting towards the end of a winner takes all rapid frontier growth and
into what’s sometimes called the deployment phase, and there is a lot
more room for a wide variety of tools and obscenity space.
And so, this style of company, again, there’s role models I look to and
maybe we can, if we do it right, maybe we can be an example for others
as well.
And I think the brand as well continuing to see that stand for more than
A multimedia canvas as good as it is and as many great features as it
has, and so on.
In the end, you know, I hope we stand for thoughtfulness and curiosity
and serenity and in a very noisy world where it seems that technology is
just always fighting against us with dark patterns and trying to like
get our engagement loops and dopamine loops going with notification. and
so forth and even beyond technology just I think a greater degree of
thoughtfulness in the world would just sort of benefit humanity that
everyone taking a little more time to slow down a bit and just think
about things that are important before they do them or before they
engage in the hot take or whatever, whatever it is. I think that’s,
that’s something I hope we could. Not just stand for with our team and
our company and our products and our podcast, but also maybe something
that in a small way we could influence the world for the better.
01:18:04 - Speaker 3: Yeah, there are likewise a lot of ways that I can
answer this question, but I might focus on the product side.
I had a very particular product vision from you going back, I don’t
know what it is, 3 or 4 years or something, and I feel like it’s
actually stayed pretty consistent.
It’s this idea of a personal information tool that takes advantage of
the unique form factors, is multimedia, is resonant with how the human
mind actually operates as high performance as local first. I thought
we’ve gotten about 50% of the way there, we have a very good line of
sight to most of the rest. And so I really want to see this thing exist
in the world. A, because I want it for myself and I think it’d be cool.
But also, it’s kind of this definite optimist take where I kind of feel
like if we don’t do it, it might not get done and that’d be very sad.
So I really want us to succeed in bringing this vision, which is now of
course, grown beyond just myself to the whole team, but see that brought
into the world and see it earn the success that I think it can get.
It’s a lot of work to do, so let’s get back to it.
01:19:05 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at NewAHQ by email,
hello at msApp.com. Wulf Mark, it’s been a great ride these last 3
years. I’m glad to hear we’re 50% of the way through. That’s actually
a pretty solid progress bar, so let’s keep pushing through to 100%
right on to the next 3 years.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: I think designing is just the process of picking
the best option that you have gone through, but you need to go through
that process. The more time that that process takes and the more
expensive that process is, the less you experiment and you just fall
back and you default to what we know. But that’s not where great ideas
often come from.
00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. And
today we’re joined by Dan Lacivita of Play. Hey guys. And Dan, in
addition to your duties as co-CEO of a startup, I understand you also
have a particular management challenge this summer.
00:00:53 - Speaker 1: Yes, I have two boys, 9 and 7. They just got out
of school. So we are thinking of outdoor physical labor activities for
them over the summer. The last one was actually cleaning the garage
floors, my son. was squeegeeing the water out and he’s like, Dad, this
is really satisfying. I was like, yeah, you know, you have to do the
other side of the garage too, and then it became immediately less
satisfying for him. Yeah, so, we’re coming up with a lot of ideas for
those activities.
00:01:21 - Speaker 2: For some reason, I’m reminded of a beloved 80s
movie on male mentorship, which is the Karate Kid, and the famous doing
chores as a way to learn to be a martial artist, so maybe there’s some
angle like that.
00:01:34 - Speaker 1: Yeah, life lessons through chores. I don’t know
if they’ll like that, but that’s the, you need to do this in order to
play video games, so that’s the model we’re going with.
00:01:43 - Speaker 2: And tell us about the journey that brought you to
play.
00:01:46 - Speaker 1: Yes, so 42 years old, father of two boys, prior to
play starting play with my other three co-founders, June, Michael, and
Eric.
We all worked together at an agency called Firstborn. It’s a design and
technology agency. We’re headquartered in New York City.
I actually started there in 2004 as a flash developer, for anyone who
remembers the good old Flash days. And when I left, I was CEO. June was
our chief creative officer, Michael was our founder, Eric was one of our
lead engineers.
And yeah, we were designing and building websites, mobile products, AR
experiences for our clients.
We actually sold the business to Dentsu about 10 years ago now and
through the process of creating all of those products for our clients,
especially mobile products, we’re just always thinking about the tools
that we were using, and this is when Sigma was very early days as an
agency, we just moved over to Sketch and, you know, my partner June was
just always talking about how we’re using the same input devices, you
know, for our design tools, but we’re using our phone as a creation
device in many other areas and so that kind of kernel of the idea led us
to leave Firstborn and then start play.
00:03:02 - Speaker 2: And I feel this is quite a unique angle. I guess
there are plenty of places where you use a phone to create content,
typing out a quick email or something like that, but something like a
design or especially an interactive prototype, you know, we think of
that as something where you really got to be at a desk, mouse, keyboard,
big screen, and doing that on the phone, which is really optimized to be
a consumption device. It’s unusual. How is that borne out so far in
your product to date?
00:03:29 - Speaker 1: I thought it was a crazy idea initially too, when
June initially talked to me about it, and I was like, how are we gonna
create a design tool on a phone with that real estate. And so the
interesting and probably there’s many aspects of the entrepreneurial
journey that are fun, but I think the early days of just watching the
team.
Create different UI patterns.
We landed on sort of this, I think, unique slider UI that allows you to
design on the phone while not having the interface getting in the way of
what you’re actually designing. So I think that was a really
interesting part of the process in the early days. And I think what’s
been more exciting and maybe a little unanticipated is As we started to
design a design tool for the phone on the phone, we realized, oh, we
have this whole sort of sandbox of things that Apple has created, all of
these native controls, native gestures that we can now tap into and then
layer our GUI on top of, if you will, and give designers the ability to
design with the real things, right? The real materials that engineers
will ultimately use to make the product that they’re designing. So,
it’s been A fun journey so far, you know, it’s unlike traditional
design tools that require you to context switch and stimulate the mobile
experience plays really the first tool to make contextual design for
mobile possible, so there’s no proxies or simulations or syncing to
mirror apps. You are sort of getting your hands into the clay
immediately and beginning to craft inside of the final medium that the
users will ultimately experience things on.
00:05:07 - Speaker 2: And that speaks to me for sure because I’ve
written about creative process as being largely about the feedback loop,
the iteration loop, how quickly can you try something and see the
results of the value of, for example, what you see is what you get
editing and word processors, direct manipulation.
I’ve written about this in developer tools where you very often have a
long compile run. Cycle and the closer you can get to instantly make a
change and see the results sort of the better, even though in many cases
that’s not fully practical and so in some senses you’re designing it
on the device and so there isn’t some switching, as you said, to some
other location. It’s all kind of right there in the same context.
00:05:49 - Speaker 1: Yeah, it was one of the things that June had
talked about early on, is like, you know, let’s say I’m designing
something for a client to review, it’s, you know, mobile app screens or
prototype for a mobile app. I have to get all those designs on my phone,
like through a mirror app, right? Or just save JPEGs. This is even
before mirror apps were, I mean, they’re still not really that great.
It’s like, but then I want to look at that when I’m not at the office.
Like, I want to look at that when I’m walking through the park, or
maybe we’re designing for a certain persona and they’re going to use
this app in a grocery store. Like, I should look at these designs when
I’m in the grocery store and I’m in that environment, and then I’m
going to see things that I want to change, but I can’t change them in
that moment. I have to like write it down or take a voice memo, wait
until I get back to the computer or back to the office the next day,
then make those changes. And then if I want to see those changes back in
that, you know, sort of environment, I have to go back to the grocery
stores like, I just want to make that change right there in that moment.
And then see how that feels, or maybe have a few different versions of
that and then see how that feels.
And so, I think for him and as we talked about it, there’s this unique
magical moment when you’re looking at something in your phone, like a
design that you’ve created, and then you’re like, oh, I wonder what
would it look like if this was changed, and then you could just change
it just directly on your phone and it’s kind of a very cool and
empowering moment.
00:07:07 - Speaker 3: That’s interesting to me because as an early
phone user, I was surprised by the extent to which the mobility and
ubiquity of the phone was an advantage. I think that’s kind of obvious
in retrospect, but for someone who grew up with a desktop computer, you
know, everything was there. You had a big screen, you had a keyboard, it
seemed great. Just being able to access a thing all the time turned out
to be amazing in ways that I didn’t anticipate. I hadn’t thought
previously to apply it to design. Again, I’m back at the square of, oh,
it’s design work, you gotta be at your desktop to do it, right? But not
so much.
00:07:34 - Speaker 2: You mentioned needing to come up with new kinds of
interactions because the phone doesn’t have a big command vocabulary or
established precedent for, well, I think sort of creation activities in
general, but certainly design work in the specific and in my brief
experiments with the app like one that certainly catches your eye right
away, maybe this is what you were referencing is you kind of see the
prototype filling most of the screen, but you swipe to the right, which
sort of spatially speaking drags in the left hand.
Side of layer list which will look very familiar to a sketch Photoshop
type person and indeed those are often on the left, but here they’re
just sort of off screen they’re sort of in the spatial metaphor of the
mobile world they’re sort of hovering off to the side until you slide
them in and then there’s another one on the right that you sort of pull
in that actually. It gives you adding horizontal and vertical stacks,
buttons, all that sort of thing, and then there’s sort of a properties
panel that slides up from below that lets you edit stuff.
So that certainly speaks to us where, you know, working on the iPad
trying to make a thinking tool we do end up having to like invent a lot
of stuff from whole cloth, which is a pretty big hassle or a lot of work
or takes a lot of time relative to working in the more known space, but
it’s basically a lot more fun as a designer and engineer and product
builder because you do have this open frontier that Now that all
possibilities are open.
00:08:53 - Speaker 1: Yeah, I agree. I think it’s certainly fun in the
creation process.
And then when you design those small magical moments, it’s fun for the
user too.
And I think even tools that exist for creating something or have a
purpose behind what I’m doing can also still have those moments of fun
or you know, sort of interesting interactions that smile, right? That
say, wow, that was actually a cool thing that I experienced and so. When
we were designing the slider, Eric, you know, our lead engineer and my
partner was like, oh, well, maybe we can just drag the slider vertically
as well. So like I’m actually moving the knob on the slider
horizontally, but if it’s in the way of something on the screen, I
could just move that entire slider up and down. And it was just those
little moments and as they compound, then the UI starts to come together
and actually becomes something far more functional and usable and
interesting to use for the user as well, I think.
00:09:51 - Speaker 2: So our topic today is designing with real
materials, and longtime listeners of Meta Muse will know this is
something we’ve we’ve touched on with past guests.
Andy from Not Boring Software has a great post called Honor the Material
where he talks about basically furniture and how you can design using
whatever the particular material is, whether it’s wood or molded
plastic or steel that you can use.
That in a way that fits the material and then in the digital realm
we’ve spoken with David from Webflow who talks about how Dreamweaver
and other kind of past visual website builders maybe one reason they
didn’t kind of quite ever seem to click is because they don’t respect
the underlying materials of the web, that’s HTML, CSS, the box model,
URLs, pages, links, etc. So, Dan, what does designing with real
materials mean to you?
00:10:44 - Speaker 1: So, designing with real materials is something
that I think early on for us, we realized was possible because we have
access to, as I mentioned before, this sandbox that Apple has created.
So even the most basic example of a button. I’m gonna design a button
in FigMA or sketch, and the buttons are gonna have different properties,
right, color properties, there’s probably text in there, maybe there’s
an icon, probably has some padding, maybe a corner radius that has all
these different properties.
And even when an engineer looks at that button in a FIMA file or a
sketch file or XD file, there’s actually a significant amount of code
that needs to be written just to get that button to look exactly the
same. When I’m writing it in X code, when I see it inside of a design,
and that’s just a button.
So then if you zoom out of that and think, well, OK, well then what do I
need to do for a card or a stack of cards or an entire page or a
multitude of pages that then have different states and interactions, it
becomes a lot. And so, we realized that Why would I design a button and
play when I could just use the native UI button, for example, that Apple
creates, which is how an engineer is probably going to build the actual
product. And this is the most basic example, right? So I could just add
a native button to my page, and when I’m designing that button and
play, I’m actually manipulating all of the properties that exist. In
that UI button that an engineer is going to either include or choose to
not include when they code it. So we’re doing a couple of things. One
is where Giving, I think, more power to designers to, instead of writing
a bunch of SWIFT UI code or UI code to, you know, create that button,
we’re surfacing all those same properties, but in a way where they can
design with them. And then when they communicate that, Perhaps with a
developer handoff or collaboration feature, that engineer isn’t just
looking at a vector-based rectangle on a page, they’re looking at the
same real materials that they’re actually gonna build with. And if you
further that, then you start to get into live maps or input text fields
or UI collection view or, you know, how stacks are used. And so what we
do is we say, well, what are all of the things that I’m gonna use to
build a real application. Let’s surface those up as real materials for
a designer to use when designing, instead of using replicas of those
materials.
00:13:17 - Speaker 2: And I’ll argue it flows both ways.
There you’re talking about the engineer has to do this effort to kind
of, you know, replicate what’s in the design mockup that comes out of
the more general purpose designing vector editor tool, but it actually
flows back the other way too, which is you see that.
There’s big libraries and components that are here’s your iOS system
components, here’s your Android system components, those need to be
updated every time a new version of the OS comes out where you’re
essentially simulating all of those things inside the design tool and
then you go back to the ultimate target.
Someone needs to build that button and then they need to kind of extract
from your vector drawing what parameters are going to go into that
button. So it seems like that could have the ability to short circuit a
lot of that back and forth.
00:14:02 - Speaker 1: Yeah, exactly. And I think our general purpose
design tools do a lot of things really well, but a lot of their strength
lies in that what I would call generality, right? Like I can use a tool
like FigMA or Sketch to design a website or an app or a wedding
invitation or a poster or a business card or anything, which is
incredible.
So I think in the context of designing products, they’re great for
designing.
A blueprint for the house, but they don’t really get us closer to
designing the actual house, cause they’re not using the real materials
that are gonna be used designing that end product.
So, I think the closer designers can get to that point, not only does it
make it better for engineers, but to your point, it educates the
designer, and I think it empowers them to design with those real
materials.
00:14:48 - Speaker 2: When we spoke earlier, you pointed out that the
sketches and figmas of the world are general purpose vector editors,
whereas what you’re building is a specific tool for mobile app design
and as you said, there’s many benefits to being general purpose, but
there’s also a lot of benefits to being purpose built for this specific
task at hand.
And funny enough, one of our recent guests was a fellow by the name of
Paolo who works at Sketch, and he actually made that exact point when I
was kind of teeing up what sketches or talking about the history and I
said, well, obviously it’s really focused around UI design, and he
actually stopped me and said, well, That’s true that it found some good
traction in that vertical, but actually it’s way more general purpose
than that.
It’s a general purpose vector editor, and he talked about that they
need to serve a huge number of use cases. Engineers use it to make flow
chart diagrams, salespeople use it to make stuff for their slide decks,
as well as yeah design many different kinds of design app icon design
and graphic design and mobile apps and websites and desktop apps and so
forth. So that’s interesting, which is it’s just not good or bad,
it’s just a difference and if you want to do something very specific,
then you’re making a thing that’s very suited to that specific task.
00:15:58 - Speaker 1: Yeah, I think one of the things we, when talking
with our users, product designers, UX designers is, I don’t think
people are really happy, generally speaking, with their UI design tool,
whether it be FigMA or Sketch.
And those tools are very powerful, I think very early on in the design
process, the design workflow, when I’m really just translating ideas in
my head down on paper or on the screen.
Then there is a moment when I want to make the thing that I’m designing
more real. It’s a higher fidelity of design, it’s a higher fidelity
prototype.
I like the direction it’s going, and then that’s when we see a lot of
people, they’re reaching for another tool. Could be origami, could be
protoy, usually to do higher fidelity prototyping.
But I think what’s interesting there is, so if you think about, I’m
spending all this time in a UI design tool. many, many, many weeks. And
then I’m reaching for a secondary tool, spending time in there. The
feedback loop between those two tools is very arduous as well, right?
Because then if I want to make changes, I have to go back to my design
tool and make changes, reimport to the prototyping tool. You don’t get
tight feedback loops, which is the whole point of prototyping. I think
there’s an inherent flaw there. But then at the end of all of that,
what do you hand to your engineering team? Like a figMA file and some
videos of a prototype. And it’s all reference points. It’s all just a
blueprint. There’s nothing that they can truly use. They’re starting
from scratch. And so we sort of look at it and we’re like, well, we
should like spend time in your UI tool, in your design tool. I think is
an incredible tool. Sketch, these are really powerful tools. But when
you reach that point in your workflow when you want to make your design
more real and reach a higher level of fidelity, That’s the moment where
there’s a benefit in thinking about how to design it with real
materials, right? And so, even your interactions, why not use a native
modal instead of simulating what a modal is gonna look like? Why not use
real haptics so you can feel what those haptics are gonna feel like. And
then there’s a lot of, I think, if you get to that point where you’re
doing higher fidelity prototyping, the input that you give a user, the
higher the fidelity and the better that is. Most likely the better your
feedback is going to be, again, when you’re at that higher fidelity
prototyping moment.
00:18:22 - Speaker 2: Yeah, I feel like transitions and motion design
are an area where mobile is in a whole new class, right? Desktop,
typically you’re lucky if you get even like a button animating to a
depressed position when you click it with the mouse for the most part,
you click on something, the thing just happens. Whereas mobile
introduced this whole world of very sophisticated high frame rate
transitions that illustrate something spatial or maybe even be a little
bit 3D or a fade or something like that.
Every design team I’ve ever worked with, and this includes Muse, you
know, you do the static mockups and then you have some text that
basically says, OK. This should probably transition by this kind of a
thing with an ease in curve and probably take about half a second and
then really it’s up to and on our team that’s Julia who loves this
kind of work and in a way she ends up being kind of our transition and
motion designer because she’s turning those static screens into the
actual interaction. So yeah, allowing the designer to do more of that in
their tool and thereby get again something that’s closer to the
finished thing and let the programmers be more focused on logic, I think
seems pretty logical.
00:19:30 - Speaker 1: And there’s some engineers that are really gifted
at motion design and transitions and interactivity. It’s designers that
have had an opportunity to work with those engineers. Usually get
something great from that collaboration because the designer has the
vision, and the engineer then takes it even a step further, but that’s
not every engineer. And even sometimes designers, I think, don’t know
exactly what that interaction’s gonna feel like until they make it and
until they feel it. And I think that’s the other piece in the design
process that we don’t talk about a lot is to what level of conviction
do I have as a designer, that the thing I’ve designed looks right and
feels right. Am I just relying on my experience or what I have seen to
be true in other apps? Maybe for simple things, that’s fine, but how do
we then get different interaction patterns? How do we surprise and
delight users with new things? We need to try it. And I think the closer
you can get a designer to trying new things and making them feel real in
their hands, instead of just trying to explain it to an engineer, they
have more conviction. They’re like, oh, not only have I designed it,
but they can hand, you know, a phone to an engineer and be like, what do
you think? Like, play with it. Like how does that feel? You think we can
make it better? And I think that’s one of the things we’re trying to
do with play is get designers to that point where they can have that
conviction. Of what they’ve designed, not just from a visual
standpoint, but from an interactive standpoint, feels and functions
well, marrying those two things. I think the whole thing of interaction
design, it’s visual design and interaction design together, those
things should be married together and not be separate from one another,
or be in a waterfall type of uh approach.
00:21:20 - Speaker 3: Yeah, another way to articulate that is that the
better your tooling is for rapid and cheap experimentation, the more
experiments are correct to do. So if it is in fact very expensive to
implement a working prototype, the correct decision is often to actually
waterfall it because it’d be too expensive to do it twice. But as it
gets infinitely cheap and infinitely quick to implement a prototype, the
correct decision becomes more and more just try it, which is great.
00:21:48 - Speaker 1: That’s a great point. It’s the cost of doing
something wrong and spending too much time doing the wrong thing. If you
can get to the wrong thing quicker, then you’re able to get to the
right solution at some point quicker as well. June talks a lot about
that. He’s like, I think designing is just the process of picking the
best option that you have gone through, but you need to go through that
process. The more time that that process takes, and the more expensive
that process is, the less you experiment, and you just fall back and you
default to what we know. But that’s not where great ideas, you know,
often come from.
00:22:24 - Speaker 2: Yeah, enumerating the options and then choosing
from among them based on your design constraints and tastes and things
like that, I think that gets pretty close to at least part of the core
of the design process. And one of my favorite Walt Disney quotes that he
would always tell his designers, who only brought him one proposal, was
he’d say, Well, it’s hard to choose between one. You know, your chance
to exercise your taste is really when you can look at several things,
ideally as many as possible, that kind of explore the space and then
really see which one is inspired or solves the problem in a unique way
or just feels right.
00:23:00 - Speaker 3: Yeah, Ricky has made similar statements about
design in the context of programming languages. He said something like,
if you’re looking at one option that’s not a design decision, right?
It also reminds me of this book called The Principles of Product
Development Flow, which I constantly go back to. And one of the insights
from that book is that building something like software, something
creative, is fundamentally about eliminating risk. If you eliminate all
of the risk in a project, by definition, you win. And so one way to look
at the creative process is how do you find and systematically eliminate
risk. And again, if it becomes cheap and quick to do that, you more
quickly and more certainly move towards winning.
00:23:37 - Speaker 1: That’s a great perspective.
00:23:39 - Speaker 2: Mark, what does designing with real materials mean
for you?
00:23:44 - Speaker 3: Well, it’s interesting when you wrote that up in
our notion doc, I had one thing in mind, but I think we’re actually
talking about something else.
So I had in mind the idea of doing a design with an eye towards
eventually building it using a quote unquote real material. So for
example, designing a piece of furniture to eventually build the
production version out of solid hardwood instead of particle board, for
example.
But there’s also the notion of designing with real materials as doing
the design of the chair with an actual hardwood prototype versus doing
it with a particle board prototype, which might be cheaper, but it has
less fidelity to the eventual production version. I think they’re both
interesting, by the way, and you can imagine the same thing in software
with taking the example of the button. If you’re eventually going to
ship a native iOS button widget, you might want to do your design with a
native iOS button implementation. There’s also separately, the choice
of you can ship in your production version a native iOS button or like a
transliterated HTML version that mostly looks the same, but actually the
the covers isn’t exactly the same. I think those are both interesting
discussions. But since the thing that Adam, you originally meant to talk
about is more the Designing and prototyping with the actual thing that
you’re eventually going to be shipping, in this case, the real iOS
button. I would point out that I think that goes both ways, in the sense
that you could choose to extend your prototyping technology to get
closer and closer to production software. You could also pull in your
production software and make it easier to iterate with, and people do
mixes of both, of course.
00:25:12 - Speaker 2: Yeah, well, maybe another thing I had in mind was
going back to Andy’s article on honoring the material.
There it’s less about in the process of figuring out what the end
product is going to be. You’re making a chair, you’re doing a sketch,
you’re maybe using some software to lay it out. It’s less about are
you designing with the same material and more understanding the material
that you want to make it for.
And so perhaps this is, well, I guess that’s in the word honor or
respect, but I think it’s maybe authentic is another word that comes to
mind a little bit, which is thinking in terms of I’m going to make,
coming back to the web flow example, I’m making a web page, so it
should use the qualities of the web in a particular way. I shouldn’t
try to obscure that I’m making a web page and try to give someone a
thing that feels like Photoshop because that’s wrong. I’m going to
make a thing that feels like a static image that doesn’t feel like the
web. And perhaps there’s a similar comparison to me made for mobile app
design. If I’m doing that for a mobile app, I’m mocking up all of the
elements in a vector editor, I’m just may not be fully really
understanding and respecting what the material can do.
00:26:22 - Speaker 3: Yeah, I think that makes sense. So you might say
designing with the real material in mind and honoring that. I do think
there’s two subtle variations of this though. There’s one variation
which is, OK, I think honoring the material is a good word for this.
This is where you deeply understand the traditional and ingrained use of
the material. It’s almost like a moral argument of this is the way the
web is, respect the web, this is the way it should be.
And then there’s also the Saying, OK, design is how it works. So you,
as a part of that, you need to understand deeply the materials that
you’re working with as part of the design and fully understand all the
parameters and possibilities. And given that you’re gonna come up with
certain approaches and designs. Now, typically, these circles are gonna
almost perfectly overlap, but it’s not necessarily the case that they
do. I think FIMA is a good example of Figma does embrace some elements
of the traditional web. You can go to a URL and you can load the page,
but the way the app is actually implemented is completely different.
It’s like this wild C++ to WebGL, you know, graphics pipeline, because
there they said, OK, here are the properties of the web. We read the
fine print. You can do this thing where you transile C++ or JavaScript
or whatever, and you can combine that with the traditional, you know, on
the material sense of the web should have URLs you can go to, and we’ve
produced this great result. So I think there are two interesting and
different meanings of that.
00:27:32 - Speaker 1: It’s something we talk about internally as a team
is how much time do you spend on different parts of the creative
process. So, if I was Going to sculpt something out of clay.
Maybe I have an idea. And maybe I sketched that idea, so I’m doing a 2D
sketch of this three dimensional object.
And I think that there’s value in that because I’m visualizing my
initial idea, but if I spend too long sketching my sculpture, In 2D in
an entirely different medium. I’m not getting to that real formation as
early as I want to, versus somebody that gets their hands in the clay
sooner rather than later is going to find new things that they wanted to
sculpt.
It’s probably not going to look the same as that 2D sketch. And it’s,
I think a question of where do I invest my time and how much of that
time do I invest at different parts of the creative process.
And I think right now, our tooling. Does a really good job at that, get
an idea from my head down to a sketch on a piece of paper or a vector in
a browser.
It does it really well.
But then there’s that moment where I want to make it more real. And
what’s interesting in hearing you guys talk about the real materials
from your perspectives as well is There’s value in honoring those real
materials, so the button, like we talked about. But then there’s also a
moment where I think the working with real materials unlocks potential
that you previously didn’t have.
So, how do I create an interactive map with pins that are connected to a
carousel of cards in a vector editing tool? I can’t really do that.
Maybe somebody can create some crazy hacky thing, you know, prototype
inigma sketch, but I can’t do that.
I certainly can’t do that in a native way. Or haptics, or a picker.
Like how many times do we use a picker in an app, a little dial, right
at the bottom of our screen. I can’t make that for real in a vector
editing tool. But in a tool like ours, I just tap picker and then it
appears on my page, and then I just get to use it, like the real thing.
So there’s the moment where real materials unlock this. Potential that
I previously didn’t have, not using those real materials, because I had
to create ways around using those real materials.
00:30:07 - Speaker 2: Another real world metaphor that comes to mind.
I’m reading a biography right now of a fellow named Ken Adam, who was a
very talented production designer, so I think in film, this is the
person whose job is to basically come up with the sets and a lot of the
objects and things that are on screen that are not the actors, and
probably his most famous work was Doctor Strangelove, which has these
really dramatic war rooms and things like that.
But he’s a brilliant artist. He does these amazing sketches of these
scenes, but he makes the point in the book it’s kind of this interview
format. He makes the point that the sketches are not the finished thing.
No one’s going to see them except some years later if someone happens
to be interested and wants to read about it in a book. The sketches just
get you to the end thing.
So he really liked to get to working with in this case, the carpenters
as soon as possible, and for him, a lot of that was about not just the
way the space will feel, but also the way the materials.
Will look so the way that the light will reflect off the metal and by
the way this is film and this is film in the 1960s or whatever they’re
trying to do things cheaply, you know, they’re doing a period piece.
There’s supposed to be a big marble column or a big metal banister. You
can’t actually do that with real marble or real metal, so you’ve got
to use some various tricks of the trade to kind of do a faux version of
that, but what’s that actually going to look and feel like in practice?
So on one hand, yeah, he’s a huge fan of sketching and obviously from
the muse perspective we like that early ideation. Don’t go and try to
build a set before you’ve figured out what the concept is and what
you’re trying to convey and what the feel it will evoke will be, but
also you could spend too long on that ideation. It’s a safe place. You
can make your beautiful pictures and in the end, once you get your hands
on the clay, and the sculpture metaphor, get your hands on the whatever
the painted wood you’re using for your set, then you start to discover
the fine details that will really make or break the end result of your
artistic endeavor.
00:32:01 - Speaker 3: I feel like a lot of things we’re talking about
here are circling around our overall model of gradual enhancement and
the creative process.
So we’ve talked about how the creative process fundamentally has this
flow, just to simplify a little bit. Say you go from an idea to a sketch
to a prototype to a finished product.
Now, it’s important to Progress along that appropriately. Otherwise
you’ll make decisions and choices that are inappropriate for where you
are. So obviously if you jump right to implementation and production
without knowing what you’re actually doing, that’s a bad idea.
And conversely, if you stay around protyping forever without ever
confronting the reality of the actual production material, that’s also
a bad decision.
And there’s a theory about how you should do that whole progression
that we can talk about if you want.
But kind of bringing it back to tools. I see a few issues that we
typically have with tools to facilitate this process.
One is that there are sometimes outright gaps. So for example, we
thought that there was a gap, at least in the digital realm with the
thinking and sketching piece, which is where we introduced Muse to be a
tool for that spot. There can also be a problem with the gaps or the
extent of the gaps. So you might, for example, to use the example we’re
talking about before with buttons, if there’s a huge gap to go from
your protyping tool to your production tool, that introduces a bunch of
costs. And by the way, you’re at least going to do one jump from the
direction from prototyping to production, but you may well want to go
back and forth many times, and that has implications which we can also
talk about.
00:33:30 - Speaker 2: One thing I’d like to get your take on Dan, is
how you think about the mediums or devices of the phone, tablet, and
desktop. This is something we’ve spoken about and written about
somewhat extensively and wanting to design fairly differently, for
example, between tablet and desktop as we did with the news for Mac
versus new for tablet, even though in some ways those are closer than,
say, phone and desktop. How does your team think of those and
particularly why you want to start with the phone?
00:33:59 - Speaker 1: Yeah, so starting with the phone. We decided to
start with the phone, primarily because it was the medium that you were
designing for.
So let’s use the same medium we’re designing for as the primary input
device. And the other reason was, we realized that it was the most
challenging medium to design for if you were going to create a design
tool. So let’s start with the hardest, and then extrapolate out from
their UI to other platforms.
So, we always believed that play would be a multi-platform product. One
of the early pieces of feedback from users was, hey, can I have this on
tablet? And we had always thought that we would create an iPad version
to design iPad apps, right? Again, using the medium for its intention.
00:34:46 - Speaker 2: Yeah, that’s the thing that comes to mind
immediately is that you want to make a phone app, you use the phone, you
want to make a tablet app, you use a tablet, you want to make a desktop
app, use a desktop.
00:34:54 - Speaker 1: Yeah, and that was in our first medium article,
our launch article, we actually said that we’re going to release an
iPad app to design iPod apps.
00:35:03 - Speaker 2: I’ll link that in the show notes for historical
interest.
00:35:06 - Speaker 1: And then we got feedback from users saying, can I
have this on an iPad? Like, I want to be able to design iOS apps, but I
want to be able to do it on my tablet. It would be nice to have a little
bit more real estate, so I can work for longer periods of time. And I
think in our early testing, we realized this too, but there is a
cognitive load when you’re doing certain design tasks that coupled with
working on the device exclusively, gets to a moment where you fatigue
sooner.
So we realized, OK, well, maybe we should accelerate our multi-platform
vision quicker.
So we released the iPad app a few months ago, and what was interesting
there is a lot of users were using it with their keyboard and mouse and
Apple pencil. So the vast majority of people using peripherals, which
wasn’t too surprising, but the percentage of them was surprising to us.
And at the same time we had launched Play Web, so browser based. It’s
really more of an admin tool and asset panel, so I can easily drag
photos, images, SVGs, custom fonts, again, doing these things that are
going to be way more challenging on the phone.
Let’s use each medium for what they may be best at. And I think as
we’ve gotten feedback from users, there’s certainly A role for the
desktop in the design process. I think the unique opportunity we have
now is because we have a design tool on the phone and on a tablet. Well,
what does that then look like on a desktop? Because now we don’t need
to create a traditional desktop tool. We can create something that
marries and complements the other platforms in a way that is more
meaningful. And I think more innovative.
So that’s a space that we’re actively pursuing right now, that’s
pretty exciting.
00:37:12 - Speaker 2: Use each platform for its strengths is absolutely
singing our tunes, so I’m glad to hear you say that.
I also wonder too, I think your product caught my attention partially
because there’s something really provocative about design on your
phone, you know, it kind of has a little bit of this counterintuitive
head explode emoji like what? No, like phones, you know, for
consumption, you’re trying to picture the precision that you need for,
you know, moving a thing, 3 pixels to the left or whatever that you
associate with design tasks.
And so it’s sort of attention grabbing, but in the meantime you’re
also just building a modern specialized just well made design tool, and
I wonder, I guess I’m thinking of this because of your users and
customers who are on a tablet with maybe a trackpad and a keyboard and a
stylus, even if they’re designing for the phone, that indeed maybe they
just like a lot of the things about the tool and the core concept of
designing on the exact same device that’s sort of your target.
It is very interesting and provocative, but at the same time you can
take some of the things that are just good about the tool and generalize
them in this way.
00:38:18 - Speaker 1: Yeah, it creates an opportunity for people to
harness the unique features or capabilities, I would say, of the product
on iOS, but on a different medium.
And whereas the output would be the same, you’re designing a mobile
product, how you do that on different mediums may be slightly tailored
to that medium. And I think that’s been a really fun pursuit for the
team, because how do I Carry enough of the UI from medium to medium, so
it’s familiar, but adapt it in a way that also respects that medium,
right? We have fundamentals of how we use right click context menus and
things like this and hot keys for keyboard shortcuts. We would be silly
not to incorporate those into a desktop product, right? So, how do we
think about those things in conjunction with how a user would design on
the phone and make it a cohesive experience across all mediums, but also
unique enough where we’re taking advantage of Innate behaviors that
have been ingrained in our activities and how we’re working for so
long.
00:39:31 - Speaker 2: One thing I think we briefly mentioned earlier is
developer handoff, code export, that sort of thing.
And as I think about the full creative process and going from kind of
medium to medium for what’s appropriate for the stage, so you start
with that could be a literal envelope sketch, you know, in my case, I
would start in muse and I would gather user research and screen scouts
to the current product and sketch some new ideas and what are the
problems to solve. And once I roughly know what I’m doing, then maybe I
go from there to the vector editor. And then maybe you go from there to,
OK, now I really have a pretty concrete idea of the flow and the
solution, but now we need to get in there with the real materials and
design all the interactions and how does the spatial model work and feel
and let me quickly do user tests and essentially iterate on it right on
the spot where something doesn’t feel right and I can just grab the
phone. Back and make a couple of changes in play. So there’s a nice
progression there of increasing fidelity, but I know in that kind of
little vignette in that little story that I’ve just told, it’s sort of
all one person up until the point where they’re doing the prototyping
and play and then Usually, not always, but usually at that point you’re
not only changing between tools, but you’re actually changing between
people, so there’s sort of a knowledge transfer, what was the intention
here? What kind of role do you expect to play in that part of the
process?
00:40:53 - Speaker 1: Yes, so it’s something we’ve thought about from
the onset and I’m air quoting now, but developer handoff has been
something that so many teams and companies have tried to solve. It’s a
very challenging space for, I think all the reasons we all know to be
true.
Engineers work in different ways, existing code basis for products that
already exist, incorporating code that’s generated from a tool, maybe
challenging to incorporate. Quite honestly, a lot of the code generated
from tools is just garbage, and engineers don’t want to use it. So,
we’ve thought about it in a way where we wanted to start with the
basics and also talk to engineers about what would be valuable. And
there’s a lot of opinions is one thing that we’re realizing, but We
want to get to a place where it’s usable for both the designer and the
engineer.
What I mean by that is, I don’t think all designers want to be educated
as to how their designs are going to be written in code. I just don’t
think all designers care about that, and that’s OK. The force feed that
is not gonna be something that they’re gonna value in a tool. But maybe
we could Give them the option to view what the code would look like for
the thing that they’re designing in real time, and as they make changes
to their design, maybe those properties are changing in the code. So
they see that as I make changes in my design, it’s obviously gonna have
an effect on the code that my engineer is going to have to create.
I think the pursuit of this for us has been something where We want to
get to a point where an engineer, or anybody, quite honestly, could take
code generated by play platform, put it into X code, and render the
exact same thing that I’ve designed in play.
It needs to be 1 to 1. So what would the use of this be? Well, one of
the things we hear from engineers that we’ve talked with, for those
engineers listening, I would love feedback on this as well. Is the
moment when an engineer, they have to look at a FIMA file or a sketch
file. And then just lay out views. I have to take everything visual that
I’m looking at, and I have to start writing code to just make that same
visual thing in code. And that’s an arduous process. It’s not that
much fun for engineers to do, especially the more senior they are. So if
we could take that pain point away from them, it would give them, quite
honestly, the thing that is most valuable, which is time.
If we could say to a designer, by the way, with certainty, what you’ve
designed here in play is going to look exactly the same as what your
engineer is gonna code because we’re going to give them that code, then
there’s value for the designer. And it, again, gives them both back
this thing that is very important, which is time because there’s less
back and forth. Oh, I didn’t mean 16 point pad. Oh no, the corner
radius wasn’t supposed to be this, it was the. There’s no confusion
because at the end of the day, they’re just gonna have a straight line
into what I’ve designed, and it’s gonna render the same thing in X
code. So, This is some of the work we’ve been doing on the developer
collaboration feature, as we’re calling it, because this really
shouldn’t be a handoff. And I think that’s the other thing I can note
quickly is how often does a designer design something and hand it to an
engineer and then never touch it again. Never. So it’s really more how
can we create a feedback loop of collaboration. What if there are ways
where as I’m designing something, my engineer is beginning to develop
it, and then I want to change spacing properties? Do I need to slack
that to my engineer? Oh, by the way, like the 16 point gap is now a 20
point gap, or could I just make that modification in the design and my
engineer knows that through maybe an endpoint that we allow them to hit,
and then those properties are just updated for them. So I think there’s
a lot of work that can be done in this space. When we answer the
question, what value can we deliver to a designer and what value can we
deliver to an engineer? And I think a lot of it is about giving them
their time back to focus on other tasks.
00:45:14 - Speaker 3: This idea of a designer and engineer collaborating
is really interesting. It reminds me of a bit of a pattern we developed
in the lab and have used Muse to facilitate this collaboration.
So say a designer comes up with a design and there are certain
architectural elements that they believe are basically set, and then
there are parameters that they want to experiment with. Now, the
classical way to do this is you eject the code from the design tool and
then the designer looks at the real app and they say, oh, the font’s
too small. Slack the developer, please make it bigger. And then you’re
recompiling everything, and half a day later the build shows up. A cool
pattern that we’ve used is identify the key parameters and put those
parameters as configurable sliders in the code. And so that the designer
can show me the debug panel, slide these things around, see them happen
in real time, and then once everyone feels good about it, and nail those
values into the code base where they’re more solid, but also harder to
change. Sounds like a different way to implement the same. Logical flow
that you’re suggesting for this collaboration.
00:46:16 - Speaker 1: Yeah, exactly.
00:46:18 - Speaker 2: Now how do you picture it working in the sense of
does the engineer have a copy of play? And kind of the play, I’m not
even sure what you call the app prototype document loaded up and then
they can take those steps to export as this a place where the web
version, I’m thinking of, you know, early kind of hand off tools,
Zeppelin, I think was one that had pretty good traction for a while, and
they don’t need to know or care about the design tool the designer is
using potentially they just get this webpage that has a bunch of assets
they can download and kind of screenshots and maybe even some copy
pasteable code.
Increasingly nowadays I tend to see more either people engineers have a
copy of sketch so they can load up the sketch file or they just click on
the FIMA thing and they can kind of go through there, and in that sense
they’re not in some kind of separate handoff mode, they just are
getting different things from being in the same tool. How do you picture
it working for play?
00:47:12 - Speaker 1: Yeah, I think this would be certainly an area
where the desktop seems like an appropriate medium for this type of
workflow for an engineer. So I think that’s probably the medium where
this lives.
00:47:25 - Speaker 2: So then you can only use play for desktop in
engineering mode if you have a sufficiently loud mechanical keyboard.
That’s the right medium for programming.
00:47:33 - Speaker 1: Exactly, exactly. That’ll be the criteria that
you that you need to fulfill in order to get a seat.
So it’s interesting, one of our engineers on our team, accidentally or
whatever was updated to an editor role in FIMA. We use FIMA, you know,
for a lot of the design work that we’re doing as well. And he was like,
this is too much. Like, can you downgrade me? Because I don’t need all
this stuff. I just, like, go back to my other view. It’s sort of an
interesting moment and we were like, well, why? Like, what was
overwhelming about this? And I was like, wow, there’s just all this
thing that I don’t need, I don’t need to see all this, I just need
what I need.
So I think for us as we’re designing this is, maybe an engineer would
want this code that we’re able to generate, or maybe they just wanna
have a High functioning inspector tool as well that gives them the
opportunity to click on different components, be able to see the
different states of those components, be able to see the different
properties that have changed in those states, and then maybe if there
are interactions, let them know what the interaction is. Oh, it’s a pan
gesture. Here are some of the key parameters.
And in some of the engineers that we’ve talked with, that’s actually
very helpful, versus here’s a few 100 or more lines of code to create
this entire interaction that I’ve created. It’s like, well, no, just
give me the different states, the properties that have changed, what
type of gesture you’re using, what type of easing there is, and that’s
actually really helpful for me. So, I think it looks very similar to
what a designer would view, but as an engineer clicks on different
objects on the page, we will probably serve up information that’s more
relevant to them in a way that is not impaired by other panels, let’s
say that a designer may need.
00:49:31 - Speaker 2: So we can see that you can already make pretty
powerful interactions in play, and I noticed also as I was poking around
the interface there’s a panel where you can create variables, global
variables, and that pretty quickly leads my mind to think about, OK, so
there’s state, and once there’s state, now you’re talking about a
pretty sophisticated program. And so that makes me wonder how you think
of yourself as being similar to in competition with or in a different
part of the stack than no code or low code builders. You mentioned
origami earlier as one example, or even these full fledged outbuilders.
How do you see yourself in relation to those?
00:50:09 - Speaker 1: When we started play, the vision was to create the
first design tool that was purpose-built for mobile product designers.
And that’s still the vision that we are fulfilling today.
A lot of users have asked us, I’d be amazing if I could just submit
what I made to the app store, something similar to an Adalo or Glide or
these app builders, whether they’re native apps or whether, you know,
they’re cross-platform applications.
I think for us, the vision is something where we want to build a
professional grade design tool in a market where I think product
designers are underserved at a moment in their workflow that’s really
important.
However, because of how we’re building this tool, it isn’t impossible
for us to go the route of a more quote unquote app builder approach.
The web flow for apps, for example. It’s just a slightly different
market and a different business to build. And I think that’s the fun
part of the journey is We are building towards our vision. We have
traction with users. We haven’t even launched much of the product
ecosystem that we have road mapped, and we’re working to fulfill that
vision.
But there is an interesting Opportunity could be a secondary business.
It could be a separate business of using the technology that we’ve
created to then build an app a builder.
Of course, it then requires We’re back in integration, commerce, etc.
But it’s not something that we’re setting out to build right now, so I
wouldn’t call play an app builder because there isn’t a published to
App Store button. But the closer that we get to, again, as we’re
designing with real materials and as we are creating things that can
generate usable code. There is an opportunity for that path to be
pursued at some point in the future, should that be one that we want to
go down.
00:52:11 - Speaker 3: Yeah, I think you can also think of app builders
in terms of the ease with which one progresses down the development
continuum versus the eventual limit on one’s ability in terms of the
complexity of the app.
So the base case would be, you open up your plain text editor and you
type out the apps from the very beginning of the prototyping all the way
to the end.
Therefore, you can definitionally do anything you want that could be
accomplished in the programming language at least, but it’s gonna be
very expensive to do the initial prototyping.
Uh, and then you could use a tool that facilitates the initial
prototyping, but Jeff’s code. And then you still have the full runway
towards the eventual fully complex app.
When I think of app builders, I tend to think of tools to make a
trade-off of making it even easier to do the prototyping and limited
capability phases by walling off the future of eventual fully
sophisticated, fully general apps.
And in some cases, that’s the right tradeoffs to make if you have a
very basic use case, but a lot of reasonably want the option of the full
power of the programming language eventually and And for that reason,
they tend not to choose those tools in those cases.
You can think of it as a sort of technology problem in the sense of a
technology frontier from economics where given a level of technology,
which is your tools, you face a certain trade-off frontier, but perhaps
with improved tooling and techniques, you can bring that frontier in so
you have less of a fundamental trade-off. It can be arbitrarily easy to
develop an arbitrarily complex product. That’s the dream. But for now
in our world with our limited technology, we have to make a bit of a
trade-off there.
00:53:33 - Speaker 2: And I would agree that it isn’t that something is
better or worse because it is an app builder with a limited ceiling but
easier to get started, maybe can be done by a kind of non-programmer all
the way through FileMaker Pro is one of my favorite examples for kind of
clunky and old school as it is.
It really has enabled a lot of businesses to build custom software built
by domain experts that they just wouldn’t be able to get or afford
otherwise, or Hypercard is obviously a kind of one that almost has a
Mythical quality to it now and you know was used to make things like
games and simple content presentation but you couldn’t do sophisticated
logic and I actually almost wonder in the mobile app domain, I think
setting aside games, I feel like websites you mentioned the web flow
example, there there is a big class of websites which are really just
content. And there’s certainly logic in making sure you know it’s
responsive on different screen sizes and so on, but for the most part it
really is just content.
So once you’ve done the design and copywriting, you’ve essentially
done all of it, which is very different from a web app which has
sophisticated logic and state and all that sort of thing, and I feel
like mobile apps. are more often something that has more sophisticated
logic and state, and so therefore, a team with dedicated designer and or
a motion designer and a dedicated engineer or engineers is more likely
to be needed.
So they’re just different domains without kind of different end states.
00:55:01 - Speaker 1: You see some of the other tools that are app
builders, the capability of the tool is such that you generate a fairly
straightforward app, and it begs the question, does this need to be an
app, or could this just be a mobile website? And a lot of what we’ve
talked about in the past is If we went this route, we wouldn’t
necessarily change things dramatically from a technical perspective, but
we would need to simplify the interface, almost hide more things for
users, and then almost have a expert mode or an advanced mode where we
would then give the user the opportunity to uncover more of these
properties if they were inclined to update them, but If they were a
novice, they can build something really sophisticated and great looking
without having to tap into those properties.
So I think, Mark, to your point before, I think those are some of the
trade-offs, like it would need to be easy enough for a novice in order
to make the thing they wanted to make, but have the advanced
capabilities of somebody that wanted them if they wanted those things
exposed. And that’s the balancing act, I think, of a tool like that.
00:56:16 - Speaker 2: which I think does come back to the gradual
enhancement concept you mentioned earlier, bitmark, which is we’ve
given the example in the past of LiveJournal and and Friendster, and so
on, where you had these things where you would make this very, you know,
basically fill out a form, build a profile, but then eventually you can
unlock the secret code where you can type in a little bit of CSS into a
box, and then from there, you know, there’s the deep rabbit hole of
going into full web development. It’s pretty infrequent that things are
set up that way in computing, but I think it’s a very laudable thing
when you can have that low floor but high ceiling.
00:56:52 - Speaker 3: Yeah, not only that, but minimal discontinuous
jumps.
With gradual enhancement, we use the example of, you start with a blank
page, you write something out by hand, and you eventually want to end up
with a typed document.
Often that requires Two or 3 steps, you know, you write it out by hand
and then you type it up in your brainstorming app and then you type it
up again in your word processor. It would be amazing if you could
actually smoothly evolve that in one document. Similar to how we’re
talking about smoothly evolving the design in a way that kind of
preserves the underlying code. Now, it’s a very hard engineering
problem to get all that into one app. That is the dream, and I think
it’s important to keep that ideal in mind and not blindly settle for
constant discontinuous jumps in our tooling that jolt our creative
process.
00:57:36 - Speaker 2: So you’ve had play in a waitless private beta
state for quite some time, and I think that’s a really good way to
quietly iterate on something we did the same from use in the early days.
What can we expect in terms of a general release or whatever is next for
the product?
00:57:53 - Speaker 1: Yes, so plays available for iOS and iPad on the
App Store. Anyone could install it now.
There’s still, as you mentioned, an access gate route of beta in the
beta sense. I think we’ve got a really stable product right now and
we’re letting more users in, but we will be lifting that access gate
relatively soon.
So we’re excited about that and it will be open for all to use.
It will be a free tier for everybody to use as well, which we’re
excited about and Well, I can’t speak too specifically about some of
the bigger things we’re working on.
We have be more features for iOS and iPad over the coming months this
year. We’re excited about the charts and graphs for SWIFTUI and iOS 16,
so when that comes out, we’ll be releasing some updates there and then
some larger platform additions and work that will be rolling out in beta
later this year.
00:58:53 - Speaker 2: We’re excited to see it, and certainly as a
creator, it’s always a little bit, even if you’ve tested really
thoroughly with lots of beta testers kind of a little bit behind closed
doors, I think that there is always this act of vulnerability to come
out into the world and kind of lift the curtain and say ta da, hope you
like it. And of course, you get a huge variety of reactions from folks
on the internet, but it can also be a very powerful moment and uniting
for the team as well to feel proud about what you’ve put out into the
world.
Yeah, great, we’re excited. Well, let’s wrap it there. Thanks everyone
for listening. If you have feedback, write us on Twitter at museAppHQ by
email, hello at museapp.com. And Dan, I’m so glad that you’re pushing
forward design tools in this interesting and provocative new way. Can’t
wait to see what comes out of play next.
00:59:43 - Speaker 1: Thanks guys. I appreciate you having me.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: On the academic side, you’re very limited by your
work has to fit in the box of like a peer reviewed quantifiable research
paper and in the commercial world, it needs to be commercializable in
the next, you know, probably a year or two, maybe, maybe 3, but all the
good ideas don’t fit in one of those two boxes.
00:00:27 - Speaker 2: Hello and welcome to Meta Muse. We use the
software for your iPad that helps you with ideation and problem solving.
But this podcast isn’t about Muse the product, it’s about Muse the
company, the small team behind it. I’m Adam Wiggins. I’m here today
with my colleague, Mark McGranaghan. Mark, you reading anything good
lately?
00:00:43 - Speaker 1: Yeah, just last night, I actually reread an ultra
classic, you and your Research by Hamming, who’s a famous scientist,
and it’s about how you build a really impactful research program over
the course of your career, and I was inspired to reread it because it’s
one of the chapters in the classic book, The Art and Science of Doing
Engineering, which is about to be republished by Stripe Press.
00:01:05 - Speaker 2: Stripe Press is really on a tear these days.
00:01:09 - Speaker 1: Yeah, for sure, highly recommended.
00:01:10 - Speaker 2: And also perhaps relevant to our topic today, and
I’m happy to say that our topic today was requested by a listener. So
Fetta Sanchez wrote in to ask us, how do you get into the HCI slash
interaction slash new gestures research field. So probably we need to
start at the top there. Maybe you want to tell us what HCI is.
00:01:32 - Speaker 1: Sure, so HCI stands for human-computer
interaction, and this is things like the way humans interface with
computers, and also the way they use computers as a tool in their lives,
how they get things done, how they learn. To use them, how they
accomplish their goals, things like that.
00:01:48 - Speaker 2: And I did a couple of years of a computer science
undergraduate degree that I did not finish. And during that time, I
really remember everything in the curriculum was algorithms, databases,
compilers, maybe some network type of things. And I only learned about
HCI as a field a couple of years ago. And to me it was a bit of a
revelation because this concept of How the user interacts with the
computer and that being a whole field of study. Well, I was very excited
about, but stood for me in very stark contrast to the System the
algorithms oriented computer science that I sort of knew from my brief
time in academia.
00:02:29 - Speaker 1: Yeah, likewise, it was pretty new to me, and it’s
a whole huge world, you know, there’s conferences and papers and many
professors who’ve dedicated their entire careers to it.
00:02:37 - Speaker 2: It was fun for me to dive in and learn about that
world a little bit, and you and I were both part of this independent
research lab called Inot Switch. Uh, and through that process, we began
publishing and then made some connections with folks in this field, and
then you and I went to a conference called Kai last year that I think
really kind of opened the door for us there.
Maybe one thing that would be worth doing is um categorizing here a
little bit.
There’s Human-computer interaction as a branch of computer science in
the academic tradition, that is say mostly done in universities, sort of
the the pure sciences.
Then there’s corporate R&D which is more associated with for profit
businesses, but actually it’s where a lot of the HCI innovations that
are maybe the most famous, uh, we think of places like Bell Labs or
Xerox PARC, maybe today, Microsoft Research.
And then there’s a small but growing space of called them independent
computer science labs, independent HCI researchers, of which I think we
we had some contact with. How would you define the difference between
those three categories?
00:03:39 - Speaker 1: Yeah, well, like you said, the academic side is
grounded in these research universities, and this is often directed by a
professor or graduate students, and there the values are really around
evidence, rigor, review, publication and communication, and creating
knowledge over time, which is a whole thing we should talk about. And
then on the industrial side, it’s often more integrative because you
need to consider. Not only the the pure HTI elements, but the business
elements and the hardware constraints and the how easy the thing is to
learn for the user and practice and things like that. And then on the
indie side, this is a smaller domain, but that’s tends to be more
experimental, free form. People can bring their own wild ideas to it and
just try stuff. So it’s a nice injector of new ideas.
00:04:22 - Speaker 2: One way we can maybe make this concrete is to
describe the path from let’s say the lab to commercial product.
And I’ve I’ve struggled to find full stories on this in many cases, I
think this is something that happens behind closed doors a little bit,
even though science does have open publishing, the exact story of how
something went from basic research or early um HCI research to a product
that’s in the hands of end users is not well understood or well or
written down anywhere.
Um, I think the Xerox PARC case is one that has a lot of um, Fame and
certainly in the tech circles that we run in, there’s there’s some
books about it. There, they invented things like the modern GUI, uh, as
well as what you see is what you get word processing, and was really a
pretty special place.
And notably there was a branch of Xerox, the copier company, and they
were looking for innovations. I think their theme was the Office of the
Future. And they were looking for innovations around that and, and
clearly, you know, this is the 1970s, they knew that would have to do
with computers, personal computing was, didn’t really exist yet or was,
you know, still just an emerging idea. So that’s one famous example.
Uh, maybe more recently, you have something like Microsoft Research, and
I think, you know, I don’t 100% know what the path is for some, you
know, for example, interesting innovations that emerged from Microsoft,
to what degree were those laboratory projects versus some other path.
Uh, one that I find quite interesting is what we now on the Apple
platform, we talk about face ID on the Apple platform we use face ID
rather. And that uses stereoscopic cameras and infrared, and infrared
camera, which gives you depth sensing, right? So this is why you can’t
fool your iPad into unlocking by holding up a picture of your face,
because it can actually sense the the shape of it.
And that idea was first in Windows Hello, which sort of was the
Microsoft implementation of facial recognition. And that in turn, the
technology there, I think came from the Microsoft Kinect, which is
actually a gaming. Device, um, and I’ve tried to like dig into the
history on this. I don’t know if it came out of a Microsoft lab. I
think it may have come out of some other independent place. So you often
have these very winding paths where a promising technology like
stereoscopic cameras emerges, but you’re still trying to figure out the
application of it. And it’s actually quite a long distance between when
these early researchers are doing the work, and it’s in the hands of
consumers as a usable product.
00:07:00 - Speaker 1: Yeah, and I think honestly, that’s the best case
that you have this long winding path, but it does eventually find its
way into commercialization. I think one of the ideas we had originally
behind the lab was these two domains are kind of spinning in circles. So
it’s a lot of good ideas from the academic world that are getting stuck
or don’t have the appropriate context from the commercial world, so
they’re not transferring over. And on the flip side, the commercial
world isn’t tapping into the academic tradition and the way that it
should be. So you have a lot of like the, the Microsoft research and
the, the Googles and so on, they do a lot of internal research.
00:07:36 - Speaker 1: Google X maybe is their, their internal lab, or
they have a bunch of computer science just doing research on, you know,
search and stuff like that, uh, some of which gets thrown out as papers
and some of which doesn’t, but the kind of the classic path from uh
academic labs through commercialization I hypothesize is actually weaker
than it, it should be or could be and perhaps was in the, in the past.
And one of our ideas with the lab was to help bridge that gap with
something that was kind of in between with the with the so-called
industrial research lab.
00:08:01 - Speaker 2: Actually, Google search is another case. It’s not
an HCI thing, it’s more of an algorithms thing, but the founders of
Google, they were doing academic research work at Stanford, if I’m not
mistaken, came up with this page rank algorithm, which was a science
paper published like any other.
At some point, I’m not super knowledgeable about the story, but at some
point they decided to turn that into a working prototype. They set up
this search engine, they found it worked way better than anything else
out there, and they realized they could spin that out into a
commercial.
Entity. And so those two individuals took it from that early lab work
all the way through to a commercially viable product, but it takes
pretty extraordinary individuals and probably extraordinary
circumstances or at least serendipitous circumstances for that to
happen. And so what you’re alluding to there with the the gap between
The academic researchers who are exploring wild new ways we can interact
with computers and commercial companies that can bring these to people
in their everyday lives. Um, that’s, you know, in the Google case,
these, these extraordinary individuals took it across that threshold,
but what can we do to create more movement there?
00:09:12 - Speaker 1: Yeah, exactly. I think We’ll see as we get more
into HCI specifically here, that the HCI domain isn’t as obviously
susceptible to the academic tactics as other domains, so things like
algorithms are very quantifiable, they’re very repeatable, they’re
very discreet, and those are things that work well in the the
traditional academic model of of measurement and confidence intervals
and so on, whereas HCI is often much more multi-dimensional, maybe case
based, maybe hard to quantify.
00:09:39 - Speaker 2: Yeah, for sure, I think how it feels is like a
huge dimension of making interfaces, but that is something that is very
hard for science to evaluate.
Uh, it’s something that is more of a taste or judgment call, but then
science is and should be about rigor and the academic tradition and
fitting into these and and sometimes I think that does mean from what
I’ve seen of the HCI field.
Sometimes I read these papers where, I don’t know, one example was, um,
I think it was also a Microsoft research project. They did an
interesting thing where they rigged up some projectors where you could
essentially put windows from your computer, uh, individual windows,
whether it’s like a document app or something else up on the wall and
they had projectors, so basically all the walls. We were 100% turned
into these screens, but it was collaborative. So I could put up one
window, and it’s not like, while I’m, you know, screen sharing, no one
else can, someone else could put up their window and you had this shared
space that was very spatial and that sort of thing. This sort of stuff
was, was, you know, part of what was inspiring us and we were thinking
about the new opportunity. But notably there. It’s a really interesting
prototype, you can look at their video and look at what they’ve done
and read the paper and think about how this might be applied in the real
world, but they have to, it’s not enough to just build the thing and
say, hey, we liked it or we didn’t like it, then you need to go and do
some kind of quantifiable test. And they did a usability test or user
test, which is as near as I could tell was just grabbing 7 random people
that happened to be walking by in the office and having them use it for
2 minutes and then, you know, giving them a little survey and writing it
down. And it seems like, OK, well, I guess that makes it science because
you’re measuring a thing. But that’s not where we make great
breakthrough new interfaces, but it’s very difficult because you just
leave it to, well, did you like the thing you built? People always are
attached to the things they built. They always like the thing they
built. How do we, how do we measure that? That’s probably an unsolved
problem a little bit for the academic side.
00:11:34 - Speaker 1: Yeah, I think so. Thinking about things that do
work well in this space, reflecting on my own journey.
I started not so much with the HCI as like proposing a certain windowing
system or a specific gesture model. I started more on the fundamental
side.
So we think about human computer interaction, you need to understand the
human body, like biomechanics and things like that. You need to
understand the human mind, like cognition, and then you need to
understand the computer science fundamentals, things like the graphics
pipeline. So I found it very useful to go and study those fundamentals,
both within. And outside the HCI literature, and there again, that area
is much more susceptible to traditional scientific methods, so it’s
very good information. um, and then you really understand that the
fundamentals, the ground truth.
00:12:21 - Speaker 2: You know, the point about humans and computers are
equal participants in this. And I think there is a tendency for computer
people to focus on the computer.
Maybe one thing that HCI tries to do, or at least um some of the HCI
teams that I’ve had chance to interact with, including this team out of
UCSD that we met at this conference we went to, they try to have maybe a
cognitive science person or behavioral sciences person on the team, and
they are concerned more with that, how does the human mind work, how
does our attention work? How does our how do our bodies work, and then,
but you also have to connect that. Together with what’s possible with
the technology, both in the moment and of course, also in the future
where we think technology might go.
And I think, you know, for example, VR AR stuff is maybe in some ways a
hot or buzzy space or maybe was, maybe that’s died down a little bit.
But if you go read a lot of research about that, you see that for
example, one of the biggest problems with that is just a simple case of,
OK, if you got these controllers, you’re waving around in the air as
the main way you interact with it, your arms just get tired. And it’s,
it’s like they, they’ve measured this, right? They, they put people in
situations where they’re using these kinds of controllers for long
lasting tasks and they see that after an hour, you got to take a rest
and they’re they’re, they’ve tried lots of different things to try to
make that to be able to let you do a full work day the way you would at
a standard desktop computer or whatever, and they haven’t found a
solution. And so if you’re coming in, if you’re a commercial company
that’s coming in and wants to do something with this space, you
probably want to read that literature and keep those, uh, keep that
challenge, that unsolved problem in mind.
Yeah, one place to fill in more of the picture on the academic side, for
me, the big eye opener was going to, uh, the biggest conference in the
space, which is Kai last year, you and I kind of spontaneously both
decided to go. This is when we were still within the lab, but thinking
about the use. Idea and that was a really great experience because we
both got to meet a lot of the professors and researchers that were
working in this space, got to see how many people were there. I, I
don’t know, it was 2000, 3000 people, there’s hundreds of papers
submitted, many, many tracks of talks, and then we saw all of these
people who are working really hard at thinking big and thinking future
facing about what, what computers can do for us and how we can interact
with them. Some examples of just for fun, I pulled up my old notes, uh,
had a very early version of Muse. Uh, back then, a prototype that I was
working with, and I was able to dig that out of my, my archives, or dig
the the Muse board exports out of my archives. Um, we had, for example,
there was a talk on peripheral notifications, and this is where they’re
basically testing, OK, so if you have a slack notification or an email
notification or something pop up, and it’s on screen somewhere. What
can we do to put it in your peripheral vision so that it won’t break
your state of flow, or a better way to put it is just trying to
understand what what kinds of sizes and colors and motions and shapes
for a particular notification in a particular place in your field of
view, how likely that is to get your attention. And then as a person
who’s implementing something that wants to give a notification, you can
go read this literature and they have this very extensive data set. And
if you say, hey, I want something that’s absolutely certain to grab
your attention, you should do it like this. If I want something that’s
more a little bit of a note to the side, but I don’t want to distract
you if you’re in the middle of something, maybe you should use this
shape and this color and be in this space in your in your field of view.
And there’s things there about keyboards and different ways to improve
typing on mobile, there was lots of things about wall mounted displays.
Uh, there was, um, Ken Hinckley’s group, uh, which has been a source of
inspiration for us at use. They do a lot of stuff with tablets,
particularly around the surface platform. They had one that was, I
don’t know, they attached a bunch of extra sensors, they basically
strapped a bunch of extra sensors onto a standard consumer tablet and
they use that to detect, I think what they called like postures, so they
could tell better the grip, like how you were holding the tablet at the
time and then they can make the software behave differently. And clearly
this is not something you can use in production. They, this is the
equivalent of a raspberry pi taped onto the back and a bunch of sensors,
you know, kind of hot glued on around the edges. This would never work
in commercial environment, but it suggested some things you could do if
such a capability. Existed and I think that that is a good example of
what um what I think this field of this best does is it it it gives you
possibilities to draw from and then it’s the applied people, what we
would normally call just people building products that can potentially
go and draw from that pool of ideas and that pool of things, finding
things that have been learned and use them to make potentially new
products that solve uh new problems or old problems in new ways.
00:17:07 - Speaker 1: Yeah, this experimental slash prototype approach
is probably the thing that we um most think of when we think of HCI.
Another type of work that I found very helpful is the ethnography, where
you go and you understand how people actually work day to day and
what’s worked for them and what hasn’t.
Couple of examples there. One is a book called, I think it’s a small
matter of programming or the simple matter of programming. This is a
study of uh end user programming in the wild, things like Excel
spreadsheets, CADS, and what actually works there, and because they talk
to these people who are actually doing work every day and and having
success or not in these environments, they’re able to pretty deeply
understand what is useful in the way, in a way that you probably
couldn’t get with either theorizing or experiments.
00:17:50 - Speaker 2: And I’ll just interject to say that one was a big
inspiration for uh Hiroku.
And it’s also a good indicator of how much the academic world is ahead
of in a, in a strange way.
We think of maybe in the startup world or the tech world or whatever,
oh, we’re so on the cutting edge of things, but a small amount of
programming was written in 1993, if I’m not mistaken.
And this was 2006 or 2007 when I was reading this and and applying some
of what it, um, some of the ideas that were in it went into Hiroku. And
so at that point, the book was already 15 years old, but a lot of the
research and understanding in it and ideas that suggested were still
really bold, innovative, or just thought provoking, in a way that
current technology and software products and certainly programming tools
um had not taken advantage of or um learned from.
00:18:45 - Speaker 1: Yeah, a lot of the ideas that one tends to think
of in HCI perhaps as as a supposedly novel interaction or approach has
actually been tried before. I think it’s very important to understand
that prior art, especially if it basically didn’t make it into the
commercial world and like, why is that? Or else you’re liable to make
the same mistakes again. Um, another example that I’m thinking of was
the study. Of so-called folk practices with computer programs. This is
like little habits or techniques that people have picked up to make
themselves more productive with programs, and they found two examples.
One is lightweight version control by making copies. So if you’re in,
if you’re editing a photo and you want to, you know, have some quick
version control.
Uh, you might, uh, duplicate the item in your canvas, like in Figma, you
know, make another copy of it, and then fiddle with the new version, and
then you can kind of compare it to the old version, even if you don’t
have like a, you know, get for Figma or whatever.
Um, another one was this idea of everyone likes to have a little scratch
space where you can like put, you know, your little clippings and bits
and things you’re working on, and that was one of the inspirations for.
the shelf in the original Muse prototype.
00:19:47 - Speaker 2: Another book we both read around that time was The
Science of managing our digital stuff, and they had a lot of insights,
again, things that I think we borrowed from a little bit from Muse, but
because they come into it from this ethnographic or academic
perspective, they just want to learn, they want to collect the data,
they want to understand users. They’re not coming in with the point of
view of like, we have a product we want to sell you or or just a uh A
product we believe in and we’ve already bought into the mindset of,
they just want to learn.
And so one insight there was people who have been designing file
systems, that is the way we store documents on our computers for decades
have talked about the hierarchical file system, that is to say, folders
that nest inside each other, uh, is no one thinks that way and hard
drives get messy and no one wants that, maybe we want a tagging system,
I think BOS had a version of that, um, maybe we want fast search or
whatever. And these folks just did a bunch of studies of people
including how they use Dropbox or Google Drive or their own hard drives
or just the way they manage their files, and pretty reliably, people
like putting files in folders. And they like pretty shallow hierarchies
and they can remember where it is and it’s best for them if it’s only
in one place. And you can sit there and talk about how that’s not the
best solution or whatever, but they, they did a pretty broad survey and
just saw this is what people want to do despite the existence of other
ways of doing it and the other kinds of solutions, including search and
tagging and so forth. At some point you have to acknowledge the reality
of this is how humans behave, and even if we don’t like that behavior,
we need to think about that when we build tools for them.
00:21:27 - Speaker 1: Yes, if you’re contemplating doing a search-based
or tag-based information management system, please read this book.
It’s, it’s super critical.
00:21:35 - Speaker 2: There’s an interesting tension there between, I
think the academic world. is not only good at, but is science is
essentially built on prior art and you’re building on what came before,
right? Any paper that doesn’t start with a survey of other research
that this is built on or related to or other people have tried similar
things, and you’re you’re extending the tip of human knowledge,
hopefully, by building on everything we already know.
Um, and so for that reason, the academic world is very good at the the
prior art thing. And maybe the startup world is all about, hey, I’m a
24 year old that doesn’t know anything and I’m totally naive, but I
have this wild idea for a thing I want to build, and 99% of that at the
time, that turns out to be an idea that a bunch of other people tried,
it doesn’t work and fail for all the same reasons as everyone else
does, but 1% of the time it turns out that some assumptions about the
world have changed, and it is that naivety, it is that. Not looking at
why people failed before that it allows you maybe to find an
opportunity. So there is, there is a bit of attention there, but
sometimes the um I’m very appreciative of the what people have thought
about this, they studied it in depth, there’s a lot of prior art here,
like look that up before you start building things, um, and I think that
that would be advice I would give to my younger self, I think at a
minimum. Alright, so that gives us a little bit of the landscape of of
HCI. Now the next part of the question was, how do you actually get into
this field? I think that’s kind of a tough one, so I’m gonna actually
say that for the end. Uh, but in the meantime, there was a follow on
question here and Fetta says, how do you forget or ignore current
patterns and come up with new ones? You have some thoughts on that,
Mark?
00:23:14 - Speaker 1: Yeah, I come back to this first principles idea of
really understanding the basis for all of this, the biomechanics, the
cognitive science, the computer science, and then understanding the Um,
assumptions or lemmas, uh, of the current design paradigms.
So, you know, for example, Uh, one thing we see with with phones is most
apps are designed for only one finger to be used at a time, and it would
be a mistake to translate that design constraint or design decisions
over to a tablet, we think, but a lot of apps just kind of blindly do
that do that because they’re both iOS and they’re both touch apps.
Um, another example even more relevant to use is the pencil. A lot of
the gesture space of tablet apps can’t assume that the user has a
pencil because Apple and the various app developers just aren’t willing
to make that assumption. Uh, with, with muse, we realized that was, uh,
assumption that people were making and one that you could take the other
side of. So we’ve basically said you really need a pencil to use muse
and therefore we’re gonna have some of the functionality behind that,
you know, that, that, that physical gesture.
00:24:15 - Speaker 2: Yeah, the status quo is a powerful force for all
of us, and we, we tend to act on not quite habit, but this stack of
assumptions about the world and what the right way to do something is.
And here’s where I like to think in terms of maybe a spectrum between
on one far extreme is the research thinking, the out of the box, wild
ideas, weird ideas, when you go to one of these HCI conferences, this is
what you see a lot of just Sometimes frankly pretty wacky mad scientist
kind of stuff. Now, um, but actually there’s only certain times where
that is appropriate and in fact, doing research is a place where that is
appropriate. Typically, if you’re making a product that you expect
people to use in the real world, it’s actually a bad thing to have
weird out of the box ideas, particularly about basic interactions. You
want the status quo, you want the known path, they usually called the
best practice.
And I’ve certainly run into this on. Teams where I don’t know, you’re
building a basic e-commerce site or something like that, and there’s
someone there that wants to do something fun and exciting and so
they’re like, and so they say, why not, let’s try this wild idea, you
know, instead of checking out like this, you you do this crazy thing and
99% of the time that’s just a bad idea. Please do it the way that other
people do it.
And this is one of the things that I think tends to make software so
high quality in the Apple ecosystems, both Mac and then even more so on
iOS is you have this pretty stringent set of, you know, they call it
guidelines, but in many cases are just outright rules to get your app
approved.
They have this very extensive culture and set of principles and so forth
in the human interface guidelines and in all the precedent with Apple
apps and the wider ecosystem there. It’s all really good and it all
hangs together and it works well and people know how to use it. And so
most of the time you actually should do the boring, expected common
known path thing. And it required, but it’s a shift in mindset, a fun
one, but, but also takes some stretching of the brain, you challenge
yourself a little bit to go into the research thinking mindset as both
of us did, we went to to Ink & Switch.
00:26:29 - Speaker 1: Yeah, I think that’s an important point and a
balance to strike. Another big source of inspiration for me has been the
world of analog tools.
We’ve been thinking about how to build good digital tools for maybe 50
years or so. We have a couple of 1000 years of explicit and implicit
study of how to create analog work environments, so things like personal
libraries, uh, studies, uh, workshops, artist studios, in some cases,
there’s explicit treatises about how you organize one’s library, but
there’s also just a huge amount of implicit and embedded knowledge in
the patterns that we use every day and that people have kind of
habitually used to organize, you know, say the library.
So I like to look at the, the physical world and see, how can we just
like, as a baseline, make it as good as that. So a simple example would
be, if you use ink on a pen, it has zero latency. If you use ink on a
really good tablet app, it might have 15 to 20 milliseconds, which is a
lot. And if you use it on a bad tablet app, it might have 50
milliseconds. Um, so that’s a really basic example of how there’s a,
there’s a simple bar to set. Uh, another one that I think about a lot
is multitasking. So if you have a desk, and you have your main piece of
work in front of you, and you have some notes to the side or uh up on
the top of the table. It’s super fast and easy to multitask your
attention, just like you kind of move your eyes or you move your neck
and your eyes re refocus, maybe you lean into one side or the other, um,
but it’s it’s super fast and lightweight. What you think about a
typical iOS app, it’s like, you know, press next page, transition
animation, spinner, loads, fonts come in, right? And so it’s it’s very
discouraging to actually do this kind of multitasking work.
00:28:06 - Speaker 2: And maybe the flip side of that of taking physical
world information practices, things from artist studios and offices,
file folders. Scissors, rulers, pencils, desks, you do tend to get,
especially the first time an analog process comes on to is digitized.
So you think it’s something like desktop publishing going on to
computers in the 1980s or yeah, word processors was taking what was a
typewriter or a typesetter and moving that onto the screen, spreadsheets
that were that way, um maybe PowerPoint, uh taking overhead
transparencies, bringing onto the computer in the late 80s, early 90s.
In all of these cases, they tend to be very literal. Like the first
version of PowerPoint was a way to print out overhead print
transparencies, and it wasn’t until much later that the idea of a slide
deck that would be all digital and you would never need to print out and
put on a projector, uh, showed up. And then often you when you look back
at these first transliterations from the analog world to the screen, you
see this thing where it’s, oh, isn’t this funny? You know, there’s
the little, the little picture of the trash can and a little picture of
the Um, you know, often very literal and kind of heavy handed and not
taking advantage necessarily of what can be done in the new medium. Do
you have a, I don’t know, a sense for the how we take the best parts
and the things that work about the physical world, knowledge tools that
we’ve been working with for so long and are so adapted to human needs,
but not also get stuck in a weird rut of translating them directly so
that we don’t get the benefits of the computer.
00:29:39 - Speaker 1: Yeah, I don’t think there’s a simple rule for
that, but again, I come back to the fundamentals. A lot of the stuff is
driven by the like the biomechanics or the cognitive structures of our
mind, which isn’t going to change. So for example, we have a very
realistic, deeply embedded expectation that when we like touch something
and move our hands that it moves, and that I think is basically not
going away, and it would be a mistake to think it’s going to go away.
Uh, likewise, I think we have quite embedded cognitive arch. texts
around both spatial memory and associative memory. I think those are
basically baked in and they’re not going to go anywhere.
00:30:10 - Speaker 2: I guess that comes to mind because I feel like
that tension or it’s not even the right word for the interleaving of
try to draw the best parts of the physical world workspaces, but also
really embrace this digital space and it’s part of the pitch, I guess,
or the the value hypothesis for use as a product is that.
We are going to take taking something you previously did with Post-it
notes and your whiteboard and your notebook and some printouts of some
screenshots that you scribble on that are on your desk, and moving them
into this expensive and fragile computing device. That it will have new
capabilities and new powers that you couldn’t get. And so getting
bringing those best parts across, which is, for example, that yeah, you
touch something and it moves right away and there’s this
instantaneousness to it, and then you’re not like looking at spinners
and loading screens and whatever, um, but also taking advantage of all
the Um, incredible capabilities and the great depth of possibility that
exists within once you move to the digital virtual workspace.
00:31:18 - Speaker 1: Yeah, one idea for an exercise here and this kind
of gets into our next question would be just to try to understand and
catalog the properties of these physical workspaces that are
interesting. So for example, I have a desk here that I think is 6 ft by
3 ft.
00:31:32 - Speaker 2: For our non-American listeners, that’s probably
about 2 m by 1.5.
00:31:38 - Speaker 1: Yes, thanks, Adam. So you have this desk and
imagine it’s covered with like textbooks and notes and photo printouts
at, you know, say 200 DPI. What’s the resolution of that? And if you do
that exercise, you’ll see that it’s like massively bigger than even
our most advanced displays, it’s not even close, and just being kind of
aware of those basic fundamental properties of the physical world and
how they might or might not be reflected in your app, I think is a good
baseline.
00:32:02 - Speaker 2: So we mentioned academic HCI work, which tends to
happen in universities and funded by grant money and the output is
published papers, and then there’s corporate R&D which is divisions,
separated divisions, but still departments within some large company
that has a lot of cash, like a bell, or a Xerox or a Google to throw at
potential new innovations, but there’s a third category that Or at
least I hope it’s a category now, uh, that it’s much more rare, but I
can switch falls into this, and that would be the independent research
lab. And the hypothesis behind I and Switch was what if we take the
corporate R&D lab, but we cut off the corporation. And this quickly
leads you into how does this stuff get funded and our um.
Our mutual friend, Ben Reinhard has a whole series of excellent articles
about how innovation happens and particularly the different kinds of
funding models that can happen and how it gets funded in turn leads into
the incentives of the people doing it and there’s quite a, quite a
rabbit hole there for those who are interested in it. But the concept
behind it and switch was that we could get some grant money to do
independent research. With the idea that it would generate called
intellectual property. I don’t love that term, but basically, ideas
that could potentially be commercialized and ideas with enough depth to
them and research, and where we falsified ideas that were no go, and we
had some really compelling ones. One of those turned out to be Muse,
which we we went ahead and spun out to begin the commercialization
project process.
But there There are a few others that I know of that are independent
labs. One is um Dynamicland, which is sort of Brett Victor’s effort to
bring computing and programming in particular into a more spatial, a
physical spatial environment, not just on a screen.
And then another one that I know of is um maybe more in its nascent
stages, but Andy Maze has done amazing work on mnemonic devices. And
he’s, I think funding and stuff maybe started with Patreon and maybe
led up to institutional funding kind of more of a kind of a, what’s the
word for it, a nonprofit, more of a philanthropy type approach. But I
think there’s no great answer for how independent research can get
done, but I at least I hope that I could switch is an interesting
example, if not role model for others that might want to see how they
can push the frontiers forward in a particular space.
00:34:24 - Speaker 1: Yeah, that’s both the challenge and the promise
of this third type of institution on the academic side, you’re very
limited by your work has to fit in the box of like a peer reviewed
quantifiable research paper and in the commercial world, it needs to be
commercializable in the next, you know, probably a year or 2, maybe,
maybe 3, but all the good ideas don’t fit in one of those two boxes. As
hard as it is to collect them with this third organizational type, I
think it’s worth trying.
00:34:47 - Speaker 2: It’s a great point. I think the time horizon is
one of the key.
Variables, let’s say that defines what I would call research for for
anything, but certainly for human computer interaction, which is, um, I
believe Xerox Park actually had an explicit time horizon of 10 years.
Which is definitely way beyond what a commercial entity would normally
do. Um, and I think, you know, basic science even has a longer time
horizon than that sometimes.
But yeah, when you look at maybe university labs, they’re thinking
forward really, really far, um, maybe corporate R&D labs are thinking
further than their commercial counterparts. And then if you talk about a
startup, particularly something. combinator, you’ve got to build that
MVP, get it to market, validate it, get customers. You can’t be
building it on some shaky technology that one, you don’t know if it’ll
work, and two might take many years of development yet to come to come
to enough maturity that you can base something that people really want
to build a product that people will depend on.
00:35:44 - Speaker 1: Yeah, and I also think you get a bit more wildcard
energy in these independent orgs, you know, the, the academic
institutions and the, the big commercial labs are just necessarily more
constrained and structured, and you can have just more eccentric people
doing stuff on the independent side, which sometimes leads you down
weird dead ends, but sometimes you get really interesting results and it
kind of injects a new idea into the mix.
I’m actually we talked mostly about like independent research labs or
research efforts. I also consider like indie creators, artists,
tinkerers in this bucket too.
One example that comes to mind is that the video game Braid, which is
this amazing like time traveling based game where the time traveling is
like very smooth and scrubbed frame by frame. Um, that’s actually been
something of an inspiration for me thinking about like version control
and time travel for productivity tools.
00:36:33 - Speaker 2: Yeah, I think that’s Jonathan Blow, and he also
went on to make.
Other like category breaking games, uh, trying to remember the name of
it, there was a puzzle game that was actually really nice on the the
iPad that I played with my girlfriend at the time.
And then if I’m not mistaken now, he’s working on inventing a new
programming language.
So yeah, so that the, uh, maybe it just takes a certain mindset, a
desire to perhaps even a um a drive to think outside the box and do
weird stuff.
And yeah, I certainly agree that Labs depend on weird, wild, I think I
saw the word maverick used quite a bit when describing um there’s this
book called Dealers of Lightning, which I think covers, covers Xerox
Park and and kind of those glory days pretty well, and it talks about,
yeah, there are these, I don’t know, kind of long hair types and, you
know, don’t wear shoes in the office and of course those aren’t the
qualities that make them good researchers, but it’s connected to this.
Maybe desire to do a weird thing to not conform to try stuff at the
fringes, to be actually fascinated by things that are at the fringes, as
opposed to, this is weird, who cares? I want to work on something more
mainstream, let’s say, um, and not to say that that’s a better or
worse approach to bring to your work, uh, just that it, it fits in a
different space in the innovation cycle. Well, maybe that brings us
around to the core of the original question, how do you get into this
field?
00:38:04 - Speaker 1: Yeah, and I, I feel like there might be two
different questions embedded there.
One is maybe how do you participate or contribute or even just kind of
find, find out what’s going on, uh, and the other is how do you make a
living doing it.
And, uh, I, I think making a living doing it is, is harder, but it’s
maybe simpler to answer. There, there are two main paths right now.
There’s the academic path and there’s the corporate path. Um, the
academic path you you basically you go to graduate school and you get a
PhD. Uh, but even after that, it’s, it’s quite challenging just
because it’s so competitive in the corporate path, you become a
practitioner and you, you do good, you know, engineering or product work
and eventually you can enter this more researching ladder. But I’m not
sure we have that much to contribute on that front because neither you
or I have gone down those paths, maybe more of the how do you engage
with the community where we should focus here.
00:38:43 - Speaker 2: Yeah, absolutely. Well then, you teed up really
nicely. How should we engage with the community?
00:38:49 - Speaker 1: Well, step here I would say is start digging into
the literature, you know, it sounds obvious, but I think a lot of people
haven’t done this either they don’t realize it’s there or they’re
intimidated by it. Um, but this reminds me of Rich Hickey’s classic
talk, hammock driven development. He’s like, if you’re working on
something like you. I think you need a hash function that does X going
to Google Scholar type hash function that does X enter and see what
comes up. Like there’s almost certainly going to be something there.
00:39:12 - Speaker 2: Well, maybe there’s a great chance to talk about
something again.
I coming purely from the what what academics would call the industrial
side, uh, yeah, working in companies that build products that they sell
to people. That’s what I did my whole career.
And so things like the fact that all this academic work tends to be
published as PDFs in a particular format, there’s a lot tech to
formatted to column PDFs, they have a particular style of writing, they
have this particular style of citations, you typically, they’re not
always open access, but when they are, they’re PDF on a web page, and
the search engine for them is something like Google Scholar.
I I actually didn’t know that. I didn’t know how to go find those
things. And so as a Let’s say as a product developer, designer or
engineer, I knew how to Google for stuff. I know how to find stack
overflow. I read medium pieces, I read people’s blogs, I follow other
folks in my field on Twitter, but the academic world of things was sort
of a dark, yeah, was dark to me, except for on occasion, I would stumble
across a book like the one you mentioned earlier, a small matter of
programming.
And I feel like I discovered this incredible trove of knowledge from
someone that came at the the problem space from a very different
perspective.
And I think it also goes the other way, not as much, but I think
academics are less likely to read the medium think piece posted by the
product designer, the engineer, and basically the two, I think the two
communities, if that’s the right way to put it. Uh, have different
communications conventions and different ways that they share knowledge
with each other and different systems for evaluating. Uh, importance and
so on.
So it’s very hard to, um, if you’re, if you’re steeped in one, it’s
hard to cross the world into the other.
So maybe that comes to all right, you find some hooks into this, you can
follow some people, whether it’s on Twitter, whether it’s through
their personal blogs, you can start to find some papers and Google
Scholar on the topic, you can find some slack communities maybe that
talk about this stuff and you can try to get hooked into it and and.
Again, if you’re someone that comes from more the practitioner side, we
might say, engineering products, design, uh and you haven’t been
exposed to the academic side, going and and exposing yourself to that is
a very good idea and maybe vice versa.
00:41:30 - Speaker 1: Yeah, and one other thing I would emphasize there
is that you can do this citation crawling practice where you find a
paper that you’re interested in, you can go look at the, the
references, and this will refer to a bunch of other papers and sometimes
books and in HCI it’s mostly papers, there are a few books, and then
you can type those titles into Google Scholar and follow them that way.
And a good way to kind of know if you’re getting your hand around the
literature is if. When you read a new paper and like you basically
recognize most of the citations or they’re kind of off the edge of your
um your map in terms of your area of interest.
So you’ve kind of identified the full graph of relevant papers and then
you’re, you have a good handle on the literature.
00:42:05 - Speaker 2: And I think this is something that’s very much
you learn this in the academic tradition, which is if you want to
advance the state of the art in a field, first you need to know all the
things that humans already know.
And you do that by consuming all the literature, and you know when
you’ve consumed all the literature exactly the way you described, kind
of a crawling process, which is you start with a few seminal papers or
you start with a few that are your starting point and you follow all the
citations until you get to the edges of it and you feel like, OK, I’ve
filled in this space now I know. in some kind of um general sense, what
humanity knows about the subject. And now if I am, if I have novel ideas
or I want to do new research or I see open questions that stand on top
of this, now I can go do that in order to potentially contribute to
this.
00:42:52 - Speaker 1: Yeah, and then speaking of taking that next step,
it can be intimidating, certainly if you want to jump all the way to
publishing in a peer reviewed journal, but I think you can take more
incremental steps.
One example that comes to mind is Dan Lew’s work on latency in computer
systems. Uh, he did a series of measurements and experiments to assess
uh the different latencies like from your keyboard. Your monitor for
when you move your mouse to something happening, and uh but he was able
to publish this on his personal website, and it’s not an academic peer
reviewed paper, but it’s, that work has been quite influential, and you
can indeed reach the kind of the caliber of academic work, even if
you’re not participating in that full pipeline.
00:43:29 - Speaker 2: I’ll note that um work, and if I recall
correctly, it’s published on kind of a really basic HTML page with very
limited formatting and and whatever feels very um homegrown and
authentic.
But one of the things he does that’s so compelling is he says, he
starts with this hunch, which is computer seems slower than I remember
when I was younger, but then he goes to, you know, maybe the way if you
don’t come at it from that scientific rigor position, you might go, you
know, computers seems slower. I’m gonna like make some snap judgments.
And then I’m going to go write a blog post and complain about it. But
what he did was say, well, are they actually slower? And he got a, I
don’t know, some kind of high speed camera set up and set that up and
pointed it at the keyboard and the screen, and he recorded himself
pushing a key, and then you can see on the camera when it appears on the
screen, and then he, he wrote down exactly to the millisecond and he did
that with a whole bunch of different devices, including some computers
dating back to the 80s and then he put them all on the table and sorted
them in order.
And that’s a simple. Application of the scientific method to in this
case, a very literal human computer interaction. How long does it take
when I press a key when it appears on the screen? And that doesn’t say
how long it should take or what would feel right, but you can put now
real numbers to this intuition that maybe computers are more sluggish
than they were at a different time.
00:44:55 - Speaker 1: Yep, exactly. And then if you are looking to take
that step towards uh participating in these peer reviewed journals, a
possibility that we’ve had some success with is collaborating with an
established academic in the space. Um, Adam, you’ve kind of spearheaded
our collaboration with Martin, maybe you want to describe that.
00:45:12 - Speaker 2: Right, well, we were lucky enough to get to work
with Martin Klepman, who’s a one of the world’s experts on, say data
and data synchronization, particularly around another track of research
we had in the the lab around um what we eventually called local first.
And he is someone who was in the indust, let’s say the industry world,
he was doing startups and at some point felt that he can contribute more
to the industry or the world by jumping over to the academic world to do
more basic research around algorithms having to do with um synch data
synchronization.
And so we were lucky enough to get the chance to work with him within
the context of the you can switch lab on a kind of a light part-time
basis.
And that led pretty naturally to, OK, well, we want to write a piece and
publish it. And he wanted to publish some of his findings and he said,
hey, you know, I think this could go into the academic format.
And I said, well, Well, how does that work? He’s like, well, basically
we take this web page we wrote, we put it into a lot of tech, we change
some of the wording to remove, make it less emotional, uh, we changed
the links into the citations where that makes sense, and we, we had a
whole process to make it into something fits this format that’s
expected by the academic world, and then we submitted it to a
conference, uh, where it was accepted and eventually I actually ended up
going to present it for.
Um, various travel logistics reasons. Um, but yeah, that was a very
interesting experience because the four authors on the page, uh, the
paper, I think you and Peter maybe both have a good bit of academic
experience, although I don’t know if you’ve published that way
before.
Martin is extremely good at that stuff, and then I knew very little
about that world, but working with someone that knows all the ins and
outs of it was a very um rewarding way to to learn about it.
00:46:58 - Speaker 1: Yeah, exactly. And to be clear, we didn’t just
jump right to that, you know, a collaboration with one of the world’s
leaders in synchronization technologies. There’s a little bit of a.
00:47:09 - Speaker 2: Yeah, don’t email Martin and ask him whether
he’ll write a paper with you, he doesn’t know who you are. That’s not
what I’m advocating for.
00:47:15 - Speaker 1: There’s there’s a bit of a proof of work
function here where if you do some of your independent research in the
space, and especially if you publish something that’s coherent and
compelling, it becomes much more.
You know, reasonable to establish a collaboration. Actually, when we did
some of our publications around Muse and our latency measurement work, we
had a few academics reach out to us and you know, say that’s
interesting, maybe we should, you know, do some work together. I don’t
think we’ve brought any of those yet to the point of writing a paper
together, but it just shows that once you have some, some work out in
the world that shows that you’re serious, that you’re engaging
somewhat in the academic tradition that you’re aware of the literature,
that you have contributions, um, it becomes a more feasible to have
those collaborations.
00:47:54 - Speaker 2: Yeah, perhaps like any other intellectual or maker
or tradition, this is a world or a community or a society that thrives
on seeing what else you’ve done, and if you see that someone has done
great work that overlaps with work you’re interested in, and that
creates opportunity to connect, to learn from each other and then maybe
lead to, can lead to collaborations.
And yeah, maybe it’s not such a huge leap from do a weekend hack
project and write up your learnings about it to eventually doing
something a little more deeper and a little more serious that brings you
in the direction of um the academic recognized academic world.
Well, it’s interesting to note then that In doing the research lab, we
came to it not from the perspective of how do we become a part of HCI,
but rather we just wanted to see computers and computing interfaces get
better uh in in some particular ways that led us to doing maybe some
interesting experiments that led to some novel research that we we
published about, and that in many ways opened the door to us to be more
connected to this larger academic field. Is that something that a path
you would recommend for others?
00:49:05 - Speaker 1: Yeah, there are certainly interesting paths there,
you know, there’s this independent research lab path, and of course,
there’s the academic and commercial path, and I think those are all
interesting.
I would also say though that being a scientist or being an innovator
isn’t a hat that you’re granted by some external institution. It’s a
way of thinking, it’s a way of navigating the world.
You know, a scientific method is something anyone can use. Publishing is
something anyone can do.
Everyone can read the literature. So if you’re interested in this, I
don’t feel like you’re, you’re stuck because you don’t have some
credential like a PhD. Anyone can step into this world, go on to Google
Scholar and read literature, and then maybe you have something to
contribute on top of that.
00:49:40 - Speaker 2: It’s hard to think of a better place to leave it
there. If any of our listeners out there have feedback, feel free to
reach out to us at @museapphq on Twitter or hello at museApp.com by email.
We’d love to hear your comments and ideas for future episodes, and big
thank you to Fetta for giving us this very uh intriguing and deep topic
to explore. I’ll catch you next time, Mark.
00:50:04 - Speaker 1: Great, thanks, Adam.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Infinite canvases are essentially like a different
document format. The screen represents a camera that’s floating above a
surface, and there are things on that surface, and those things can be
anything. You can move them, you can duplicate them or resize them, and
that each one of these types of thing on the canvas also has its own
rules about how it can be changed.
00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Us as a tool for
deep work on iPad and Mac, but this podcast isn’t about muse product,
it’s about the small team and the big ideas behind it. I’m Adam
Wiggins here with my colleague Mark McCrannigan. Hey, Adam. And our
guest today is Steve Ruiz of TL Draw. Hello. And Steve, I understand
you’re a little bit ahead of me on the fatherhood journey. You’ve got
a 315 year old. What do I have to look forward to in the coming couple
of years?
00:00:55 - Speaker 1: Oh man, a kid is what, like 1.5?
00:00:58 - Speaker 2: That’s right.
00:00:59 - Speaker 1: Eventually they will start drawing, they’ll start
playing with words, and they will grow ever more interested in iPads,
and also, everything will be an iPad, every computer, every device,
everything with the screen will be an iPad. That’s my prediction, yep.
00:01:17 - Speaker 2: Yeah, that makes sense. Yeah, already is the case
that trying to keep screen time limited is a challenge. Now, of course,
we can also look forward to having built in beta testers for our
software. You got a chance to do that yet?
00:01:29 - Speaker 1: Yeah, actually, my daughter has probably spent
more time with tealra than anyone else, and I’ve learned quite a lot by
watching her kind of poke around and try and draw, try and make
different things. She really likes arrows, but the touch targets are too
small and mobile. That’s one thing that I need to work on.
00:01:46 - Speaker 2: I’m reminded of a scene in one of these Steve
Jobs biography movies where I believe it’s his daughter comes in and
tries out Mac Paint, and they sort of show this maybe hypothetical idea
that he was sort of inspired to make software and a computer generally
that was easy enough that a young person could be creative with it.
00:02:04 - Speaker 1: Yeah, I mean, if you have, uh, they’re kind of
hard to schedule or bring into the office. I don’t think the agencies
do 3 year olds, but toddlers are excellent beta testers. They won’t
tell you what’s wrong, but you’ll definitely see it.
00:02:19 - Speaker 2: So you’re working on TLDraw. Tell us about that
project and your background that brought you there.
00:02:24 - Speaker 1: Yeah, so Tal Draw it started out as like an open
source project, I guess it still is an open source project. It grew out
of kind of earlier open source work that I did with a library called
Perfect Freehand, which is an algorithm for creating like digital ink,
so pressure sensitive or variable width lines, takes a whole bunch of
input points, and comes up with a whole bunch of output points that kind
of describe a shape that surrounds the input points. So, perfect
freehand, I kind of started working on it pretty publicly on Twitter. So
posting all these in progress GIFs and talking about the different ways
that I was trying to solve this problem of doing pressure sensitive
slash variable width lines.
You can’t really do that in the browser, like it doesn’t have any
primitives for like lines that change their width. So, hence the whole
like journey into trying to figure out how to do that kind of
programmatically myself.
It works, it works super good. I would recommend it if you have anything
to do with the browser that needs to have a kind of a cool ink. And
it’s being used all over the place. It’s used in Draw.io, it’s used
in Excali Draw, it’s used on, I think NextGS Live uses it in their
product.
It was one of these situations where The status quo for like a pencil
tool or a pen tool was like so poor on the internet or on the browser
especially. That any improvement sort of would have been well timed and
perfect freehand just happens to be an improvement that is pretty good.
You should use it. That’s what I say.
So, I’d been working on perfect freehand, I’d been doing some
integrations with like other diagramming tools like cala Draw and I
guess in along the way of making perfect freehand, I built a couple of
these. Canvas playgrounds almost, places where I could test this thing
out or try out the different algorithms, see where it was going right or
wrong. And I’ve done that a couple of times for Perfect Freehand, also
for like a kind of an offshoot of this project called Globs. But anyway,
I just made enough of these sort of infinite canvas editors that once
Perfect Freehand was pretty much done, I started working on that kind of
a framework.
Originally it was gonna be like a programmable design tool that I could
use both together with direct manipulation, but also with like, you
know, programming, in order to help me figure out problems like perfect
forehand or problems like cool arrows or something. And once I started
posting that, On Twitter, saying like, oh cool, I’m looking, I’m kind
of making almost like a figma that you can program, or a figma that you
can put anything on the canvas that you want, and I’m doing it in
React. That story suddenly got pretty popular. Like I had folks reaching
out to me and saying like, hey, we’re building something that kind of
needs this kind of canvas. Can you open source this or can you share
this or can I hire you? So based on that attention, I was like, all
right, well, maybe this is worth proceeding with. I took some time off
between jobs. I was gonna start a job actually at Adobe, and I thought,
OK, I’ll take some time off in between and I’m just gonna work on this
project, make it open source, spend 6 months on it, and then, yeah, see
what happens. Worst case scenario is that I’ve made something really
cool open source, worked on something interesting in this space, and I
should say there’s really very, very few open source kind of canvas UI
type of tools out there. And none of them that were using this kind of
react driven canvas.
00:06:04 - Speaker 2: It’s interesting that you got that initial
demand, you might say a product manager lingo might be it’s sort of
market validation, you know, don’t build it until you already know
people want it. Even before you got into the project itself, did you
have a sense of why people wanted it or had they tried to build it
themselves and discovered it was hard? Had they not built it and they
just hoped someone else would do it for them? It just they liked your
other work and they just thought if you did a good job on this other
library, maybe you do a good job on this library too. What was the core
of their demand, I guess.
00:06:36 - Speaker 1: Yeah, my theory about this or my guess about this
is that this was 2021, so not too long ago, 18 months ago maybe. We were
still middle of the pandemic, seemed like everyone had started using
these apps like Miro or Mural or I think Fig Jam had just been released
and The place for online collaboration was starting to just be the sort
of the whiteboard, you know, abstractly like this 2D kind of surface
that you could move around on and interact with people and co-create
this type of surface.
And the tools in that space were pretty mature, like again mural fig jam
was new, but it was already, you know, built on good bones of FIMA
itself. And so, As normally happens with like successful general
products, like you start seeing different teams wanna carve off
verticals for that, say, like, OK, cool, Mirro is great. Mirro is for
everyone, Miro is for everything. What if it was just Mirro for project
managers? What would that look like? Can we steal a billion dollars off
of Canva? Can we, you know, take a little bit of that giant market from
FIMA or something? The issue there is that all of these tools, pretty
much anything. That wants to use that kind of canvas UI, it’s a tough
engineering problem. And there’s like a ton of uh functionality maybe
of like a canvas like that that is like, it’s almost like a text editor
that it just has to be there in order for it to feel complete. And if
it’s not complete, it’ll feel broken. But if it is complete, if it has
those like table sticks features and all that, then congratulations, no
one will notice because they expected them to be there from the
beginning. And maybe you ran into some of this with Muse as well like.
Selection should just work, like Undo reader should just work, the cloud
stuff should just work. And some like really gnarly, like logic puzzles
involved in these type of things that we take for granted in something
like Mirro or fig jam. Yeah, like they’re they’re just gnarly
problems. Never mind the whole like, how do I render this thing. So when
I started saying like, look, this is something that you can use as like
a starting point, where all those problems are gonna be solved. Now
it’s just about picking like, what do you want to put on the canvas,
how do you want these things to interact with each other. I think that
story of giving someone like good open source starting place, that was
like the compelling story. It’s just like the same with maybe like
prose mirror or a code mirror. Text editors are super hard, no one wants
to build one themselves. I mean, I don’t want to build a text editor
myself ever. But I do want to make apps that include them, and I do want
to do stuff with them, and if I can do that on open source work, then
all the better. So, I think that’s where the validation started
clicking in, or like pre-validation. I didn’t have an idea really, but
I did notice that there was a demand for this kind of thing, because,
yeah, it was becoming more of like what software looks like, especially
around collaboration, like it looks like a canvas.
00:09:30 - Speaker 2: Fun little parallel story there from the Hiroki
days, which is a very early version of Hiroki that was mid-2000s, 2007,
2008, had a text editor in it, but yeah, we had to implement that from
scratch in the browser and you know, pretty quickly you exactly as you
said, all these table stakes things you just expect to work,
particularly in programming editors, you know, we had to implement it
and that’s not the differentiated or wasn’t the differentiated part of
the product at the time.
But it wasn’t long after that that the AC editor, I believe it was, was
kind of the first really solid open source in the browser code editor,
and that seemed to unlock a kind of explosion of people seeing that.
I mean, I know GitHub used it in the early days for some of their stuff,
but lots of other projects did as well. Suddenly people saw, oh,
there’s a really good code editor that covers that table stakes stuff.
Now I can build this weird project idea that I had that I haven’t been
doing because I don’t want to have to build a whole, you know, fully
functional text editor first. That’s just too hard and isn’t the core
of the idea. So maybe there’s, if your hypothesis that the canvas is a
foundational type of some kind, as you said, how software is just
starting to be, then maybe there’s a similar explosion that could be
unlocked with the right canvas tool kits.
00:10:52 - Speaker 1: I hope so. I released this thing in November of
2021, so after, I think I started working on it full time in like July,
so not too much time. It got pretty popular, the initial usage.
00:11:07 - Speaker 2: You talking about the open source or because I
know, I guess I should describe that.
00:11:09 - Speaker 1: While I was developing this, I was posting about
it on Twitter a lot. You’re gonna hear me say Twitter a lot, probably
during this interview.
00:11:19 - Speaker 2: I think we could have done a build in public
episode with you if we already did it with the maker of Canopio Club.
Yes, so it’s a similar kind of concept which is showing your work in
progress as you go and obviously it’s a very visual domain and yeah,
people like that. They like those little bite sized pieces and they like
to see the journey.
00:11:39 - Speaker 1: Yeah, I’d started thinking like, this was right
when GitHub sponsors had come up, and I guess the media that I was
consuming was largely like sponsor driven. Podcasts, YouTube channels,
etc. And I was really interested to see if that kind of model could work
for programming. Programming does not lend itself well to YouTube
streams or videos, even like the educational stuff, I think it can work,
but it’s not like a sponsor model that kills, it’s like a course model
or something.
00:12:10 - Speaker 2: Yeah, from what I’ve seen that typically people
who have programming YouTube channels, then you have an upsell into buy
my course, so they put the more basic stuff online, you find it, you
watch it, you get to the end and you like the teacher, quote unquote,
and then you think, well, I want more, I want the intermediate level
stuff, then you go buy their course that’s behind some paywall.
00:12:29 - Speaker 1: Yeah, which is great, and I’ve certainly bought,
you know, courses and books as well, and especially if you have an
education budget, you know, consider spreading that around, don’t let
it go to waste. But I was kind of thinking about the type of content
that I could post every day almost, or the or the type of content that
required like a very low level of engagement with, like, much lower than
by my course, and even like a level of engagement where just clicking
like was like the correct.
Appreciation for this type of content.
You know, I’ve seen folks who are making like really amazing involved
educational material, not just in programming, but in other stuff too,
and it always feels bad where like all I can do is just click a little
heart, you know, it’s like, oh man, like this is worth way more than
that, kind of feels awkward. So anyway, I kind of made user content,
educational content when I worked at a company called Framer. So that
was all very involved as well, very kind of produced.
Took a lot of time to make, and I didn’t want to do that anymore.
So, the kind of the place where I settled in terms of like the kind of
content that I would use to drive interest around Tealro before I had
released it, like, while it was under development, was just like these
eight second gifts. These gifts that maybe had like, you know, were at
150% speed, didn’t take very long to make at all, and certainly didn’t
take very long to consume and just be done with, and, you know, just
clicking that little like button was, what more could you do? Like, it
was perfect.
And so I was posting this a lot as I was working on Tealraw and at the
same time, I had made the like TealDraw.com a kind of sponsorware. So
the only way to access this was to be a GitHub sponsor. And there really
wasn’t any like floor for that. You could give me a $1 and, you know,
have full access. It wasn’t even like a $1 a month. It was just like,
give me something and you can come in. And that worked pretty well. I
got like a couple 100 sponsors, which certainly wasn’t enough for like
a tech salary or anything like that. But it did show that people were
interested in this and it was like a good thing to come back to as I was
developing it. I was also a good motivator for making that content.
00:14:46 - Speaker 2: And to come back to that product manager style
validation, here’s the next step. People parting with money any amount,
the number doesn’t even matter that much, is just such a hugely higher
bar and saying they like it, clicking a like button. Telling you they
think it’s cool, even using it. Parting with your hard earned cash is
just the ultimate measure of validation. So I don’t know if this was
intentional, but it seemed you’re following the product management
playbook kind of market discovery in this journey.
00:15:18 - Speaker 1: It was not very intentional. Again, I was kind of
just playing with this before going to take a job at Adobe, but, you
know, I liked making the content, I liked being able to share this
before it was ready and get that like feedback from people. And I liked
that those people were a little bit motivated as sponsors, and somehow
it just really like ended up in a kind of warm place. It felt like there
were a lot of people on Tal Draw’s side as I was making this and like
wanted to see it do well and wanted to You know, be a part of that. I
spent a lot of time asking folks on Twitter like, how should this
feature work, you know, this, here’s how it works in sketch, here’s
how it works in FIMA, here’s how it works in Miro. What should happen
when you try and resize a group of shapes where one of them is rotated?
I don’t know, like, does it skew? Does it smash? Does it lock the
access or uh aspect ratio and then resize that way, so.
There was a lot of like kind of audience involvement in a sort of a
musical sense.
And yeah, that carried right into the release in November, where I made
everything open source, like overnight. It had previously been closed
source. I’ve removed all the kind of the sponsor walls around
Tealra.com. And just said, like, there you go, release, you know, there
was no product hunt launch. I didn’t post it on hacker news or
anything, but other people did. Enough that I had to ask like product
I’m like, can you just stop posting these? Like, I would love to do a
launch sometime in the future, but I don’t want to do that. And then it
was like at the top of Hacker News for a while, like, for like a
majority of the day, it started. Getting a ton of attention on GitHub,
like in terms of stars and interest from people there.
My Discord started exploding. It was, it was like a really interesting
week as this thing made its way around the internet. And just as like a
free diagramming drawing tool that had I poured a lot of like, I guess,
attention into the microinteractions to sort of add up to a canvas tool.
Yeah, it was fun, and bunch of cool contributions started coming in, and
I was thinking, I don’t know, maybe I don’t go to Adobe, maybe this is
like a good Maybe I can make this into a little microsas product for
myself.
And then what happened was, since it was open source like folks started
building with it and I started seeing a lot of interesting projects that
started being used or built around Tealra and getting some amazing
contributions from people who are kind of using it. And noticing like
where it needed to grow and and how it needed to change, and a ton of
feature requests and suggestions and will it do this, could you make it
do this? Can we contract you to come over and integrate it here or
there? And also interest from like investors and other people who are
kind of working on similar projects, but there weren’t many. It was a
really exciting time.
Eventually, the interest was enough. And I had some conversations with,
I guess people whose advice I could take that this might have legs, this
idea, kind of like this bet that we’re living in a moment where, for
better or for worse, there’s a lot more remote collaboration. People
want to do interaction or like collaboration through software more and
more that needs to happen somewhere.
The canvas is probably the place where that’s gonna happen.
My bet was these apps, there’s just gonna need to be more of them. It
will be impractical for every team that wants to make Miro for project
managers or fig jam for doctors who wanna collaborate on annotating
images, like, it’ll be impractical for every one of those companies to
also build Miro or also build fig jam, which at the moment is sort of,
there are no primitives, so, yeah, good luck. Like if you want to do
that type of software, like your work cut out for you. If you want to do
that kind of software then. Yeah, there’s really nowhere to start
except from scratch. So, there’s Tal Draw the startup, that’s just
Teal Draw the company Teal Draw Inc and TealDraw GB now also.
00:19:28 - Speaker 2: Well, congratulations, and at the moment is this,
the story you told up till that point, it sounded like it was very much
a solo effort doing kind of everything yourself, one man show. Is there
a team now or is that still to come?
00:19:42 - Speaker 1: Yeah, it was pretty much just me, probably like
99% of the code in the project was just written by me over those couple
of months between July and November. I have had amazing contributions
from a lot of people on the GitHub repository. And those continue to
come in, we have a nice little community growing. But yeah, now I have a
team. I’m up to, I just hired my first employee, and I have two other
contractors who are taking up different parts of the project. We’re
growing it, for sure.
00:20:13 - Speaker 2: Oh, congratulations on your new job as a manager,
I guess.
00:20:17 - Speaker 1: Yeah, exactly. I have no experience, but so far so
good.
00:20:22 - Speaker 3: So when you open sourced TLDraw, were you at that
point specifically positioning it as a platform for making verticalized
canvas apps, or was it more open sourcing the app and then people
discovered that you can mod it basically and do their own thing?
00:20:41 - Speaker 1: Yeah, so I had picked a kind of a point to chop
the app into two, in a way. I was saying, OK, here’s a rendering layer.
Here’s a, basically like, put react components on the canvas. I call
that the kind of the core layer. And then on top of that, I built a kind
of an application that would use that core layer, which implemented
things like selection or erasing or different types of shapes. And my
guess was that other teams would want to build on that core layer and
say, OK, well, you know, Tealro’s cool, but we’re gonna make a
different app, so we’re just gonna use the same render, like react
Canvas type of render. Um, I was completely wrong. I think there’s
maybe one team that ended up doing that. Everyone else just forked Teal
Draw.
I picked the wrong place to chop, essentially, that what I thought was
unique to the app, to TealDraw. Ended up being more general than I
thought.
And so things like the selection tool where you, you can whatever hold
shift and click things and now they’re all selected or draw a box in
order to collide things and select them that way. Turns out that’s the
same for every canvas and I just gotten it right and followed all the
conventions that I saw in other apps who had also reimplemented the same
sort of logic and whatever an eraser is an eraser is an eraser like.
So the part of the task, once I did decide to keep going on this was to
basically start over, like within 6 weeks of releasing, I was like, all
right, let’s start over, let’s make this for real. And let’s make
that abstraction point that like, where can I chop this? What can I say
is general versus what is specific to til draw and move that way up so
that it really is, you could get more for free without having to fork
it.
00:22:31 - Speaker 3: That’s interesting and that’s super surprising
to me. I feel like for these complex problems, it’s basically
impossible to design a framework de novo, and people try this all the
time, but it very rarely works. Instead, what happens is you have an
application that works well, and then basically you copy and paste that
2 or 3 times, and then you look at the discs and the things that aren’t
the disks become the framework. And that sounds like it’s basically
what you ended up doing with this.
00:22:55 - Speaker 1: Yeah.
00:22:56 - Speaker 2: I think that was a story with rails as well, where
there was a bit of they kept writing these kind of crud apps with a
model view controller framework, and once they’d done it a few times,
it became pretty clear what should be extracted from that and be common
to all of them and what would be different.
00:23:12 - Speaker 1: Right. Yeah. Well, even though I did pick the
wrong place to chop or the wrong abstraction, it was part of the kind of
the DNA of this project from the beginning to be something that other
people built on.
And so, once it was evident that like folks just were using Tera the
component, which I should say that we did distribute the complete app as
something you could put inside of any website. So it was like also
something that you might like drop into your video chat app, even if you
didn’t want to change how it looked or worked, but you just wanted to
have it somewhere other than TDraw.com.
But yeah, once it became evident that folks wanted to say like, Teal jaw
is perfect. We also want to add like a shape that represents a person.
You know, and that like looks like an avatar and has like that type of
data attached to it. How do we do it? And my only answer was like, smash
that fork button and then own this thing forever, because like, I just,
it’s not built for that, or start from scratch essentially again, like,
maybe not zero, but still very close to it.
So yeah, version 2 is much more kind of Anticipates those kind of
stories, and I had no idea folks would want to do that, but looking
back, I guess, yeah, now it’s obvious.
00:24:30 - Speaker 2: I see that’s where you are today. I’d love to
hear a little bit of the backstory there. You mentioned briefly working
at Framer, which is a very interesting product. It’s been through a lot
of iterations and itself has its own canvas aspect, and I know you’re
actually even relatively new to the programming field, so tell us a
little bit about the journey that brought you to Teal Draw.
00:24:48 - Speaker 1: Yeah, I guess, you know, it seems like everyone I
talked to has a non-traditional story about how they got into this kind
of tech field.
For me, I studied art. I studied, uh, you know, painting for undergrad
and then grad at University of Chicago. So I had a tiny bit of like
technical experience building like portfolio websites, but that was
pretty much it. It wasn’t until I had turned 30, I was now living in
Cambridge in England.
Kind of broke, realizing I should probably make some money in my life
and have a career that has a little bit more speed to it. So, yeah, I
kind of shut down my studio out out near Cambridge and started looking
at different ways of using that same creativity and I guess industry, I
suppose.
So I started out in design, and then I quickly learned about like
prototyping as a place where the tiny little seed kernel of technical
skills that I had had from all those WordPress sites that I’d in the
Bush administration could be brought over and applied.
This was also like 2017, the idea of like designer who codes was like,
even for someone just crashing into the tech scene like was very
evidently like hot and so that essentially became my brand or my story
as I came in. I was an extremely active user of Framer’s first product,
the Framer, now Classic. So typing out coffee script code and making
things spin around when you click at them.
And my first couple of jobs here in London were essentially, yeah, like
prototyping. Like I was brought in because one way or another, they
wanted to be able to build something before they actually brought
engineers on to build it. And so this Kind of approach to design and
approach to programming of like discovery mode of like, well, we’re not
even sure what this needs to be, but let’s start hacking something
together. Yeah, that was essentially what I have been doing my whole
career and still what I’m doing now.
Ended up working for Framer doing their education, which was an
interesting break from actually like shipping designs or shipping
prototypes and instead trying to figure out. How do I talk to people
about this, or how do I show how to do this type of work? And instead,
like, how do I present this to other people? How do I communicate, like,
what makes a good prototype? How do you go about that and specifically
how do you do that with Framer.
I wasn’t so good at that job. And so afterwards I went back into design
and prototyping for a company called Play who’s making a design tool,
another design tool for iOS, which surprisingly like, you wouldn’t
think that a design tool fits on a phone or on an iPad, but it does.
It’s a pretty cool one to check out if you haven’t.
That was a fun opportunity to kind of rethink all of the creative
software experience. As a designer, you kind of can’t help but think
about the tools that you use because of their software too, and you’re
designing software. Play was like an extreme example of being able to
rethink features like a layers list or an objects list that haven’t
changed since. I don’t know, Adobe Illustrator, and say like, OK, well,
how do you do that on the phone? How do you do a properties panel when
there’s, you know, the size of an iPhone to work with? That was a blast
for me, and it was during that contract when I started doing the open
source work around arrows and around a perfect freehand, and then
eventually healra too. So, that’s sort of the abridged version of my
kind of path from Design and technical design, or increasingly kind of
technical aspects of design until now I’m, I guess, not too far away,
but they definitely do more programming than design and now managing
too, it’s fun.
00:28:49 - Speaker 2: Not to mention it seems like there’s an evolution
there from prototypes which are by nature or even by definition
throwaway, and then going to something that’s an open source library,
other people are building on it, you need API stability. There’s going
to be, I mean, so far the project’s pretty new, but you need long term,
it’s quite the opposite of that prototyping, so I imagine you’re
growing new skills there too as well.
00:29:12 - Speaker 1: Yeah, to be honest, this is also a place where I
think the team that I’m building is gonna Do a lot of the heavy lifting
because my relationship to software is still very like disposable, kind
of like crumple up and and throw in the trash, just do lots and lots and
lots of sketches until it resembles what you want. Not to say that Tilra
isn’t like solidly built and, you know, we’ve fixed the bugs and it it
has good abstractions and solid API and all that. But yeah, definitely
there are certain problems that you can’t quite as easily start over
with. So, I will be slightly hands off on the on those problems just
because different skill set for sure.
But the community side of things, I mean, managing not only the open
source, like an engineering project, but also as a community project has
been really interesting too. That’s probably closer to the work that I
was doing at Framer in terms of education and doing a lot of work with
the community and a lot of work on Twitter and uh chats and such of kind
of unblocking people as they’ve been working with at that time, Framer
now and with Tealro turned out to be decent training for those sort of
Open source relations manager, open source project, open source
maintainer, culture or role. Luckily we haven’t had any drama with
Tera, but it’s still a little bit chaotic and fun.
00:30:36 - Speaker 2: So our topic today is infinite canvas or perhaps
infinite canvases.
So I think we’ve explored this a little bit already in talking about in
this new world of kind of, yeah, the whiteboard brought into a digital
space and made collaborative and that is increasingly feels like a
foundational piece of many pieces of software.
So yeah, I’d be curious to, you know, kind of go to the fundamentals
here, which is certainly how you Steve or Mark how you define. What is
an infinite canvas, and then we should probably also talk about the
name, cause that’s an interesting thing. But let’s start with
definition. Steve, what do you makes one of these canvases what it is
and different from other types of software?
00:31:15 - Speaker 1: Yeah, well, especially on the web, we are used to
a kind of a document metaphor that, well, the web is just built for,
which is kind of a vertically scrolling infinite page. Infinite canvases
are essentially like a different document format. This idea that there
are two dimensions or kind of almost 3, you know, you can move left, you
can move right, you can move up, down, you can zoom in and out, and that
the screen, what you’re looking at kind of represents a camera that’s
kind of floating above a surface, and there are things on that surface.
And those things can be anything. And in a drawing app, those things
might be little lines that you’ve drawn in a visual note taking app or
canvas-based note taking app, those would be different notes or
different headers or different flags or in a whiteboard, they might
include arrows and texts and sticky notes and all that.
The actual things on the canvas don’t matter. It’s mostly about Stuff
on the canvas that you can view, or if you’re able to, if you have the
correct permissions, then you’re able to directly manipulate.
You can drag things around, you can move them, you can duplicate them or
resize them, and that each one of these types of thing on the canvas
also sort of has its own rules about how it can be changed. So maybe
it’s a video, maybe the aspect ratio of that video can’t change, even
though you can’t change the size. Whereas maybe it’s like a rectangle
and you can change that aspect ratio or the sizes.
And whatever you wanna call these things on the canvas like shapes or
primitives or elements, the thing that you do with an infinite canvas
is, you know, to manage these and read them or arrange them or put the
canvas into a state where it represents something.
So, obviously, again, like whiteboards are pretty clear, like you wanna
do a retro and you’re moving sticky notes around, and maybe voting by
stamping things. And the important thing also is that, unlike a document
where you’re only seeing a very small part of infinitely scrolling
page.
The canvas works really, really well for collaboration. The idea of
having multiple people working on the same surface is pretty natural.
You just represent them by their cursor, wherever the cursor is, that’s
where they are. Um, you can do things like follow people around. I
suppose you could do that on a vertically scrolling page, but it might
not be as fun. Yeah, so that’s why I think it’s been picked up so
readily by, again, like whiteboarding or diagramming or or places where
you need to have more than one person editing the same document. It’s
not like something with text where, as I’m editing text at the top of
the document, all the other text is being pushed down the document.
00:34:00 - Speaker 2: The elements are relatively independent of each
other. Yeah.
00:34:03 - Speaker 1: Yeah, exactly. You know, you can have independent
experiences on the same document that are just in different places.
And I suppose the idea of place is also a big part of this, and
potentially a big part of this.
The idea of near and far, of close and distance, or like it quickly
drifts into like video game territory of your cursor is your avatar, or
maybe you have an avatar and you’re moving that avatar around this top
down view of an office or a space and jumping into video calls with
people close to you. So yeah, that infinite canvas, that’s kind of a
long definition of how I see it. It’s just a found an infinite 2D plane
and you are a little camera represented by a cursor. Moving around,
moving over that surface. Mark, what do you think?
00:34:52 - Speaker 3: Yeah, I have a pretty similar take. I’ve often
called these multimedia canvases, cause I think there are two dimensions
going on.
So one is the canvasness, which is at least 2, sometimes 3 dimensions
and the freedom and flexibility to place content items wherever you
want, like you were saying with relative independence.
The second axis is multimedia, so Which types of media the digital
document accommodates.
When you lay it out like this, it’s interesting because this actually
captures the whole universe of digital document editors.
So for example, a classic plain text editor is at the sort of bottom
left of this graph where it’s very limited to one content type and
it’s very linear, a spreadsheet in contrast. Has pretty limited content
types. It’s basically text and numbers, maybe a little bit of color,
but it’s quite high on the canvasness.
You have this flexibility and freedom to place things and by the way, as
we’ve talked about in this podcast, that’s something people love about
spreadsheets. It’s not just a calculator, it’s just a place where you
can put stuff, people like that.
Then you can go all the way out to the top right where I would put like
muse and TL draw where you have a full 2D canvas and it’s highly
multimedia. You have handwriting, text, images, videos, links,
whatever.
Or you could kind of go back down and say we want lots of different
media types, but we don’t have the full flexibility. So I would put
notion in this category, for example, of you basically have whatever
media type you want, and there’s, there’s a little bit of flexibility,
but it’s pretty much a linearized document.
So in this view, the multimedia canvas is simply the fully generalized
final form of a digital document.
00:36:38 - Speaker 1: It’s good to be here at the end, yeah.
00:36:40 - Speaker 3: And all the others are sort of specializations of
that space.
00:36:45 - Speaker 2: One element you touched on there, Steve, which
also I think fits in with the multimedia side as well as you talked
about the elements, you know, we call them cards and news just because I
think that works for us visually and particularly with the touch screen.
It feels like an index card moving around on a desk or something, but
yeah, the elements have a certain sameness and I think this does go back
to Illustrator, which in many ways was the original Infinite canvas to
my mind, but you know, maybe sketch and. FigMA and Framer kind of
modernized that a little bit, but when you lay down a bit of text or add
an image or add a rectangle in, for example, sketch, you can click on
and select each one of them. You resize them the same way as you said
there might be slightly different rules around resizing.
There may be snapping or other things, but in the end, You can do the
same things with all of them, and I think that’s really important and
it’s actually something that to me comes actually from file systems.
This is what’s great about files. It doesn’t matter what’s in the
file. You can always delete it the same way. You can copy it the same
way. You can put it in a folder the same way, you know, inspected size,
that sort of thing. There’s this uniform container. And then over the
years, files have gotten more capable and contained more and more
different types of things, including, you know, things like video that
the original creators of the file system probably couldn’t have even
pictured being possible on a computer, but because it’s this general
purpose container and as a user, I feel that gives me a lot of agency
and power because even if I don’t know the specific type, I know
exactly how to manipulate it.
00:38:16 - Speaker 3: This is reminding me that there’s potentially
some secondary axis here. So one is collaboration, which we’ve
mentioned, and we almost take that for granted now when we think about
modern software, but you know that is a separable axis. The other is
this notion of inline editing, which I think is actually pretty
essential to what we think of as a modern multimedia canvas app, in
contrast, you know, with the typical file manager like Finder, that’s
actually very high on multimedia and quite high on. 2D flexibility,
especially on your desktop, but you don’t have the inline editing, so
it it feels like a totally different experience.
00:38:50 - Speaker 1: Yeah, this ability to not only move, delete,
organize, copy, hold alt to clone, to directly manipulate content, but
also It’s not only about making choices about where a thing is, or its
relationship to other things, but it’s the place also to make stuff and
to edit it directly.
And yeah, one of the bigger kind of challenges with tealra was deciding
how to allow interactions within shapes versus interactions with
shapes.
So, for example, you have a video, you can click on the video and drag
it around. But you might also want to like pause the video or change the
time of the video, and thinking about, OK, well, how do you transition
from a shape that is, I call them shapes, whatever tail drops I’m gonna
keep using that word, too hard to deprogram a shape that is Acting like
a shape versus in a shape that is acting like a video, and that you can
interact with with like a video.
And yeah, it turns out that there’s a pretty good rules around that,
like how to make it consistent, which works just as well for like text
as it does for videos, as it does for, I think I have a code sandbox,
you know, running on the canvas and teal draw in one of my example
projects. The joy of using a kind of a web-based canvas of rendering
stuff using the web, although that sounds like such a bad idea to render
things in HTML and CSS, but it really does give you the ability to just
put anything that can be in a browser on the canvas and interact with
it.
00:40:29 - Speaker 3: And this also brings us to the why now and why is
this hard. Like if this is the fully generalized form of digital
documents, why didn’t software start this way? I think a big part of it
is just that it’s hard. Like we talked about how it’s hard to write a
text editor, but what if you now need to write a text editor, an image
editor, a video editor, and audio editor, and they all need to be in the
same thing, you know, it’s, it’s quite difficult.
And then on top of that, you got to actually render all the stuff and
make it manipulable and fast and responsive. It’s just quite difficult.
I think that’s a big reason why.
We haven’t seen it until relatively recently.
I also think there is an element of people just, they don’t fully
realize the expansive possibilities of the software, perhaps when
they’re starting from a very limited. World.
But OK, I constantly bring up this analogy of like a woodworking shop.
Could you imagine if you had like a woodworking district and you had a
shop just for like your chisel work and then a shop for your saw work
and then a shop for your standing work and like you had to take this,
you know, quote unquote file of a project and bringing it across to
these different buildings. That’s kind of the world that we live in
now, and you can’t even look at two things at the same time, like
you’re standing and your chiseling work. That’s kind of the world that
we’ve been living in with respect to software for a long time. And
yeah, it takes some work to bring all those things into one. Workshop
and to learn all the tools and to keep them all maintained and stuff,
but that’s what you really want as a creator.
00:41:43 - Speaker 1: Yeah, especially in the browser, it’s like. Every
10 years, I’m told that you just have to forget what you knew about
like what you can do and what you can’t do just because it just gets
that much better.
Certainly when I was Poking around with WordPress websites in college,
the web was not a place where you could make a kind of a dumb driven
canvas and make it like fast and good and perform it and do all the
things that you need to do with pressure and multi-touch and all that.
But it is possible today, and I think that when a platform is mature
enough, you know, for you to have like an anything app, kind of a place
where you can just put anything. OK, cool. Videos, yeah, put it there.
Text, we’ll put it there. And that’s always sort of been the promise
of the browser. It’s just been really constrained to this document
format that is increasingly showing its limits.
I think one of the newer APIs that I was looking at from Google, you
know, involved like transitions, like kind of iOS style transitions
between things, you know, that absolutely explodes the notion of the web
page as a page and hopefully Tera also kind of demonstrates that this
technology could be used.
By the way, like, the idea of a rack driven canvas, not to keep coming
back to framer, but That’s where I saw that this was possible because
their, their canvas is driven by react and is driven by the dumb and
like surprised me with the fact that it worked and that it could be made
secure and all that. So, I don’t think I would have come up with this
project without having seen it been done by people more capable than me
than considered that as a possibility. It’s like, hey man, you could
put anything on here. Like, why aren’t we?
00:43:26 - Speaker 3: This was an important data point for me in
believing 4 or 5 years ago that these multimedia canvases were going to
be really important because anywhere you had anything that was like
multimedia canvas, if you squint, people loved it and they were using it
for all kinds of stuff. I mentioned the example of spreadsheets. Another
example is using tools like PowerPoint or drawing programs to do like
whiteboarding basically. We’ve also seen this more recently with FigMA.
FIMA is obviously a design tool, but people will use it for a personal
note taking just because they really like the ability to put different
stuff on a canvas.
00:43:56 - Speaker 1: Yeah, I think one of my first creative software
experiences was with Hypercard, way back in the day. I think it was
still Hypercard, like Apple Hypercard or not macromedia or Flash or
anything like that, but yeah, there’s this idea of like, that is not an
infinite canvas, that’s just a glorified slideshow.
But it’s still like I’m like, man, you can make games with this, you
can make presentations for this, you can make You know, animations, if
you just click next fast enough.
Yeah, um. A little bit of Like giving users a little bit of room to run,
you know, it’s always like the best, just because, yeah, suddenly you
have Doom running in Microsoft Excel.
Yeah, and I think with TLDraw, I mean, folks have made a slideshow app,
like a slide editor app with TLDraw, which apparently didn’t take too
much work cause it already had like pages and you’re just have a UI for
moving between pages and I’ve seen it used to do video annotation, like
you pause a video at a certain time and just overlay like teal draw and
be able to edit, like, you know, this guy’s gonna run over here or
whatever, and it’s been used for like wikis.
One of my favorite stories about this actually is that there are two
products that compete with each other. They’re both for Dungeons and
Dragons game masters or Dungeon masters. And when you’re telling or
running like a story campaign or a story world game, you have a bunch of
locations and people and, you know, items and all this stuff and they
might have relationships to each other, etc. And so there are two pieces
of software, one is called WorldAnvil, one is called Legend Keeper, and
they both are essentially wikis, custom wikis for people who are running
these games. And Legend Keeper shipped a whiteboard view of their like
wiki, essentially. Based on TalDraw, like 6 weeks after I shipped
TealDraw, like open source it, like immediately, they seemed to be like
immediately, oh cool, this thing that we wanted to do for like 2 years,
like, let’s just do it. Like we could just nail this, and they did. And
then about 6 months later, World Envil released their canvas, their
whiteboard view of their wiki, which was also based on Tealra. And I had
been, I’d been telling people I’m like, someday there’s gonna be a
product. Or two products that are competing with each other, similar
features, and the thing that they’re not gonna be competing over is
like how well the eraser works or how well the select tool works.
They’re gonna be competing at that higher level of, yeah, like the
features that they built that are unique to their products because both
of them are gonna be using TealDraw. And then it happened 6 months in,
it happened that I was like able to point to both of them and I love
that. They’re both wonderful products and then their communities are
always posting. Like I kind of lurk on their Discord channels just to
see people’s like whiteboards, and yeah, it’s like 200 individual
characters, you know, in a big family tree structure or like alliances
between things. Yeah, definitely not what I expected when I was working
on Tealdrop, but that’s the whole point, right? It’s like to see where
people take it.
00:47:06 - Speaker 2: That’s great and I like the Dungeon master and
world building aspect. We have some new customers who do a similar thing
for their sort of dungeon mastering, but it is in a way the purest form
of knowledge management.
Yeah, you have this complex world, you need to keep track of stories,
characters, yes, it’s all made up.
There’s a version of this for sort of fictional worlds as well, right?
Like, yeah, if you work on some franchise like Star Trek or whatever. to
keep some shared knowledge base of all the canonical everything that has
ever happened, timeline and characters and rules for the universe and
things like that, but yes, it is a mix of obviously textual, kind of
more linked wiki knowledge graph style stuff.
But obviously diagrams, maps, drawings, all of that can and should be a
part of it, but traditionally the digital tools that we use tend much,
much more towards those that text and that linear top to bottom
document, and it’s not even top to bottom, it’s really about the
inline. It’s about the text that flows left to right and it wraps when
it hits the edge of the screen and it keeps going down until you get to
the bottom and any multi.
The media you add tends to kind of float awkwardly as sort of a big
character or something, but I think when you look at something like the
Dungeon Master use case which so purely and in this made up realm
captures the complexity of what you can do with computers in terms of
tracking knowledge and what you might want to do, and quickly you see
that text is a big part of the story, but it’s not the only part.
00:48:38 - Speaker 3: Yeah, and I think related to this idea of
constrictive media types and layouts is the notion of premeditated
workflows versus totally in the control of the user workflows.
So typically with software, you have workflows that are Designed by a
product manager or whatever, and they write down the software and
that’s that. So you can imagine for world building, you have a database
table that’s like characters and database table that’s equipment and
you know, if you have something that doesn’t have a common database,
well too bad, you know, email the product manager maybe able to add it
in a year.
But people really like the ability to craft the software to their use
cases and motivations. I think this is a big draw of The multimedia
canvas, you can just do whatever you want with it.
You know, if you have a different way that you think about equipment or
characters or whatever, you just put it on the canvas and and do
whatever you want.
And I think that’s an important aspect.
But the other thing here is you can go down a layer and change the
actual programming, which is one of the things that sounds like it is
really exciting with TLDraw. And again, people, when they just give them
a little kernel of power and capability and you meet that. With some
motivation, people do all kinds of stuff. I’m reminded of the Half-Life
game engine. I don’t know if you guys know the story, but the game
itself was great. It was very successful. But this game engine spawned
off all kinds of stuff, you know, that critically, the original creators
did not anticipate, design, approve, or even know about, right? Just
someone else, they took this kernel of power and made something new. I
think that flow was so great.
00:50:05 - Speaker 1: Yeah, absolutely. One of the opportunities of
having like a multimedia canvas is the ability to extend it
semantically, almost, and you see some of this discourse around like the
idea of notion-based editors, block-based editors, right? Is that like
text is a primitive, images are primitive, but you start to kind of wrap
these things up into more specific domain specific or just project
specific and more meaningful blocks, right? And those things can
interact in ways that maybe have to do with like what they are. So in
the kind of the Dungeon Master example with something like Legend
Keeper, the things on the canvas that they added were parts of your wiki
that you can put on the canvas. And so the character on the canvas, you
know, you can drag out a character from your wiki and put it on the
canvas, is not just an image of that character, but it’s sort of is a
representation of it. And It could be that dragging a character onto
another character might produce a different outcome, might suggest a
different user intent than dragging a character onto a location, right?
Now suddenly you’re able to extend this surface metaphor into something
where those same basic interactions, those same basic direct
manipulation actions can be like meaningful in a way and produce
different outcomes based on what you’re working with. Um, it’s not
just text, it’s not just images. Now, we have people, we have places,
we have things, and they might have their own rules around them.
00:51:34 - Speaker 3: Yeah, I think this idea of extending the content
types in the canvas is super cool. We explored this a little bit back in
the day with the prototypes that led to Muse in the Ink & Switch
research lab, and I remember a couple that were really fun.
One was a person. Which is represented as like an avatar and a name, but
it was so useful to be able to have someone on the board and put them
next to tasks or put people in a group, or, you know, put your current
work under your picture. It’s like a great primitive, in other words,
maps and locations, something that actually people use all the time for
planning purposes.
But I think there’s an important sell to here around extensibility. So
there’s one thing you could do, which is draw out the notion of a box
and say, we as the creators of this program could put different things
in this box, you know, notion could put different things in their block
abstraction. And just that is useful because then you can manipulate
these in standard ways and link to them and so on. But then users being
able to extend it is so fun and powerful. I remember with our
prototypes, because this was back when we were doing the prototypes in
JavaScript and people could just kind of write the stuff like a react
component. And it was people were so excited to be able to write their
own things, you know, things that were too specific and niche for the
central, you know, controllers of the framework to ever worry about or
even think of, but people felt so empowered to write their own
components. This brings me to a problem that we’ve been noodling on for
several years and and to my mind it’s still a critical open question.
So when you’re trying to build these end user extensible digital
document systems, there’s a few deerrata that you want. OK, you want it
to be very fast, you want it to be safe in the sense of end users
aren’t gonna be injecting wild stuff, you know, and other users’ data
or something. You want it to be approachable cause you want end users to
be able to actually use this thing. You don’t want to give them some
like, you know, assemble or guide and say go have fun. And ideally, I
think you want the extensions to not feel like a totally different
world, like some limited, slower, neutered, you know, subset of the
platform. You really want to feel like the extensions and the platform
itself are like written in the same way. And in fact, if an extension
does well, it can be promoted into the platform. Or if a piece of the
platform is, you know, not finding a lot of use that can be sliced off
as an extension. And I just think it’s very hard to get all these
things at the same time and it’s not clear to me how you do it. So for
example, C++ can be very fast and It can be safe. Maybe Rust would be a
better example of something that’s very fast and safe. But then telling
end users to write their components in Rust, that’s a little bit harsh.
And JavaScript in our experience can be very approachable, it’s very
flexible, but it can be very hard to make fast, especially at the 120
FPS level that we’re targeting from use. So I’m just kind of curious
if they that problem statement kind of resonates with you, and if so,
how you’ve been approaching that.
00:54:25 - Speaker 1: Yeah, I think that’s a really good summary of the
problem of extensions.
Um, which some of that is gonna be true for any products, right? Like
it’s true for a text editor as for a video conferencing infrastructure.
I don’t know, whatever.
In the case of Tealra. I’ve addressed this in kind of three design
decisions. One is to use React for the canvas again, because I think the
development story there makes up for the performance story. And the
performance story is pretty good. It’s never gonna be as good as
something like custom webGL canvas that was written in a systems
language, right? That’s not gonna be possible. But on the other hand,
uh, you can put things in there that you just can’t put in anything
else. You can put a mapbox map or you could put a, you know, YouTube
video, like as we’ve talked about, and you can do that, you can offer
those things fairly easily. So, in the case of Tealra, all the shapes
that you and I’m kind of referencing this next version that’s gonna be
launching soon, all the shapes that you see. When you look at teardrop
when it loads up, those are essentially extensions. Those are all
custom. We wrote the user facing app kind of at that same level as you
would write your custom plug-ins and your custom things. And I was
pretty good about not cheating, and of course it’s easy cause we can
change that lower level, you know, that core level in order to
facilitate things that don’t work yet, but um all the shapes are custom
shapes or plug-ins. And then the shapes themselves, these sort of like
plug-in shapes. are all based on like uh primitives that the lower
levels do share. So, for example, you have something like a box, right?
A box rotates in a certain way, it resizes in a certain way, it hit
tests against like points and lines in a certain way, and all of those
things are different than if it was like a pencil shape, like a drawn
line. All those answers are different. However, they’re all the same.
Every box is gonna hit test pretty much the same way as every other box.
Every line is gonna hit test the same way as every other line. So when
you’re creating these custom shapes, when you’re creating these
extensions, you’re able to just sort of inherit all that functionality
from kind of the base, right? You say this is a box, all right, job
done. This is its model. It has a width and height just like a normal
box, but it also has a latitude, longitude and a camera zoom. And then
the next question is like, well, what does it look like? And you say,
well, it looks like a map box component, and it uses that data from the
model, and that’s pretty much all the code you have to write, because
all the other parts of that box in terms of its behavior and such are
just their default, right? If you wanted to make something crazy and
unique or if you wanted to make something that was very different than
all of the primitives that we do share, things like whatever boxes,
lines, polygons. Then you can also access those same primitives, those
like lower level primitives to say, OK, well, here’s my squiggle. It
has 3 ups and downs. Here’s it’s like outline that you can use for hit
testing, and here’s how it resizes and all that. But most of the time,
the custom shapes that we’ve written are just boxes, mostly just boxes
with react components inside of them. So that’s the authoring
experience, or the like developing story there, which itself is a
developing story as we try and push like what you can do with these type
of shapes. Then separately, it’s like, how do you do that, especially
in a multiplayer situation, how do you allow multiple people to be using
their own custom shapes, especially if they’re sort of end user
credable. At the moment, the answer is, well, you don’t. The way that
I’m thinking about this is deferring to sort of the implementer level,
is that TealDraw as a SAS product might someday have its own extension
markets like you might find in Figma where you can download stuff. But
in the short term, this is primarily infrastructure tool for other teams
to create apps with. Those folks would be the ones defining, you know,
OK, well, here’s my person place thing shape. Those folks would be also
guaranteeing that everyone who’s using the app has access to those same
shapes. And so it wouldn’t really be like end user developer who’s
making those extensions.
00:58:38 - Speaker 3: Yeah, so each instance of the TLDraw derived app
chooses its extension ecosystem and curates those and makes sure that
they’re safe, and it’s not every individual Joe, you know, injecting
JavaScript into everyone else’s computer.
00:58:52 - Speaker 1: Yeah, exactly. There might be a future where we
want to solve those types of problems or like create those types of
marketplaces. And there are a ton of interesting questions about like,
well, how do you distribute those shapes in like a multiplayer situation
with people who haven’t installed the plug-in. What happens if you copy
your squiggle shape from one project into a different project that
doesn’t have that squiggle shape? Those are all questions for later
down the road. I think the primary thing that I’m going for with this
version is just giving other developers the tools that they need in
order to build the experience that they want for their users to have
that involves this sort of canvas.
00:59:27 - Speaker 3: Yeah, and I think that’s a very reasonable and
practical set of trade-offs, you know, react, curated by the instance,
makes a lot of sense. It is fun to think about the fully general world.
00:59:37 - Speaker 1: Oh, totally, yeah.
00:59:39 - Speaker 3: Of arbitrary extensions.
00:59:40 - Speaker 1: I’ll get there eventually. There’ll be some cool
streaming JavaScript modules, you know, that are pulled in at runtime in
order to, you know, we’ll get there, don’t worry. happy not to be
thinking about that yet.
00:59:52 - Speaker 2: I think of the time, certainly.
00:59:54 - Speaker 3: And your experience with React is that it’s fast
enough. My recollection, so this was a few years ago, but my
recollection was that React or React like systems on the web for this
canvas use case was Not fast enough.
01:00:09 - Speaker 3: More like was very close. It was right on the line
in the sense that if you kind of did anything weird or made a little
performance mistake, it’s very easy to throw the flags, not meeting
even 60 FPS. I don’t think we ever could try to get to 120 FPS because
the browsers on the iPads don’t support 120 FPS as far as I know.
01:00:34 - Speaker 1: Yeah, that’s true, that’s true, but it’s like
plausible for 60.
01:00:37 - Speaker 1: Yeah, I think Chrome goes up to 120, and I mean
you could try out on Teal Draw, even though the current Tealraw.com is
sort of the first version, and that has only like a little bit of the
optimizations that we’ve since done with the next version. It’s
primarily a memory management issue because those big garbage collects
is what gets you. And it’s also about having a lot of control over what
is rendering, of course, what should react, recognized as a render. And
then managing paint.
Paint is a big thing with canvases also, which the browser can do a lot
on its own, and there are some CSS optimizations that you can really
push the rendering engine to do as little as possible and to only do it
when you want to do it.
01:01:21 - Speaker 3: The memories are starting to come back. I’m
recalling, if you use certain CSS incantations, it invalidates a whole
suite of repaint optimizations, so you get totally hosed, so you got
like, you know, the specific CSS, you know, magic words to say and to
avoid.
01:01:36 - Speaker 1: Yes. And they’re not all the same between
browsers either. Those magic words, for example, like uh just as a quick
example, I think in Chrome. They perform their transform operations,
they scale, and then they translate or something. They scale last,
essentially. In Safari, they scale first, or maybe it’s the other way
around. No, no, Chrome, they scale first, Safari they scale last. So
essentially that if you do some of these optimizations that sort of skip
the paint and say like, don’t repaint that, you’ve already repainted
it. Suddenly everything’s blurry if you’re zoomed in because they’ve
scaled it second. Yeah.
01:02:14 - Speaker 3: Another way to articulate this might be the react
model in the abstract. If it correctly maps down to GPU operations, is,
it’s great and it’s totally suitable.
And the challenge is Getting that mapping to happen correctly through
your use of react and CSS incantations and so on. It’s a little bit
subtle because that’s a little bit of a black box, you know, there’s
several layers there, and like I said, if you make a mistake, you end up
repainting the whole screen and you’re out of luck.
I also think just taking a step back from the very down in the weeds
implementation details, there is a challenge with canvases and the react
style cause it’s less obvious, I think, what needs to be recalculated.
So in a traditional document. You have just take a very simple case,
like you have a sequence of rectangles that gets rendered, and when you
change, you know, a div, for example, you need to re-render the div and
then put that back in the tree, but you kind of know that the rest of
the stuff hasn’t changed, at least in a simple case.
Right, because it’s a series of non-overlapping rectangles.
But when you have cards on a canvas, for example, there’s all these
implications around, you know, intersections and hit testing and
overlapping, and that’s just for rectangular cards, you know, add ink
and erasers and it’s a whole other thing. So, I’m just kind of
recalling a few years ago, the challenges that we faced with using the
reactor model on a canvas. It’s not easy.
01:03:31 - Speaker 1: It’s not easy. Having done it a couple of times
and having kind of rebuilt that engine, that rendering layer a couple of
times.
One of the tricks was to keep it as flat as possible. So, for example,
HTML allows elements to be placed inside of other elements, and they’re
all can be positioned relative to one another.
Don’t do that. If you’re if you’re building a canvas, you want to be
managing those positions yourself, and you want it to not be pushing
that type of change through React, right? So, if a shape has two shapes
as its children, even though those shapes are being positioned relative
to the parents, and if you move the parent around, that the children
move around too, in the react model, those are siblings. They have
transforms that are being recalculated automatically based on their
dependent data, which is like the parents transform.
And so that takes a little bit of the lifting off of React, to say like,
don’t worry, the thing that you are gonna take care of, we will take
care of, and then to use a ton of essentially observables in order to
kind of Take the wheel in terms of the data. So, You know, nothing has
props, like, OK, that’s too much work for React to do. We’ll take care
of it using observables and we’ll update things when they need to
update. So, there is a lot going on in Tealraw where like, I think we
had someone on the Discord being like, hey, I’m kind of new to React,
and this looks like a really fun project, and I’m like, this is the
wrong project for someone who’s new to react because we’re actively
short circuiting like a bunch of the things that React normally does in
order to be fast. In this type of an app instead.
01:05:11 - Speaker 3: And I would imagine that the programming within a
component looks more standard. It’s like a sort of regular, but then
what you basically want is you want react to render each card, and then
to take all of those and give them to the GPU to composite because that
can be done super fast. So as long as you don’t ask, you know, react to
the equivalent to like recalculate and re-render this whole tree instead
of just making individual cards you can posit down, it should be pretty
good.
01:05:39 - Speaker 1: Yeah, and that’s pretty much a summary of like
what how we do it is that if nothing’s changing with relation to with a
card shape element, we almost want it to be treated as a texture.
In fact, we do want it to be treated as a texture. Don’t think about
it, don’t re-render it, don’t repaint it. But then, you know, you have
something like someone zooms in and suddenly you have to repaint
everything and have to, but at least you don’t have to re-render it.
You just have to, you know, repaint it. And there’s a lot of these days
you can use CSS to avoid a certain type of data flow that otherwise
would have had to be pushed into all those components. So, for example,
maybe it’s the width of the Indicator, when you’re like hovering over
something, right? You want that width of that indicator to be based on
the zoom, so that it’s always exactly one pixel on the screen. And if
you’re zooming in, then you’re actually scaling this canvas using CSS,
but you don’t want that line to also scale. You want it to like counter
scale it against that, right? In the past, you would have had to push
that zoom level down into that box component and say like, OK, well, now
the zoom has changed this, you need to adjust the width of your
whatever. No longer the case, you can use CSS variables and calculations
and such in order to get around that. And so now suddenly, you are still
pushing the data around, but it’s happening in CSS rather than in
JavaScript land, and so that’s a whole class of things that no longer
has to Deal with, did my data change or whatever. And so, especially the
things that happen like moment to moment, like dragging interactions,
like selection and hovering and all that, I try really really hard to at
least keep those things isolated, if I can’t keep it out of JavaScript
completely. Yeah, I’ll probably end up having to hire like a X Mozilla
browser CSS Wizard to optimize all the all the browser stuff because it
is like, we’re not writing a render, we’re not writing a systems level
like WebGL render. Instead, the browser is our render and so we need to
have as much knowledge about how that thing works as we would if we were
working with a lower level architecture. So, if you’re interested in
that, My email address is [email protected] and uh get at me. I’d love
to chat.
01:08:04 - Speaker 2: If I can transition us out of the technical deep
dive, one thing I’d be curious to get both your take on before we start
winding to a close is the name infinite canvas, whether that’s a
category or a component, and it’s one that I have some mixed feelings
about, because on one hand, Mark uses the term multimedia canvas more
commonly we called Muse a spatial canvas and kind of our 1.0
positioning.
And I also like the term open canvas, we actually do use that a bit on
our website talking about kind of the interaction model, I guess, or the
idea that it’s more about the flexibility and the fluidity rather than
kind of infinite sounds more like how big it is.
But one thing that I did learn is that that name actually already has a
lot of traction, if that’s the right word for it.
We get lots of reviews on the App Store, people tend to just organically
reach for that term they have since the beginning, and furthermore, that
even experimenting with App Store search ads, I discovered that actually
infinite canvas is a very frequently searched term.
I’ve learned over the years in trying to define new spaces for software
and technology that some name that just seems to stick with people,
whether it’s Tool for Thought or Infinite canvas or something else,
it’s sort of like not worth your while to fight it, so I’ve got my
quibbles with it. I’m not sure it’s the best name or the one that I
would pick, but it does seem to be the one that has some legs. I’m
curious how you both see that.
01:09:34 - Speaker 1: Yeah, not to mention that in the browser, we have
something called Canvas, which is a specific technology which is images,
offering images through JavaScript and like tealras as we talked about,
it’s like emphatically not that. And so I’m always presenting it as
like, it’s an infinite canvas that’s not using Canvas like and it’s
immediately I’ve, I’ve gone overboard.
01:09:55 - Speaker 2: I mean, canvas is just a lovely word, right?
01:09:57 - Speaker 1: So, yeah, of course. And I like the potential for
infinite to not only imply.
01:10:10 - Speaker 2: How big it is, but also like what you can do with
it, or like, that it has that other sort of depth, but yeah,
possibilities, which definitely that interpretation is less, how big is
it or can you zoom in an infinite amount, but more about that it has a
lot of possibilities, you can put anything on it, you have a lot of
freedom in how you manipulate it.
01:10:24 - Speaker 3: Yeah, I think about it very similarly where,
again, to me, the important parts are the freedom and the flexibility
and openness, so I might use freeform canvas, but also to me canvas kind
of implies free form, you know, it’s a blank cheat and do whatever you
want it’s kind of the whole point. So that’s why I often use
multimedia Canvas, but I also agree that it’s probably not worth
fighting too hard, you know, if everyone’s already using those words,
just say it back at them.
01:10:50 - Speaker 1: Yeah, I would be curious to look at that data
about what other, what other terms those people are looking for, because
the other risk with canvas is, and again, not made any easier by the
fact that I picked a name that has draw in it, but that like canvas is
associated with like a drawing or painting kind of like context. And so
I’d be curious if folks that you’ve seen were searching for like
infinite canvas, plus art, plus drawing, plus like Apple pencil. Rather
than infant canvas plus productivity plus whatever, collaboration, etc.
01:11:24 - Speaker 3: This does bring up the very interesting question
of what is the appropriate physical analog, and like you’re saying,
it’s not exactly the canvas because canvas, while it is free and open,
it does connote more drawing and art. To me, the analogy was always a
desk, it’s a place where you put down different content and work on it,
but I don’t think anyone is searching in the app store for Infinite
desktop
01:11:43 - Speaker 2: desktop as a metaphor has already been used.
01:11:46 - Speaker 3: Yeah, I got a little bit more traction with
whiteboard because people do use a whiteboard in that way or a pin board
cork board, but it is an interesting point that there isn’t quite an
obvious physical analogy that people tend to reach for.
01:11:59 - Speaker 1: Yeah, Pinboard seems to lack the direct
manipulation aspect of whatever this type of thing is now that we’re
calling it. I like whiteboard too, although whiteboard also It seems
like a fairly narrow subset. For example, like Scalira uses a virtual
whiteboard as it’s kind of like description of itself, and that’s
really good, but it also, you don’t expect to have like what you’re
describing of like multimedia types on a virtual whiteboard. So an
infinite white open pin board is really what we’re going for here, just
doesn’t roll off the tongue.
01:12:37 - Speaker 2: A whiteboard is an interesting term. Digital
whiteboard is one that I’ve seen Miro and others use to describe
themselves, and I think it’s not bad.
It feels a little trivializing or it seems to miss the grandeur and the
potential that I think this space has because a physical whiteboard is
pretty limited not only in size, but really what can do with it, which
is just draw in very limited ways in a few colors, whereas again I think
the file system is more of a source of inspiration to me, something that
is extremely flexible, powerful, searchable, has a lot of depth, has a
lot of extensibility, has programmability.
So I think whiteboard isn’t bad, but maybe an infinite canvas indeed is
better.
01:13:19 - Speaker 1: I was curious, when you were using the kind of
term spatial, like, I use spatial canvas, I think when I was first
presenting this idea to investors, and that seemed to click with that
crowd, because they probably heard it from other people who are pitching
these type of apps. But yeah, does that have legs? Did people understand
what Muse was when you were calling it like a spatial app or a special
UI?
01:13:43 - Speaker 2: Yeah, I think so. I think it wasn’t very
accessible, so I think folks who are, you know, read the Humane
interface by Jeff Raskin or know about Zoomy UIs or I don’t know, just
have a very deep interest in the topic or maybe that’s more likely for
them to understand, but for a more Not even casual user, but just a
regular professional user that is looking for a tool to solve their
problem. I don’t think it meant a lot, it didn’t seem to resonate,
didn’t seem to strike a chord necessarily. I like it, and I’ve even
seen others use it as well, but it feels like that’s one’s less likely
to really get the traction.
01:14:19 - Speaker 1: I guess zooy won’t take off either, for the same
reasons, yeah.
01:14:22 - Speaker 2: Probably not, yeah. ZUI, yeah.
01:14:26 - Speaker 3: This is very interesting to me that there’s two
ways we’re defining fitness of the name. One is, for example, if
you’ve used uses a lot, does it seem to accurately describe what it
does, but the other is, what are people typing in the app store when
they want something like this, and these things are actually quite
different, and I think the latter is harder.
01:14:47 - Speaker 1: Yeah, I mean, you always want to try and meet
people halfway, but it also, I don’t know, it’s been fun to watch what
people’s expectations are with Tealraw, like when they come to it, and
like, due to some poor user interface choices on my side, like, it’s
not obvious that this is a multiplayer app and that you can like, use it
with other people, and so I’ve definitely been like on Twitter and
people are like, man, this is so good, but I wish that it was
multiplayer, and I’m like, oh no, it is, it is, it is, and I know that
I’m only meeting like the one out of the 100 people or 1000 maybe who
decided to actually tweet about it, rather than just being like, oh man,
whatever, it’s not multiplayer like Miro is. So I think getting some of
the naming can also work to kind of signal those type of things, like,
what can you do with this? What is it for? And Yeah, like if it was
called a multiplayer whiteboard, like right off the bat, you know,
chances are people would look a little harder for that button to say
like, OK, open a new multiplayer page.
01:15:45 - Speaker 2: Notably, Mirro was originally called Real Time
board, which I think sort of captures, maybe not the most elegant name,
but it does capture that feeling, right? And then later they rebranded
once maybe they were big enough that they didn’t need the product’s
name to be so descriptive, so. I don’t know, but we look forward to an
upcoming rebrand of TL draw to TL collabra or TL I use realtime board
apparently it’s free.
01:16:07 - Speaker 1: There you go, waiting, waiting for it. I, I did
always feel bad for Mural, M U R A L, which is another direct competitor
of Miro, and then they had that name first and then Miro changed their
name to Miro, which is almost like identical pronunciation. Yeah,
surprised it worked, but yeah, I hope no one else does it with Seal
draw, CL draw or something like that.
01:16:36 - Speaker 3: Well, regardless of what we end up calling this, I
think the good news is it’s a very powerful category of software,
especially over the past 5 years. I think we’ve really seen it come to
the forefront with products like Sigma, and now with tools like TLDraw,
we could see a whole another blossoming of verticalized instances of
this pattern. So I think it’s really cool to be a part of that
evolution in software.
01:17:03 - Speaker 1: Yeah, for sure. I really just can’t wait to see a
bit like what you were describing with text editors, you know, like,
once we had a good text editor on the web, something that you could use
to build other products, you know, we saw a ton of really interesting
projects that just wouldn’t have been built, because like the same team
that wanted to build code sandbox might not have. Wanted to build
Monaco, right? Or might not have also wanted to build the text editor
that you would need to build code sandbox. Whatever else happens with
Tera, I really, really hope that it lowers kind of the barrier of entry
to making this type of app, that if there are bad ideas that involve the
canvas, that suddenly we’ll see bad ideas that involve the canvas
because there’s not 2 years of engineering time in order to get that
bad idea out into the world. And I’m more than happy to do that 2 years
of engineering time cause I Like this stuff, but I’m looking forward to
seeing what people do with it.
01:18:01 - 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. And Steve, I want to thank you for helping
inspire and push forward the infant canvas revolution that hopefully
we’re all going to be a part of.
01:18:20 - Speaker 1: Thank you. I should say, if you want to kind of
follow some of my journey here, you can follow me on Twitter. I’m at
Steve Rui OK. And yeah, if you want to try out TealDraw itself, it’s at
tealdraw.com. It is multiplayer. Don’t let the UI fool you.
0 min

About Metamuse

From the publisher's feed

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

Share Metamuse

Sign up to save your podcasts

Metamuse

Metamuse episodes

About Metamuse