Subscribe
Share
Share
Embed
Conversations with designers, founders, and builders behind some of the best work
Steve Ruiz Full Podcast.txt
English (US)
00:00:00.000 — 00:00:11.960 · Speaker 1
I actually killed the project. I was like, this is not. It's just not differentiated enough. It's not like, unique enough. The thing that was really unique, the thing that had no competitors and no like saturated market was Steve Reeves was about.
00:00:11.960 — 00:01:23.060 · Speaker 2
To start at Adobe. He had his bags packed. The job was accepted. He started on Monday, but then he looked at what was happening with his side project and open source canvas that he'd been building. Hundreds of sponsors had put up $200,000 in. Two major companies wanted to build on top of it. So he called Adobe and said he wasn't coming.
That project became a draw. Steve's background isn't in software. It's actually in fine art, and he has his masters in it. He spent thousands of hours studying ink on paper, how it moves, how it bleeds, how it dries. And when he wrote the algorithms for Digital Ink. He had this deep physical understanding that most engineers just don't have.
And he's put in 10,000 hours of that kind of labor. It's the whole reason that teal Draw even exists. We're going to talk about why he shelved his own SaaS product to focus on the software developer kit, why he thinks craft only matters when you're building for high agency users, and his surprisingly simple answer for the question every open source founder faces how do you actually make money?
This is state of play. Let's get into it.
00:01:30.220 — 00:01:40.700 · Speaker 2
Was there kind of a moment as you were coming up where you said, oh, wait, this this arts background is actually a really unique perspective in this tooling space.
00:01:40.780 — 00:02:16.710 · Speaker 1
There's some obvious ones, right? Like, okay, I'm working on design tools. I'm working on visual tools. I'm working on like ink and arrows and of course, like I worked a lot with ink. And, you know, I spend my thousands of hours looking at ink, move across paper and stuff. So, you know, when I later worked on algorithms that tried to approximate that.
Yeah, like I just had a ton of knowledge that was very specific and appropriate for being able to make good looking digital ink, because I'd spent a lot of time looking at, um, good looking non-digital ink, I suppose. Analog ink. Uh, the
00:02:17.750 — 00:02:47.669 · Speaker 1
the surprising thing was just how many parts of the way that you work when you're doing art translated over into just doing software and doing software in a kind of an interesting way. There's a long answer to that question. I'll try and give you the medium, medium length one with, with some, some meat, uh, which is, you know, if you're, if you're an artist, if you're working alone, um, especially if you're kind of early career.
So. Right. Your job is to, to find something that
00:02:49.030 — 00:04:31.580 · Speaker 1
interests you in a way that really is evident to other people. You can kind of tell pretty easily. Or at least I can when when an artist isn't really into their own work. Um, because it's usually kind of shallow and, um, isn't really, like, iterated on enough to, to become really, really unique. But, uh, the problem is that unlike design or unlike software, where you have a user, you have some problem that you're trying to solve for this, you know, theoretical user, uh, when you're in the studio, it's, you know, if you're painting, drawing like you don't really have anyone knowing, no one cares.
Uh, and no, no one should care. I mean, it's you're either going to make something that you like or you're not. That absence of constraints, that absence of, um, you know, reasons why you need to do any particular thing rather than something else. That is the creative freedom that that lets you kind of tune into to what you really want to do, what you find interesting, what corresponds to your skills and your the space that you have and the options that are in front of you and that that leads to the the artwork, but it's really, really hard to be working without external constraints.
It's really hard to work based on nothing but like, well, here's here's what I think is most interesting to do. Next. You develop strategies, uh, as an artist to to do that. And part of I guess what you learn at art school is like, um, you know, how to think critically about something that doesn't really matter.
Like it doesn't have to be good, but and it's really hard to even say whether it, you know, art can be good or bad or a painting is good or bad, but yet you're going to try and make the best one that you can, which seems like a contradiction. But that's still the, um, that's still the game. And you do get a sense for,
00:04:32.700 — 00:06:07.850 · Speaker 1
uh, how to, to work in this very, very open space of, uh, um, of the studio. And that surprisingly, actually worked really well, especially when I got into the open source where I was like, hey, you know, this is a side project or this is an open source project. I don't have to do this for anyone. I don't have to do this for anything.
There's no immediate reason why I should do this. And yet I have a pretty good idea of what it is most interesting to me. And I have a huge appetite for the type of working on something without immediate feedback on, oh, this is a good idea, or this is a good, you know, validated or, um, externally. Uh, in other words, like, I feel very, very comfortable saying, okay, I'm going to work on ink, digital ink, and I'm going to work on it for a long time, and I'm going to go like really deep into it.
Um, and even though I, it's not making me any money or there's no clear reason why this thing needs to exist or that what I'm doing that even that I'm the person who's supposed to be doing this type of work. Um, well, that doesn't matter. I've already done that a hundred times. I've put in 10,000 hours of, like, unmotivated work or, um, like pointless labor in terms of, uh, in terms of artwork, because I know that at the end of that, you know, either is a new direction, which I wouldn't have discovered any other way.
Or you can actually create stuff that really is great and really matters. But the only way to do it is to just kind of to do it. You kind of take that risk with your own time and with your own. Um, I suppose like the the value of your own labor.
00:06:08.050 — 00:07:09.310 · Speaker 2
Some folks might say art is something that you you really start by creating for yourself. And in, in tech we're so focused on the external feedback we get the product market fit. Um, we'll, we'll maybe give a little bit of, uh, attention to this idea that the creator has to enjoy what they do, and we'll call it Product Maker Fit.
And that's about as much love as it'll get. Or we'll say, oh, we're going to invest some time into just some exploratory stuff that might not yield an ROI right away. You're lost. Leading. Um, and in my relationship with, with kind of this idea over the last 15 years is everything has had to at least have some sort of ROI.
I've been so obsessed with it. I've gotten good out of out of necessity. And now I'm telling my team, let's move forward and play and experiment. And it's okay if we fail. But I want us to try some things that are a little unconventional. How has your relationship evolved coming from art into technology around that?
00:07:09.790 — 00:08:20.520 · Speaker 1
I have a pretty big tolerance for kind of trusting my gut and kind of working without knowing immediately what you're working for or working towards, because I just trust that, hey, look, if something is really, really interesting to me, there's probably a reason why that's that's the case. Um, I might not be able to articulate it right now.
I might not be able to see it right now, but, like, you know, my my, you know, context window is really packed with, um, you know, uh, with what's possible and within my specific domain that I'm working in, but also just in general and software and stuff. So if something is like shining out, if something really makes me feel like we should work on that, there's probably a good reason for that.
Um, I think the way that you negotiate those, you know, like the risk of play, you know, the risk is that you put a lot of smart people in a room and get nothing out of it at the end because, you know, we've we've investigated some things where we've scratched some itches, but like, nothing comes together the way that you kind of the way that I, um,
00:08:22.000 — 00:10:49.840 · Speaker 1
work with that is essentially setting up these parameters that make sure that something is going to come out of this. Now, that might be, uh, social media content, that might be marketing content. Right? That if at the end of the day, the worst thing that comes out of this experimentation is that we make some banger tweets like, that's good.
Like that's fine. Um, it might have been some expensive, expensive social media content, but at least it's documented with children. We have the ability to create examples and starter kits and just play with our own toys. And there's almost no wrong move there because it's all going to be useful to, to to someone or it's going to be useful to, I mean, these days even just as a so that someone's coding editor, you know, AI can say like, oh no, no, I found an example of how to do that, you know, online or something.
A lot of content creators will do a ton of low investments, um, content creation, very easy to do concentration, that kind of just, you know, tries a whole bunch of different things. It's just kind of a, you know, tweet, tweet, tweet, tweet, tweet or, you know, lightweight post or something like that. Uh, and then you see what, what really hits either what really hits with an audience or what really hits with you and you're like, no, no, no, there's more there.
Uh, and then you do the next level of like, you know, labor intensive, the next most labor intensive thing based on the survivors of that first generation. So if you put out 20 tweets and two of them start getting traction, like, well, one of those can become a blog post, right? You don't pick the thing that no one cared about and do a long form video on that because like, well, no one cared about it, right?
Especially if you've repeated that same topic multiple times and you know no one ever cares about it. Maybe you pick the one that that has an audience, and that audience could be you. You could be really, really into that thing. And okay, fine. Uh, and I think you can do the same thing with building as well, is that you can you can try a whole bunch of things in a way that is very lightweight or very low fi or that very like leverages different tools that are to, um, to, to prototype quickly.
And then you, you know, try it out either with your users or with each other and the team. I think teams are great for kind of like judging this type of thing internally, and if something is compelling, or if there feels like there's more to a certain idea that that idea kind of leads to other ideas in a way that that seems unique, then you invest more in that.
00:10:49.880 — 00:11:30.160 · Speaker 2
You refer to the canvas that we're referring to in this case is Digital Ink. And I, and I actually really like how you talk about that, because I feel like you're giving respect to the fact that this is an art medium. It can still behave that way. In my brain, I always told myself the story that I'm not good at art and I'm not good at illustrating or pen and paper.
So I'm going to go into design because there are these very rigid constraints that I have to operate within. But it seems like you think very differently about that. And I think I'm shedding these too. Was there a moment when you took yourself to kind of a digital canvas and said, hey, there's actually something here that's very artistic.
00:11:30.200 — 00:14:42.510 · Speaker 1
I think there's a big difference between working in an art and working in software. Um, software is just easier. I mean, like, I mean, you, you know, to to go back. Like, you have those constraints, you have that external user, you have that problem that you're solving and that is a gift. I mean, like it so many things just become so much easier because all of the possible, you know, things that you could do are just narrow to the ones that like, well, what do we actually think is going to be going to solve this problem, is going to help this user is going to entertain them, to light them.
You know, all that. And especially if you're the oh, also like a user of your own product and invest it in it's it's quality and can can feedback that way you know then it becomes this kind of prosumer loop and you're trying to satisfy yourself and you, you, you know what good software feels like or good, you know, hopefully, uh, you know, you're, you're on a team that can can have that kind of critical, uh, eye towards the software experiences.
I think from a, from a creative satisfaction perspective. Um, in many ways the, the software can be more creatively satisfying if you work on a project long enough. You quickly run out of obvious moves to make like, even if it's a fairly conventional, um, type of product, even if it's an email client or whatever, and you have this long list of, uh, table stakes features that you're kind of grinding through at the end.
You, you you'll finish those things, and it'll be this space of like, well, what do we want to work on next? You know what? What do we think is going to, um, be the new, you know, and the process of discovering that those new features or those new experiences or those new kind of, like, sister products or something.
There's this, this kind of loop that probably every, every creative person goes through where you're like, you have this like, empty canvas, uh, panic, you know, of like, oh my God. Like, there's there's no guidance other than, you know, like what I can think of that, that I like. My own creative imagination is, is really the limiting factor here.
And that, you know, whatever we're going to work on has to sort of occur to me or occur to us. Um, and if it doesn't, then then we're not going to make it. And if we're limited to what it does and all that stuff. Right. Uh, and that can feel very, very like, scary or daunting. Um, but then you do it and then you. The good ideas come.
You build it, and, uh, and you make it good, and you put it out in the world, and you're you're proud of it. Um, and that that kind of self-reliance, you know, uh, loop of knowing that you can, I don't know, get lost and find your way out again. Um, again and again and again, like, that's that's the that's the, you know, that's what keeps me coming back.
I have that same feeling whenever I write. I have that same feeling whenever I, you know, would start a painting and whatever. Um, and software too, like, it's still like whenever we, we need to work on something big or need to kick off something, something big. It's always like a all right. Like, can we do it again?
Can we make another hit here? Like, can we, uh uh, are we going to be able to figure out this time?
00:14:42.550 — 00:15:13.830 · Speaker 2
It already makes a lot of sense why you've been somebody who is increasingly finding new paradigms and ways to solve things from kind of a user experience perspective, because you, you, you encourage so much play in the process, it seems like. Or do you subscribe to the idea that in each medium so desktop or mobile, um, that there exists a ceiling of patterns?
Uh, there's only so many ways we can create around progressive disclosure. There's only so many ways we can reduce cognitive load.
00:15:13.830 — 00:15:46.520 · Speaker 1
I would say the majority of, like, software experiences, uh, have not been discovered yet. I think it's still a very young, young medium, if you would ask me four years ago or like, you know, do you know what a chatbot is? You know, I would have said, yeah, yeah, yeah, it's super mature. Like intercom is adding it.
You know, it's like it's a very, very conventional thing now that's been completely exploded in terms of what I can expect from a chatbot and what kind of interactions existed with within that. And I really like the fact that so much of software experience has been
00:15:47.600 — 00:17:10.410 · Speaker 1
like, become conventional, uh, because it lets you focus on the things that are not conventional. Is that, uh, especially as a designer, as a maker, I mean, there was a there was a time where I feel like a lot of designers, maybe we'll see it again with the liquid glass thing. But a lot of designers were spending a lot of time rebuilding, um, and building component libraries that like rebuilt native, you know, interactions like native headers and toolbars.
And I saw this in all the prototyping tools as well, where folks were like, re implementing all this stuff. I'm like, what a total waste of time. Because like, uh, like, good job you did it. No, no one notices. Like, you know, cool. I'm sure it was like you learned a lot about building components and building the design systems and stuff like that by by copying.
But, um, you know, it's not differentiated. Like, and I think the fact that like a combo box is pretty well known as to what a combo box does and, you know, error text underneath a text input or the way that you set up an account menu or something like that. That's good. Like, I hope those things continue to contextualize and like become more and more boring to design because, uh, we probably won't be designing them, you know?
Um, we probably will be spending that energy on the parts of the, the applications that we work on that are like, unknown, that are, that are new. And I really do think that there's a lot left to explore there.
00:17:10.449 — 00:17:39.510 · Speaker 2
You've described yourself as kind of prototyping obsessed, and I have to ask you, and maybe this is a pretty conventional answer, but I'm curious, how do you decide when something a point of play in prototyping, like with tell draw, you know, introducing something like the infinite canvas to maybe match certain expectations that exist on the market, but then going completely unconventional with some of the things that you can do on top of that canvas.
How did you start to say, yes, this is now ready to go and become a full product.
00:17:39.550 — 00:17:46.350 · Speaker 1
It was always kind of a full product, like it was always like, well, and in some ways it's not a full product. Like we don't make any money off of.
00:17:47.990 — 00:19:13.129 · Speaker 1
Uh, you couldn't even log in to Tilda before January, and we had like, 200,000 users a month. You know, but but no one, no one could log in because we just hadn't done that and we didn't really have to in the the demo, the experience of telecom was actually kind of fine. Uh, without it, I think it's better with a user accounts, but it was kind of fine without it as well.
Uh, you can still collaborate even though it was anonymous. But you know what? You you tend to know who you're collaborating with anyway. You tend to send that link to someone anyway. Okay? You couldn't save files forever, or you didn't have a list of all your previous files. But you know what? Most of the collaboration was ephemeral anyway, and you could always just bookmark stuff or put it in a note or something.
So there were all these, like, kind of folk habits that people were building up around how they managed their, uh, their use of Teodora before that, like any prototype. It's it's kind of real, but it's also kind of not real. It's also like, you know, it's it's as good as you could make it given the constraints.
But you know, that you could always invest more in it and or throw it out and start over. And I certainly did that a couple of times. So you'll draw, having done prototypes professionally as like the prototyping designer and technical designer, um, as well as just on many, many of my own projects, really, the line between the prototype and the, you know, the, the actual product starts to blur really quickly.
Um, and that the
00:19:14.250 — 00:20:47.400 · Speaker 1
mentality that I had working on prototypes and the, the way of doing that, just out of, out of, out of necessity when, when working with design teams, just turned also out to be a good way of doing software, which is that, um, you try and be as like, clear as possible because you think that you're going to throw this out later.
Um, you try and have loose couplings between different systems because you want those systems to get, you know, reused on the next iteration or replace pretty easily. Um, you document a lot because you assume that someone else is going to be reading this in order to, to, like, create the real version of it later.
Uh, and you don't build more than you need in order to, to create a kind of compelling experience. And, you know, when we did, uh, make real, you know, that was also an incredibly thin, uh, make real is where you could draw a user interface, click a button, and, uh, GPT four with vision, which was like the first multi-modal model, would go build it for you.
And then the the thing that it built would We would put it back on the canvas, and then you could, like, draw on top of it and, um, like, annotate it and give more context and then do that again and say like, okay, I've crossed out and things left notes and like, all right, make make that real again. And uh, and you could iterate kind of forever that way by just by drawing.
And people made incredible things. It was one of the first like vide code type of, uh, apps that let non-technical people build interactive stuff.
00:20:47.440 — 00:21:13.120 · Speaker 2
It seems like you kind of optimize the critical mass around features of the things that are in the hands of the user. So, like, I mean, like you decided to forego user authentication early on and, uh, before you, you poured into that and then some of the other features, you're like, you know, what's in the hands is what we're going to try and make work.
Well, and then we'll kind of extend beyond that. Is that is there, is there like an intentionality around that, or does it just kind of you just kind of approximate in that direction you.
00:21:13.160 — 00:23:14.880 · Speaker 1
Focus on like the features that really, really, really matter that people are going to absolutely use, all of the users are going to use, uh, and then you kind of go out that that next step of like the things that some people are going to use or some people are going to need or some people would want. Um, but if you don't have that core, like if you don't have the core user experience of a of a piece of software like excellent and validated and like iterated on and putting a ton of energy into that and nothing else really matters.
I used to I used to ride my bike a lot. Like long distance cycling. Uh, and you can spend a lot of money on cycling. Uh, you can spend money on every single part of the bike. You know, if you want a carbon fiber bottle cage for $40, like you can find that. And the way that you make that manageable from from the perspective of, you know, the cyclist is that you you have to give some sort of priority to the things that matter.
And everything else sort of becomes a luxury. And you're allowed to spend money on your hobbies. So luxuries are fine. But like the the things that you care about first are the parts of the bike that you're touching, like the parts of the bike that your body is going to physically touch. Before you spend money on the parts of the bike that your body is not going to touch, because it'll just matter more.
Right. Like that's the part of the bike that really, really exists to you. You can sacrifice. You won't notice the bottle cage. Uh, you won't notice the, uh, the whatever kickstand or something. But you will notice after after 200 miles or 300 miles. Like if the grips are low quality or something. And I think with the software, it's the same.
It's like you, you optimize for the part of the app that people are going to touch, and the people are going to know all everyone is going to experience. And then you kind of prioritize, or at least either you never build it. That's totally possible authentication for us. We just never built it. Um, or you you just keep prioritizing you, you go lighter on those other things.
Um, and I think most people understand that like, and kind of even appreciate it as long as that court experience is great.
00:23:14.920 — 00:23:51.800 · Speaker 2
So you optimize for the points of contact, the hands on the handlebars, the tires on the surface, which makes it really interesting to think about the decision that went into tail draw, which operates very heavily. You just spoke about, you know, a non-technical person being able to come in and immediately prototype with very limited knowledge on what is happening in the background.
But at the same time, this is a deeply developer centric tool as well. You talk about the SDK and you talk about the philosophy that went behind making this open source and extensible from the start. Where did that come from, and how did you kind of mix that into this, this core philosophy?
00:23:51.840 — 00:29:05.930 · Speaker 1
When I started to draw, it was kind of a follow up to another open source project that I did called globs, which was this experimental design tool that you'd have to you'd have to see it, but globs dot design. Um, and, you know, I'd built a pretty complicated canvas for globs and, and I really love the, the the kind of the UX paradigm of resizing things, moving it around, kind of building this little like Figma Lite type of thing.
And I thought, you know, I'll probably keep making these, like, I'm going to be continuing to work on visual problems. Uh, and there really wasn't any solution out there for me to, to pick up and, like, use for, uh, like there was no open source around, like, design tools, like there was no design tool starter or canvas starter for, uh, for me as a developer.
And I was actually surprised by that, given how successful some of these projects are. Like Sigma's massively successful, uh, you know, Miro was massively successful. This was in 2020 or 2021. And it just made sense for, uh, for me to build that for myself. But, um, it also was such a visual problem. And, you know, so many people were using these tools like using Figma and using Miro that, you know, as I was sharing my work and sharing these problems that I was working on, uh, people just loved it.
Like the content was, was great. The social media feedback was was amazing. Like, it just lets itself really well to to storytelling on social media of like, hey, have you ever noticed in Figma that the corners of the boxes are in the corners of the of the box, even if, if you resize it, they don't, you know, the the dashes are always in the corners.
I don't know, whatever. Like, how does that work? Let's build that. Um, it was really fun and I just kept on here. As the project got more popular, I just kept on hearing, uh, from teams that were like, yo, we've been waiting for something like this to come around because we really wanted to build one of these, these types of apps.
Or we have this like design for this, this canvas. But, you know, as soon as we started working on it, we were like, oh my God, this is impossible to build. Or this is like super complicated, um, and like, like specialized work. So, you know, there's thrilled to build on top of what I was building. As the story goes, I had accepted a job with Adobe and said, let me start in January.
Let me finish this thing. Get this open source thing out of my system. And then by the time that I would have started working at Adobe, I had had like $200,000 of sponsorship from like hundreds of people and two major companies and had like people were building with this thing and the com was popular and the, the repo, like the open source part of it was really popular.
I was like, there's something here. I don't know whether this is, you know, like the I, I'm going to end up making like a miro competitor and just saying, okay, end user experience. That'll be where I focus or whether I, I'm going to go in the other direction and focus more on the developer side. But either way, I had to tell Adobe I wasn't going to start work on Monday.
Uh, and really, it took a long time to to even decide which of those two directions we were going to go in with regard to commercialization, because the work was the same. either way. The work was to rebuild the canvas and to make it good and get all these features in. Um, and then when it came down to it, I felt like ulta.com was and we built a SaaS app on top of that.
We never released it, but you know, where you could log in and have your team and get your stripe kind of, you know, credit card out and pay $10 a head. Um, and I actually killed the project. I was like, this is not it's just not differentiated enough. It's not like, unique enough. The thing that was really unique, the thing that had no competitors and no, like saturated market and, um, no super mature, you know, muros in the space where it was, uh, was the SDK.
And when software succeeds it, it kind of just gets commodified. Uh, Trello was great. Trello boards. I changed the way the teams work. Trello was amazing. But we don't call them Trello boards anymore. We call them Kanban boards, right? Like, it's not a not an application experience. It's like a commodity.
It's like a it's just software experience. I think we're seeing that happening in light speed with AI, where like some company will come up with like, oh, agent mode, you know, and then like two weeks later, it's like everyone has their agent mode and it's like, all right, cool. That's that's just a normal thing now.
Um, and did you'd expect with the success that had happened in whiteboards and canvas tools that that would have happened there as well, but it hadn't, because it's a super hard problem and a very valuable problem. And every company that had started working on something like that was acquired, um, and had that, that software folded into to some other, other company.
If you're diagraming, if you're drawing, if you're on a quick call and you just need to send someone a link and work together, like, like, um is exactly perfect for for that use case. Um, and I'm really happy with that. I really like that, that role for it. And I'm very happy to, um,
00:29:06.970 — 00:29:08.089 · Speaker 1
yeah, be able to
00:29:09.610 — 00:29:19.490 · Speaker 1
justify the amount of quality that I like to put into a product through the SDK story, where it can benefit thousands of different applications.
00:29:19.490 — 00:29:37.290 · Speaker 2
And I've got to imagine there was some conflict there, like quite a bit of conflict in deciding to open source versus kind of keep it proprietary or private, do you think? Well, so I'm curious if that's true or not. And do you think think what would have been different, do you think today, had you decided not to open source.
00:29:37.290 — 00:30:02.140 · Speaker 1
The decision to share our code to to tell developers you can build on this? We will continue to support this and we will continue to support you. It wasn't easy because there aren't a lot of good examples of companies that make any money at all doing this type of thing. Um, like, there are some really great companies in this space, uh, in open source that, you know, or,
00:30:03.660 — 00:31:34.480 · Speaker 1
uh, they just like, don't don't make nearly as much money as you'd expect, given how much, uh, influence they have and how much impact they have on on the kind of software world. Uh, react flow for for diagrams. Uh, super, like insanely popular. Like way more popular than TLG. Um, I think we're making more money than them just because we're not.
We don't have an MIT license like people. If a large company wants to use dual draw, they they pay large company money to use teal drive. Um, and that's that's very hard to do if, you know, most of the time, based on the way that the company sells their access to their software by selling, like access to their docs or premium like little widgets that big companies can build anyway.
And so there weren't a lot of like shining examples of of companies for us to look at. It was a big bet that we would be able to do something different and make that work. The thing that we did different, by the way, is just not have an open source license and ask for money and ask for more money every time. Um, and so it was it in a lot of ways, it's kind of a naive way of, of solving the problem.
It's a little bit like that. You know, I use the, the mid whit meme, uh, to explain this, that like ask for money, very complicated solution and then just ask for money. Uh, just charge for the product that you're offering and capture a part of the value, like surprise. Uh, everyone gets it.
00:31:34.520 — 00:32:12.620 · Speaker 2
You prioritize craft, but you also recognize there are these edge cases and these certain things that have to be done right in order for this to work in this context. Um, there are other teams in me included who I would, at the first couple of versions, prioritize a couple of those edge cases, because I would want those edge cases to be where we differentiated ourselves.
We go to market Having already thought about that. But if we were thinking through the kind of critical mass lens, that might be a waste of time initially up front, that's not the points of contact approach. And so I'm curious, how do you define this word that's been, you know, overused this year? Kraft, in the context of tile draw, when.
00:32:12.620 — 00:34:08.050 · Speaker 1
You build a product or build a company, you kind of get to build it in a way that lets you take advantages, take advantage of your own strengths. Uh, and that's that's what I feel like I've done with Teal Draw is that, as I was saying before, like the thing that I often find myself saying to developers when they're evaluating teal draw or when I'm explaining teal draw is like, look, you're a good developer.
This is, you know, you could build this, um, but you wouldn't build this. You'd build the minimal version of this in order to, to finish your application because you're not building the, the, the world's perfect canvas. You're building a tutoring application for, you know, K through 12 tutors. Um, and so making sure that the cursors rotate.
Like when you're rotating things. Like it's probably not a blocking issue in terms of like delivering that experience to your users. I am trying to build a perfect canvas or a canvas that is is completely worked over in terms of polish, in terms of all the little edge cases, in terms of all the, um, you know, the full user experience that we've gone in and solved all of the crazy stuff that you could probably cheat your way around.
Like you might, you know, be able to punt on this or that might just not let people rotate things, you know, in order to avoid the craziness that comes with rotation. And so now you get to kind of create that, that, that level of, of quality, not just in the the things that you're great at, of building tutoring applications or something, but also in the canvas itself, should, should meet that same level of quality as the rest of your app.
Uh, and that's that's pretty compelling. And that's a good use case for for quality. Another good use case for quality and craft is building products for high agency users. What I mean by agency users. Uh, I might soapbox a little bit here, but but go with me.
00:34:09.090 — 00:34:17.490 · Speaker 1
Uh, software developers are like probably the highest paid, um, non managerial staff outside of, you know,
00:34:19.010 — 00:35:05.300 · Speaker 1
the athletes. Yeah. Like when you think of, like, non-executives who are commanding like very, very high salaries, uh, software engineers are some of those. And so they have a ton of influence. They have a ton of agency. They have a ton of, like, political power, uh, within an organization to say, hey, look, these are the tools that I want.
Um, my time is worth so much money that if you make me fill out a Jira ticket, I'm going to quit my job. You know, like you're wasting your own money in addition to making my life a living hell. By Bilinear. It's great. Uh, and it'll make me happy. And that's that's very compelling because you're you're building for linear, like you're building software for very high agency, high influence people within their organizations.
I think we're craft is less,
00:35:06.420 — 00:35:57.590 · Speaker 1
uh, a good idea or a strong differentiator is where you're building software for low agency or low influence people. There might be tools for, uh, customer support. And I love customer support. I love every customer support person that I've worked with it often the most interesting people at the company, certainly the nicest, but they don't have a lot of influence.
They don't have a lot of like, uh, they can't make the same demands that a software developer making $1 million a year in comp can, can make. And so, you know, is that the right place to as a, as a software builder, like to, to optimize for, for user experience to this if you're the people that you're building for, aren't really going to be able to be making those decisions if those you know it.
Yeah, it might not be. I mean, it kind of sad, but it might not be the right place to start. Strategically, the right place to invest in craft.
00:35:57.630 — 00:36:14.470 · Speaker 2
At high agency. Lower agency is a really great. I love I love your take on that. Um, and, you know, I appreciate your time here, Steve. I just want to kind of wrap up and ask you what is the most fulfilling thing you're getting out of building tail drawer right now?
00:36:14.470 — 00:37:28.530 · Speaker 1
So with Teodora, I love the fact that I get to build a team that sort of reflects what I care about. Uh, in, in, in software development and software design, uh, in an approach to product and so on. And so like, you know, whenever we have a win, whenever we, we sit down and say, okay, we're going to do something great and then we do it.
Absolutely. I'm happy that, okay, this is going to convert this many people or this is going to bring in this much attention or this is going to like get as many Twitter followers or whatever. Uh, but it's also like highly validating to that, that the way of working that I like and that I think is, is, you know, the right way of working for this product like that it works and that it's not arbitrary and that these aren't like bad habits necessarily.
It's just, hey, if you want to do something that is both creative and commercially minded and super ambitious, and this is one way to do that, it's such an opportunity and such a privilege to be able to even try that and to really be able to run this, this startup as a, as a somewhat of a the experimentation on how software can be made.
00:37:28.530 — 00:38:39.150 · Speaker 2
I liked Steve's long distance cycling analogy that when you're spending money on the bike, you first focus on the parts your body touches first. And that's how he builds software. TLDR had 200,000 users before you could even log in because the drawing experience was just that good. People were bookmarking their files and they just kept coming back.
I also liked his framework for when craft actually matters strategically, by focusing on the power users who have the political power to say, use this tool, or I'm walking because that's where Polish converts directly into revenue. When you can build for people who can demand better tools, than suddenly quality becomes one of your advantages.
It's a colder take than I think most people are comfortable with, but I do think he's right. And underneath all of this is what he learned in art school that I think applies to anyone building right now. This ability to get lost and then find your way out again to trust that if something feels interesting, there's probably a reason for it, even if you can't articulate it.
That's the episode. I'll see you next time.