Season 3
|
Episode 5
Confessions of a two-time design founder
Brian Lovin
Founder and Designer @ Campsite
Nov 2, 2023
Nov 2, 2023
|
48 minutes
48 minutes
music by Dennis
About this Episode
In this episode, Brian Lovin talks about his journey as a second-time founder and gives a behind-the-scenes of building his new startup, Campsite. He also shares key insights from hundreds of interviews he’s conducted to learn more about what makes a great design process.
We talk about:
- Strategies for sharing your work and getting feedback
- Why Brian thinks we’ve gone too far with landing page design
- Finding the right level of craft as a design founder
- Why Brian no longer thinks every designers should start a company
- The problems with post-COVID design process
- What he’s doing differently as a second-time founder
- The three values he’s instilling in the design culture at Campsite + a lot more
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Deep Dives
Get every episode
Free lessons from 👇
Fonz Morris
Lead designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Transcript chapters
Going from designer to founder
So campsites started as a bug in my brain many, many years ago. Really, at Facebook, just thinking about what it feels like to be on a team where there's a culture of sharing early, sharing often. There's some social mechanics at play inside of Facebook where... It was fun to share work and get lots of people to look at it and get people higher up in the organization to look at it. In this planted this bug in my brain back in 2016, that there's a different way for design teams to function.
And ever since Facebook, I've just been looking for that same way. So I started a company and then I ended up at GitHub. And at GitHub, uh, fully distributed team, and also through the height of COVID and the pandemic and work from home, I just looked around at design teams siloed into Slack channels and literally not knowing what anybody else is working on.
I would, I would [00:01:00] constantly be messaging people at GitHub like, What's new? Show me pixels. What have you made? Like, what is your team going to ship next? And just getting those answers was like pulling teeth. And, uh, the management team at GitHub did a lot of work to try and share these updates, to bring people along for the ride.
And it was super manual, tedious, time consuming. I don't know that anybody really liked it. I don't even know that that many people looked at the ensuing artifact. So anyways, there I was at GitHub knowing that there's a better way to collaborate as a design team and feeling like we haven't figured it out.
I talked to a lot of other designers and design teams that haven't figured it out. I bet I can solve that problem. Uh, and so once that bug starts to creep back up, uh, for me, it was, it was like a nights and weekends bug, right? Like, I'm going to just start prototyping an app and show it to some people.
See if it feels right. Uh, the nights and weekends led [00:02:00] to showing it to people who are really excited and wanted to use it and wanted to try it. And, uh, you know, I think when you're starting something new, there's always the question of, do you just quit and go full time? Do you try and de risk it? For me, I did try to de risk and sort of gradient my way into leaving GitHub.
And really that was only possible because I had really good managers at GitHub or specifically my manager was incredibly supportive and I basically negotiated a leave of absence. . And I took three months to just work full time on Campsite, and during that three months, it was full steam ahead to just try and figure out if this is a thing that could work.
At the end of the three months, I had built some confidence, I had conviction, like, yep, there's something here, I have people using it, I have people paying for it. I'm just going to go. And I mean, it's not a fun message to send to your manager. Like, Hey, thanks for all of the time you put into helping me get a leave of [00:03:00] absence.
I'm out. Um, but I think there was some implicit, uh, well, actually pretty explicit understanding that this was a possible outcome. So anyways, that was sort of my path to de risking. I'd been thinking about it for a long time. Uh, nights and weekends, unpaid leave of absence, a little bit risky, but not the end of the world.
And then finally, at the end of that, had enough conviction to go full time.
Going from designer to founder
So campsites started as a bug in my brain many, many years ago. Really, at Facebook, just thinking about what it feels like to be on a team where there's a culture of sharing early, sharing often. There's some social mechanics at play inside of Facebook where... It was fun to share work and get lots of people to look at it and get people higher up in the organization to look at it. In this planted this bug in my brain back in 2016, that there's a different way for design teams to function.
And ever since Facebook, I've just been looking for that same way. So I started a company and then I ended up at GitHub. And at GitHub, uh, fully distributed team, and also through the height of COVID and the pandemic and work from home, I just looked around at design teams siloed into Slack channels and literally not knowing what anybody else is working on.
I would, I would [00:01:00] constantly be messaging people at GitHub like, What's new? Show me pixels. What have you made? Like, what is your team going to ship next? And just getting those answers was like pulling teeth. And, uh, the management team at GitHub did a lot of work to try and share these updates, to bring people along for the ride.
And it was super manual, tedious, time consuming. I don't know that anybody really liked it. I don't even know that that many people looked at the ensuing artifact. So anyways, there I was at GitHub knowing that there's a better way to collaborate as a design team and feeling like we haven't figured it out.
I talked to a lot of other designers and design teams that haven't figured it out. I bet I can solve that problem. Uh, and so once that bug starts to creep back up, uh, for me, it was, it was like a nights and weekends bug, right? Like, I'm going to just start prototyping an app and show it to some people.
See if it feels right. Uh, the nights and weekends led [00:02:00] to showing it to people who are really excited and wanted to use it and wanted to try it. And, uh, you know, I think when you're starting something new, there's always the question of, do you just quit and go full time? Do you try and de risk it? For me, I did try to de risk and sort of gradient my way into leaving GitHub.
And really that was only possible because I had really good managers at GitHub or specifically my manager was incredibly supportive and I basically negotiated a leave of absence. . And I took three months to just work full time on Campsite, and during that three months, it was full steam ahead to just try and figure out if this is a thing that could work.
At the end of the three months, I had built some confidence, I had conviction, like, yep, there's something here, I have people using it, I have people paying for it. I'm just going to go. And I mean, it's not a fun message to send to your manager. Like, Hey, thanks for all of the time you put into helping me get a leave of [00:03:00] absence.
I'm out. Um, but I think there was some implicit, uh, well, actually pretty explicit understanding that this was a possible outcome. So anyways, that was sort of my path to de risking. I'd been thinking about it for a long time. Uh, nights and weekends, unpaid leave of absence, a little bit risky, but not the end of the world.
And then finally, at the end of that, had enough conviction to go full time.
The first three months working full-time
you talk a little bit more about that three month period? Like where were you at at the beginning of it? And then kind of, how'd you know where to go from there? And where'd you get to at the end of the three month period that kind of crossed you over that confidence line where you felt like you knew you could make the jump.
It's funny. Cause you start out the three months with some goal in mind, which for me was, I just wanted paying customers. And towards the end, you're like, actually, it's just really hard to get paying customers. So you get to be a little bit fuzzy there. I had paying customers, but I was, I don't know.
I think I was just setting really abstract goals. Like I want [00:04:00] 10, 000 in revenue, just basically making numbers up. I can't even remember at this point at the beginning of the three months, I think I had a prototype and people interested in it. And I might've had like a landing page wait list with.
Companies who had signed up and the name of the game through the three months was, I mean, it was just a grind, but talk to customers, build things, show those things to the same customers, rinse and repeat, and I would basically get into a loop where I think it was Monday, Tuesday, talk to customers, Wednesday, Thursday, Friday build.
And then rinse and repeat the next week. And so after three months of that, like you can get a lot done. And by the end of three months, I had customers, there were people paying for it. I don't know if I hit the, any sort of revenue goal, but it was like promising enough, you know, you're like, it didn't quite hit the goal, but there's [00:05:00] a, there's a line that's going up into the right here that, that feels good.
You mentioned this briefly in the beginning, but I'm just going to kind of hit on it for people who are not aware. Yeah. This isn't your first rodeo you've started up before you actually started a company called spectrum, sold that to get hub, which is how you ended up at GitHub. And that's now powering their like developer community forums.
So you have this history of experience. You've learned a lot of lessons. My question is, what are you doing differently this time with campsite than you did with spectrum?
Well, first I should correct the record. Spectrum isn't really powering anything at GitHub. Spectrum is actually shut down, but I like to think it was maybe the spiritual precursor to discussions. I don't know. There's
Powering doesn't mean need to mean APIs.
code is gone. Spectrum
gotta have, you gotta have the foundation.
Which, by the way, is a whole separate thing that was interesting about Spectrum is that it is deleted.
It [00:06:00] is gone from the internet. And that's a weird feeling to have worked on something for a long time, and I don't know, I guess you have the Wayback Machine, and maybe some old screenshots on your hard drive, , but it's gone, man.
Talk more about that. I don't want to skip it yet.
, I'll tell the story that when we joined GitHub, we had, On the order of magnitude of like tens of thousands of active users on the app. Not huge, but not bad. Like people were using the product and it was growing a little bit.
I was using the product.
Yeah. Yeah. We had good communities on there. I think we had the, the Figma community was on there. We had a big framer presence. We had a big react presence. Like there was folks on there using it. , so we joined, we were on the order of tens of thousands. , and. I don't know that we really found our footing internally at GitHub.
Uh, we ended up not getting to invest that much in the Spectrum product in that first year. But I checked back in on the analytics after a year [00:07:00] and we were in like the hundreds of thousands of users. So zero product work, zero new features. And the app just grew like crazy. And a lot of that is because we've been planting these seeds that Spectrum would be.
Um, like the search indexable alternative to a Slack community or a discord community, right? Like That search index ability led to a lot of growth without us really doing anything.
So in hindsight, I don't know, like maybe we were. On the cusp of something more interesting. , so it's always this tension, I think in the early stages of like, how long do you keep pursuing an idea before you quit? And for me, like joining GitHub was quitting, right? Like we stopped working on spectrum. , and that's just always hard.
It's a hard call to make in the moment. Like when you're in the weeds, it feels like [00:08:00] everything is fighting against you. It feels like the odds of failure are high failures right around the corner. But then you get this one year period where you get to look back at some graph and you're like, Oh shit, like things were actually kind of working.
Um, so you just don't know in the moment.
I'm curious, do you feel that same failures right around the corner right now
Oh, yeah. Uh huh. Yep every day every day. It's funny I feel like the startup mode is just this like, uh spiraling outward, uh From a time point of view, just recursion of highs, lows, and stresses. Like literally every day, it feels like you're failing at something. And then every week, there's sort of like some slightly broader theme that you're failing at.
And every month is some slightly broader theme that you're failing at all the way out. You know, and then I'm now like in year two. It's like, oh man, time is flying. [00:09:00] Uh, so yeah, definitely feels like things could fail. I mean, we're still small.
All right, now let's return. So with all of these experiences and thoughts and emotions, how does it impact the way that you're currently approaching Campsite?
The first three months working full-time
you talk a little bit more about that three month period? Like where were you at at the beginning of it? And then kind of, how'd you know where to go from there? And where'd you get to at the end of the three month period that kind of crossed you over that confidence line where you felt like you knew you could make the jump.
It's funny. Cause you start out the three months with some goal in mind, which for me was, I just wanted paying customers. And towards the end, you're like, actually, it's just really hard to get paying customers. So you get to be a little bit fuzzy there. I had paying customers, but I was, I don't know.
I think I was just setting really abstract goals. Like I want [00:04:00] 10, 000 in revenue, just basically making numbers up. I can't even remember at this point at the beginning of the three months, I think I had a prototype and people interested in it. And I might've had like a landing page wait list with.
Companies who had signed up and the name of the game through the three months was, I mean, it was just a grind, but talk to customers, build things, show those things to the same customers, rinse and repeat, and I would basically get into a loop where I think it was Monday, Tuesday, talk to customers, Wednesday, Thursday, Friday build.
And then rinse and repeat the next week. And so after three months of that, like you can get a lot done. And by the end of three months, I had customers, there were people paying for it. I don't know if I hit the, any sort of revenue goal, but it was like promising enough, you know, you're like, it didn't quite hit the goal, but there's [00:05:00] a, there's a line that's going up into the right here that, that feels good.
You mentioned this briefly in the beginning, but I'm just going to kind of hit on it for people who are not aware. Yeah. This isn't your first rodeo you've started up before you actually started a company called spectrum, sold that to get hub, which is how you ended up at GitHub. And that's now powering their like developer community forums.
So you have this history of experience. You've learned a lot of lessons. My question is, what are you doing differently this time with campsite than you did with spectrum?
Well, first I should correct the record. Spectrum isn't really powering anything at GitHub. Spectrum is actually shut down, but I like to think it was maybe the spiritual precursor to discussions. I don't know. There's
Powering doesn't mean need to mean APIs.
code is gone. Spectrum
gotta have, you gotta have the foundation.
Which, by the way, is a whole separate thing that was interesting about Spectrum is that it is deleted.
It [00:06:00] is gone from the internet. And that's a weird feeling to have worked on something for a long time, and I don't know, I guess you have the Wayback Machine, and maybe some old screenshots on your hard drive, , but it's gone, man.
Talk more about that. I don't want to skip it yet.
, I'll tell the story that when we joined GitHub, we had, On the order of magnitude of like tens of thousands of active users on the app. Not huge, but not bad. Like people were using the product and it was growing a little bit.
I was using the product.
Yeah. Yeah. We had good communities on there. I think we had the, the Figma community was on there. We had a big framer presence. We had a big react presence. Like there was folks on there using it. , so we joined, we were on the order of tens of thousands. , and. I don't know that we really found our footing internally at GitHub.
Uh, we ended up not getting to invest that much in the Spectrum product in that first year. But I checked back in on the analytics after a year [00:07:00] and we were in like the hundreds of thousands of users. So zero product work, zero new features. And the app just grew like crazy. And a lot of that is because we've been planting these seeds that Spectrum would be.
Um, like the search indexable alternative to a Slack community or a discord community, right? Like That search index ability led to a lot of growth without us really doing anything.
So in hindsight, I don't know, like maybe we were. On the cusp of something more interesting. , so it's always this tension, I think in the early stages of like, how long do you keep pursuing an idea before you quit? And for me, like joining GitHub was quitting, right? Like we stopped working on spectrum. , and that's just always hard.
It's a hard call to make in the moment. Like when you're in the weeds, it feels like [00:08:00] everything is fighting against you. It feels like the odds of failure are high failures right around the corner. But then you get this one year period where you get to look back at some graph and you're like, Oh shit, like things were actually kind of working.
Um, so you just don't know in the moment.
I'm curious, do you feel that same failures right around the corner right now
Oh, yeah. Uh huh. Yep every day every day. It's funny I feel like the startup mode is just this like, uh spiraling outward, uh From a time point of view, just recursion of highs, lows, and stresses. Like literally every day, it feels like you're failing at something. And then every week, there's sort of like some slightly broader theme that you're failing at.
And every month is some slightly broader theme that you're failing at all the way out. You know, and then I'm now like in year two. It's like, oh man, time is flying. [00:09:00] Uh, so yeah, definitely feels like things could fail. I mean, we're still small.
All right, now let's return. So with all of these experiences and thoughts and emotions, how does it impact the way that you're currently approaching Campsite?
What Brian is doing differently with his second startup
So one of the, the big differences now is that we actually have a team at campsite with spectrum. It was just the three co founders. So I'm getting to have a little bit of a different experience there. Uh, I think we're able to move a little bit faster. We just have more horsepower behind, , the machine that is campsite. I think it's so hard because when you're in the weeds, every decision you make is made for a logical reason, right? Like, I look back at some of the mistakes we made at Spectrum, and in the moment, it was like the most logical [00:10:00] decision we could have made. I don't know how you could have avoided that. , and so I think when I think about campsite now, it's like, you don't really know what's going to be a mistake until later.
So the way I think about it is as long as we are building fast, learning fast, and not getting precious about any of the things that we've tried, uh, like we're pretty willing to cut features, delete things, uh, try and bring customers along for the ride as we do that. But we're just not precious about the thing that we've built.
Um, I don't know that we were ever super precious about things, , on Spectrum, but I think there was definitely a hesitation to cut features. And what ends up happening if you can't cut features is you just, the, the surface area of your product just starts to sprawl, even, even for a small startup, right?
It's just like more pages, components, flows, things to maintain. More bug [00:11:00] reports, which leads to more stress support queues and all this kind of stuff. When really like if you just cut the features that nobody actually cared about, your life would be a lot easier. So if I think about Spectrum, we probably didn't cut enough.
Campsite, we're cutting quite a lot and we're not, , shy about doing that.
Can you share an example or two of just like, yeah, what's a feature that you cut that maybe you would have been a little bit more precious about the first time around?
What Brian is doing differently with his second startup
So one of the, the big differences now is that we actually have a team at campsite with spectrum. It was just the three co founders. So I'm getting to have a little bit of a different experience there. Uh, I think we're able to move a little bit faster. We just have more horsepower behind, , the machine that is campsite. I think it's so hard because when you're in the weeds, every decision you make is made for a logical reason, right? Like, I look back at some of the mistakes we made at Spectrum, and in the moment, it was like the most logical [00:10:00] decision we could have made. I don't know how you could have avoided that. , and so I think when I think about campsite now, it's like, you don't really know what's going to be a mistake until later.
So the way I think about it is as long as we are building fast, learning fast, and not getting precious about any of the things that we've tried, uh, like we're pretty willing to cut features, delete things, uh, try and bring customers along for the ride as we do that. But we're just not precious about the thing that we've built.
Um, I don't know that we were ever super precious about things, , on Spectrum, but I think there was definitely a hesitation to cut features. And what ends up happening if you can't cut features is you just, the, the surface area of your product just starts to sprawl, even, even for a small startup, right?
It's just like more pages, components, flows, things to maintain. More bug [00:11:00] reports, which leads to more stress support queues and all this kind of stuff. When really like if you just cut the features that nobody actually cared about, your life would be a lot easier. So if I think about Spectrum, we probably didn't cut enough.
Campsite, we're cutting quite a lot and we're not, , shy about doing that.
Can you share an example or two of just like, yeah, what's a feature that you cut that maybe you would have been a little bit more precious about the first time around?
Why Brian removed his Linear integration
one of the things that we cut recently was we built an integration with linear and github where you could create linear issues and github issues from a post on campsite, and we heard this from customers. People told us they wanted it. They're like, while I'm giving design feedback to somebody, wouldn't it be nice if I could just spin up issues and assign those to the engineers on my team?
And even internally, we were like, yeah, that sounds great for us too. Like we're using campsite all the time. We use linear to create issues. Wouldn't it be nice if we could just create our own issues while we're using campsite? So we put a lot of time and [00:12:00] energy into building these integrations with lots of syncing and like keeping all of the fields up to date so that you can know what's open to closed and canceled.
I don't know. There's like a lot of edge cases in those APIs to figure out how to connect your organization, making sure people have the right permissions to create all this stuff, pull this energy in. And, uh, nobody used it. Like we looked at the numbers of issues created and it was like a handful. So we're like, okay, let's take another design pass at this.
It was a little bit buried in a menu. You had to go through one of those three dot overflow menus, create an issue. We're like, all right, let's lift that out. On to the campsite interface that on every post, there's a call to action, a button to create a new issue. So we did that. Nobody used it. We saw the number of teams connecting to get hub and connecting to linear going up, but nobody actually created issues.
So for us, we're like, this is a [00:13:00] lot of overhead for us to maintain everything added to an interface dilutes everything else. And so we cut it. Uh, we have, of course, all of the version history, if we ever wanted to restore any of that functionality. But we just deleted it and, uh, zero people complained, luckily, like nobody used that feature.
So zero people complained and we were able to simplify the interface. Maybe someday we bring it back, but we'll be a little bit more cautious. , when we do, I think in the, the user research, the understanding side, when people tell you they want something. Doesn't always mean they want it. , and that's, that's like the hard thing to tease apart, right?
There's just always a mismatch between stated and, and actual preferences. And I think the good designers and good researchers will be able to tease that out.
Obviously mistakes will be made as we made in this case. , but yeah, that's an example of something that we've, we've cut and I think it's worked out fine.
Why Brian removed his Linear integration
one of the things that we cut recently was we built an integration with linear and github where you could create linear issues and github issues from a post on campsite, and we heard this from customers. People told us they wanted it. They're like, while I'm giving design feedback to somebody, wouldn't it be nice if I could just spin up issues and assign those to the engineers on my team?
And even internally, we were like, yeah, that sounds great for us too. Like we're using campsite all the time. We use linear to create issues. Wouldn't it be nice if we could just create our own issues while we're using campsite? So we put a lot of time and [00:12:00] energy into building these integrations with lots of syncing and like keeping all of the fields up to date so that you can know what's open to closed and canceled.
I don't know. There's like a lot of edge cases in those APIs to figure out how to connect your organization, making sure people have the right permissions to create all this stuff, pull this energy in. And, uh, nobody used it. Like we looked at the numbers of issues created and it was like a handful. So we're like, okay, let's take another design pass at this.
It was a little bit buried in a menu. You had to go through one of those three dot overflow menus, create an issue. We're like, all right, let's lift that out. On to the campsite interface that on every post, there's a call to action, a button to create a new issue. So we did that. Nobody used it. We saw the number of teams connecting to get hub and connecting to linear going up, but nobody actually created issues.
So for us, we're like, this is a [00:13:00] lot of overhead for us to maintain everything added to an interface dilutes everything else. And so we cut it. Uh, we have, of course, all of the version history, if we ever wanted to restore any of that functionality. But we just deleted it and, uh, zero people complained, luckily, like nobody used that feature.
So zero people complained and we were able to simplify the interface. Maybe someday we bring it back, but we'll be a little bit more cautious. , when we do, I think in the, the user research, the understanding side, when people tell you they want something. Doesn't always mean they want it. , and that's, that's like the hard thing to tease apart, right?
There's just always a mismatch between stated and, and actual preferences. And I think the good designers and good researchers will be able to tease that out.
Obviously mistakes will be made as we made in this case. , but yeah, that's an example of something that we've, we've cut and I think it's worked out fine.
Advice for designers considering starting their own thing
I think there's probably a lot of people listening to this, that are designers and they have that idea. That's maybe the bug in their brain, or maybe they just have this desire to. Take some steps toward owning their own thing instead of just selling their time for money. And, you know, you've been in this seat for quite a while now.
So are there other pieces of advice you have or, uh, other ways that designers can prepare to be founders to avoid some of those challenges that you've faced either with spectrum or now with campsite,
I used to think everybody should start a company. Because I've always found it so valuable. Like my learning experience at Spectrum accelerated my career, both from a design standpoint, from a programming standpoint, from, just a product thinking standpoint, super valuable.
So I'm like, Oh yeah, everybody should do this. I've kind of come around the other side of that one. I'm not sure everybody should, what I think everybody should do if they're at least somewhat interested in taking that path [00:15:00] is. Start a side project and maintain it for like three months. Like, see if you can do that.
I think most people can't, , , and that's not because most people are bad or lazy or anything like that. It's like, I don't know. I've done this a million times. You know, you write the first blog posts on your website and you're like. I'm starting a new writing habit. I'm going to be posting weekly.
Subscribe to my newsletter. And then crickets. Right? Like, no posts after that. It's just hard to do something over and over again for an extended period of time. And that's kind of the startup game. It's just like failing every day over and over and over again until hopefully you're not failing. And so I recommend people just start with a side project.
Advice for designers considering starting their own thing
I think there's probably a lot of people listening to this, that are designers and they have that idea. That's maybe the bug in their brain, or maybe they just have this desire to. Take some steps toward owning their own thing instead of just selling their time for money. And, you know, you've been in this seat for quite a while now.
So are there other pieces of advice you have or, uh, other ways that designers can prepare to be founders to avoid some of those challenges that you've faced either with spectrum or now with campsite,
I used to think everybody should start a company. Because I've always found it so valuable. Like my learning experience at Spectrum accelerated my career, both from a design standpoint, from a programming standpoint, from, just a product thinking standpoint, super valuable.
So I'm like, Oh yeah, everybody should do this. I've kind of come around the other side of that one. I'm not sure everybody should, what I think everybody should do if they're at least somewhat interested in taking that path [00:15:00] is. Start a side project and maintain it for like three months. Like, see if you can do that.
I think most people can't, , , and that's not because most people are bad or lazy or anything like that. It's like, I don't know. I've done this a million times. You know, you write the first blog posts on your website and you're like. I'm starting a new writing habit. I'm going to be posting weekly.
Subscribe to my newsletter. And then crickets. Right? Like, no posts after that. It's just hard to do something over and over again for an extended period of time. And that's kind of the startup game. It's just like failing every day over and over and over again until hopefully you're not failing. And so I recommend people just start with a side project.
Reflecting on the Staff Design interview series
Can you talk a little bit about staff design then? That was a side project of yours. Was that where you thought you were going to end it? Or was there this [00:16:00] decision where you're like, you know what? This isn't something that I want to be consistent on. Like, how do you think about that project?
Yeah. So staff design was an interview series. I did eight interviews with. Uh, high level individual contributors, mostly just trying to answer my own questions about like, what is career progression for a designer who doesn't want to be a manager? It had always been a thing that bugged me. I can never figure it out.
I'd been thinking about it since my time at Facebook. And when I started that project, I knew that it was going to be a small compact standalone artifact. I didn't want another design details. I didn't want to do a weekly interview. So I did eight interviews and published them.
And I feel like I scratched my own itch. And hopefully scratched the itch for other people that had been wondering the same question. The thing that was tempting about staff design is I think there's a way to extend that series. Like, I think you could do like another season of eight interviews and like maybe interview managers, do [00:17:00] another season, interview design leaders, we could probably talk to illustrators, motion designers, , brand designers, and get a different lens on this, like, I see career progression. So that was always interesting. But I don't know, I interviewed people for years and years and years.
And it's just a lot of work. And so that staff design was really just a personal thing. I knew, knew it would be standalone and I didn't have any motivation to keep going.
A fun fact about staff design, which I actually didn't really plan on talking about is the way that you unveiled who you were going to write about was like the direct influence for how I originally unveiled the people behind
cool. Yeah.
you had the little pixelated, , faces and I was like, man, that is cool.
Copy paste.
It was, those were fun because people actually like spent time figuring out who the people are going to
Oh yeah,
some people have like a recognizable silhouette, you know, and their Twitter photo or something.
Yeah. I tried to do Joey banks and everyone immediately figured out cause he's like at the 45
mean, he's got the profile.
and I was like, all right, [00:18:00] whatever.
Yeah. Yeah.
Reflecting on the Staff Design interview series
Can you talk a little bit about staff design then? That was a side project of yours. Was that where you thought you were going to end it? Or was there this [00:16:00] decision where you're like, you know what? This isn't something that I want to be consistent on. Like, how do you think about that project?
Yeah. So staff design was an interview series. I did eight interviews with. Uh, high level individual contributors, mostly just trying to answer my own questions about like, what is career progression for a designer who doesn't want to be a manager? It had always been a thing that bugged me. I can never figure it out.
I'd been thinking about it since my time at Facebook. And when I started that project, I knew that it was going to be a small compact standalone artifact. I didn't want another design details. I didn't want to do a weekly interview. So I did eight interviews and published them.
And I feel like I scratched my own itch. And hopefully scratched the itch for other people that had been wondering the same question. The thing that was tempting about staff design is I think there's a way to extend that series. Like, I think you could do like another season of eight interviews and like maybe interview managers, do [00:17:00] another season, interview design leaders, we could probably talk to illustrators, motion designers, , brand designers, and get a different lens on this, like, I see career progression. So that was always interesting. But I don't know, I interviewed people for years and years and years.
And it's just a lot of work. And so that staff design was really just a personal thing. I knew, knew it would be standalone and I didn't have any motivation to keep going.
A fun fact about staff design, which I actually didn't really plan on talking about is the way that you unveiled who you were going to write about was like the direct influence for how I originally unveiled the people behind
cool. Yeah.
you had the little pixelated, , faces and I was like, man, that is cool.
Copy paste.
It was, those were fun because people actually like spent time figuring out who the people are going to
Oh yeah,
some people have like a recognizable silhouette, you know, and their Twitter photo or something.
Yeah. I tried to do Joey banks and everyone immediately figured out cause he's like at the 45
mean, he's got the profile.
and I was like, all right, [00:18:00] whatever.
Yeah. Yeah.
Three traits of design culture at Campsite
So I'd like to transition a little bit because, you know, you have just a lot of thoughts and insight on. , team process and how people work.
And I'd like to actually start with your process at campsite and like your vision for a design culture, because you have these, you know, this background at like robust, mature design orgs at GitHub and Facebook and. You're talking to all these teams, you're learning how they work. And now you kind of get this blank slate handed to you a little bit.
So when you look into the future, even , what are some of the defining characteristics that you hope to instill as far as how design operates at campsite?
There's sort of three points that come to mind for me. And There were these things that just emerged through the way that we worked and we talked about them and noticed them.
And people pointed out that, Hey, this is actually kind of interesting. , not every company [00:19:00] actually works this way. , so the first is on the team calls their shot. I know this sounds obvious, but actually a lot of people don't do this, which is say what you're going to do and then do it. A lot of people, , there's no accountability to even say what you're going to do.
It's like, cool, another week, just like just hacking on this. project, just going to make progress on it, going to work on this design. Like what, what work are you going to get done? , so the way that we've manifested that at Campsite, it's kind of gone through a few iterations. What we do now is we do a Monday kickoff and we just talk about what we want to get done this week.
, Friday we recap and I don't know, check in. How did it go? What did we miss? What's on deck for next week. And then every day we just post one very short bullet point list of things in Slack. We have a daily updates channel. And it's full points of things you want to get done that day, and that has been awesome. It's super helpful, , just to like, [00:20:00] say what you're going to do. And force yourself to be specific about it. Right. I think there's a lot of times that get how, where you'd start the week and be like, yeah, I'm just going to work on this project, but it's so abstract. Like, what do you want to get done?
What problem do you want to solve? What do you want to end the week? Having learned or figured out or completed. So being really specific about calling your shot and calling your shot in front of your peers, right? Like we're not writing this in our private journals. Like we're telling everybody else, this is what I'm going to get done.
So I like that. I guess you'd call this like a standup culture, but, like that flows into all of our communication. We post, , throughout the day, throughout the week in campsite, as we're making progress towards those goals, we bring everybody along for the ride.
, so that's the first point. The second point is we call it everybody shovels snow, which is basically saying like, you gotta do the.
And I think this is true for engineers [00:21:00] a lot, but also for designers too. Like, you know what, it sucks, but you gotta like tidy up your files. If other people are going to be in them, you gotta go through and like, make sure you're, I don't know, colors are correct and your types cracked and like, go through what the, , preview deployment looks like and actually bug hunt and actually look for misaligned things.
It's grunt work, it's not very fun, hopefully AI replaces it all someday. But we call this shoveling snow.
Uh, third thing, this comes from a blog post, and really just rallies around this phrase called radiating intent.
I think radiating intent, , is very similar to calling your shot, but it's more about doing. Then asking permission. It's like, I am going to do this thing. Speak up if you don't want me to do it versus, Hey, can I please do this thing? And that subtle shift is I think [00:22:00] what helps great teams move really, really fast.
You do by default and people speak up only when they notice something that's like really going to go off the rails or something that's really, , needs more conversation, but just doing by default. So we call that radiating intent. , .
I think
It comes through in your release notes too. Like y'all ship every single week. It seems, at least from the outside, my
Almost every week. Almost every week.
we'll call it every week. There seems to be a tempo at Campsite that I appreciate
Three traits of design culture at Campsite
So I'd like to transition a little bit because, you know, you have just a lot of thoughts and insight on. , team process and how people work.
And I'd like to actually start with your process at campsite and like your vision for a design culture, because you have these, you know, this background at like robust, mature design orgs at GitHub and Facebook and. You're talking to all these teams, you're learning how they work. And now you kind of get this blank slate handed to you a little bit.
So when you look into the future, even , what are some of the defining characteristics that you hope to instill as far as how design operates at campsite?
There's sort of three points that come to mind for me. And There were these things that just emerged through the way that we worked and we talked about them and noticed them.
And people pointed out that, Hey, this is actually kind of interesting. , not every company [00:19:00] actually works this way. , so the first is on the team calls their shot. I know this sounds obvious, but actually a lot of people don't do this, which is say what you're going to do and then do it. A lot of people, , there's no accountability to even say what you're going to do.
It's like, cool, another week, just like just hacking on this. project, just going to make progress on it, going to work on this design. Like what, what work are you going to get done? , so the way that we've manifested that at Campsite, it's kind of gone through a few iterations. What we do now is we do a Monday kickoff and we just talk about what we want to get done this week.
, Friday we recap and I don't know, check in. How did it go? What did we miss? What's on deck for next week. And then every day we just post one very short bullet point list of things in Slack. We have a daily updates channel. And it's full points of things you want to get done that day, and that has been awesome. It's super helpful, , just to like, [00:20:00] say what you're going to do. And force yourself to be specific about it. Right. I think there's a lot of times that get how, where you'd start the week and be like, yeah, I'm just going to work on this project, but it's so abstract. Like, what do you want to get done?
What problem do you want to solve? What do you want to end the week? Having learned or figured out or completed. So being really specific about calling your shot and calling your shot in front of your peers, right? Like we're not writing this in our private journals. Like we're telling everybody else, this is what I'm going to get done.
So I like that. I guess you'd call this like a standup culture, but, like that flows into all of our communication. We post, , throughout the day, throughout the week in campsite, as we're making progress towards those goals, we bring everybody along for the ride.
, so that's the first point. The second point is we call it everybody shovels snow, which is basically saying like, you gotta do the.
And I think this is true for engineers [00:21:00] a lot, but also for designers too. Like, you know what, it sucks, but you gotta like tidy up your files. If other people are going to be in them, you gotta go through and like, make sure you're, I don't know, colors are correct and your types cracked and like, go through what the, , preview deployment looks like and actually bug hunt and actually look for misaligned things.
It's grunt work, it's not very fun, hopefully AI replaces it all someday. But we call this shoveling snow.
Uh, third thing, this comes from a blog post, and really just rallies around this phrase called radiating intent.
I think radiating intent, , is very similar to calling your shot, but it's more about doing. Then asking permission. It's like, I am going to do this thing. Speak up if you don't want me to do it versus, Hey, can I please do this thing? And that subtle shift is I think [00:22:00] what helps great teams move really, really fast.
You do by default and people speak up only when they notice something that's like really going to go off the rails or something that's really, , needs more conversation, but just doing by default. So we call that radiating intent. , .
I think
It comes through in your release notes too. Like y'all ship every single week. It seems, at least from the outside, my
Almost every week. Almost every week.
we'll call it every week. There seems to be a tempo at Campsite that I appreciate
Finding the right level of craft
I think one of the problems with being a design founder is there's this temptation to just only care about the design to basically like. Care more about the design part of the design founder title than the founder part, which is like all of the other boring crap, like starting a company and paying your taxes and running payroll and all that kind of stuff.
This is a complicated one because I feel like there's all these interviews coming out now. Like obviously Lenny linear and Kari has been doing some interviews talking about craft and [00:23:00] beauty. And I nod along to all of those things, but linear has built a really great business. I think there's so many examples of apps where the founder also cared about craft and quality and design and beauty.
And we don't use any of those apps anymore.
So I see as a design founder and looking around other design founders, I do worry about. Making sure that I'm not over investing in the craft and quality, because as a designer, it's my job to like hold the line and instead of make sure that we're actually building a sustainable business, closing sales, investing in marketing and communications and making sure that the company is running smoothly, , internally behind the scenes, administratively, all that boring snow shoveling crap, you know?
How do you find that line though? Because I think your situation [00:24:00] is unique because you're not building this like commercial real estate app where. Designing for other designers to get the likes on Twitter would have absolutely no value. Like that is your target market in some ways. And so I could see a world where, Hey, I'm shipping for tech.
I'm shipping for people within tech that have taste. This is a competitive advantage that we want to lean into. You've done that a little bit. Like you can't say to me that you haven't pursued craft to an extent.
Oh man, I have spicy takes on this. Obviously it all depends on the stage that your company is at. There's like pre product market fit. There's growth and beyond. , We're in like the early pre product market fit.
We have paying customers, but still figuring out some of the core engagement loops. , so red flags would be designing your own custom icons. Red flags would be rebranding. Red flags would be, , designing your own typeface.
Let's talk about your website a little [00:25:00] bit. Cause I think that I could have seen a world where you set a bar, maybe similar to what diagram did, where they were maybe even an earlier stage as a company or similar, similar stage where they said, you know what, we're gonna try to break the internet.
Did you have that temptation?
Finding the right level of craft
I think one of the problems with being a design founder is there's this temptation to just only care about the design to basically like. Care more about the design part of the design founder title than the founder part, which is like all of the other boring crap, like starting a company and paying your taxes and running payroll and all that kind of stuff.
This is a complicated one because I feel like there's all these interviews coming out now. Like obviously Lenny linear and Kari has been doing some interviews talking about craft and [00:23:00] beauty. And I nod along to all of those things, but linear has built a really great business. I think there's so many examples of apps where the founder also cared about craft and quality and design and beauty.
And we don't use any of those apps anymore.
So I see as a design founder and looking around other design founders, I do worry about. Making sure that I'm not over investing in the craft and quality, because as a designer, it's my job to like hold the line and instead of make sure that we're actually building a sustainable business, closing sales, investing in marketing and communications and making sure that the company is running smoothly, , internally behind the scenes, administratively, all that boring snow shoveling crap, you know?
How do you find that line though? Because I think your situation [00:24:00] is unique because you're not building this like commercial real estate app where. Designing for other designers to get the likes on Twitter would have absolutely no value. Like that is your target market in some ways. And so I could see a world where, Hey, I'm shipping for tech.
I'm shipping for people within tech that have taste. This is a competitive advantage that we want to lean into. You've done that a little bit. Like you can't say to me that you haven't pursued craft to an extent.
Oh man, I have spicy takes on this. Obviously it all depends on the stage that your company is at. There's like pre product market fit. There's growth and beyond. , We're in like the early pre product market fit.
We have paying customers, but still figuring out some of the core engagement loops. , so red flags would be designing your own custom icons. Red flags would be rebranding. Red flags would be, , designing your own typeface.
Let's talk about your website a little [00:25:00] bit. Cause I think that I could have seen a world where you set a bar, maybe similar to what diagram did, where they were maybe even an earlier stage as a company or similar, similar stage where they said, you know what, we're gonna try to break the internet.
Did you have that temptation?
The flashy era of landing page design
Zero temptation. I think the diagram landing page is gorgeous I think the linear landing page is gorgeous, but i'm honestly so burned out with modern landing pages and what people think of as good design There is an obsession with bento grids where every box has a micro interaction that is insane.
And it's insane because it gets likes on Twitter. So people keep doing it because it feels good to get likes on Twitter. Every landing page is over invested in What's the micro interaction scroll animation we can add here? [00:26:00] Instead of how do we explain what our product does really clearly.
I'm not saying the campsite landing page is good. We're going to redo it soon. We could do way better job of telling the story. But I focused on like, there is a series of words that I want you to read as you scroll down the page. And the visuals are accompanying. Yeah. You might actually linger on those for a second, but I want you to leave the landing page, understanding what our product does and if it's going to be useful for your team, I'm tired of landing pages where I scroll through the whole thing.
Oh, it's pretty. I like screenshot it. I'm like, Oh, that was a nice interaction. That was a cool. Yeah, that was nice. Oh, I should , tweet that and get some likes. And I get to the bottom of the page. I'm like, I have no clue what this product does. , we're going to unlock creative collaboration for your AI generated team workspace.
Like what, just tell me what you
like, like the bento grid where you have these ridiculously [00:27:00] robust, beautiful animations, and then you have like 18 point font. With a title underneath this, like really big graphic and then like 14 point font with like 60 percent opacity underneath it. And I can't even read the text. I don't see any text.
I scroll it and I don't even see a single line of text.
I think we've gone too far. I think we'll pull back, but we are definitely in , the flashy era of landing page design. And Hey, if you do that and you can communicate really well, what your product does more power to you. If you're in a pre product market fit startup and you spent three months doing that, you wasted your time.
, and so that's where we are, like someday we will have a really flashy, gorgeous landing page. We're going to have the perfect brand. Just not now. , right now, like let's get people in the door and make sure the product actually works for them. , so that means, yeah, I think we did the current landing page in 24 [00:28:00] hours.
Which maybe it shows, I don't know, maybe people look at that and they're like, yeah, I think it's, I think it's fine. , but that's like the level of investment we wanted to put in right now. 'cause we're just all in on talking to customers and building the product.
The flashy era of landing page design
Zero temptation. I think the diagram landing page is gorgeous I think the linear landing page is gorgeous, but i'm honestly so burned out with modern landing pages and what people think of as good design There is an obsession with bento grids where every box has a micro interaction that is insane.
And it's insane because it gets likes on Twitter. So people keep doing it because it feels good to get likes on Twitter. Every landing page is over invested in What's the micro interaction scroll animation we can add here? [00:26:00] Instead of how do we explain what our product does really clearly.
I'm not saying the campsite landing page is good. We're going to redo it soon. We could do way better job of telling the story. But I focused on like, there is a series of words that I want you to read as you scroll down the page. And the visuals are accompanying. Yeah. You might actually linger on those for a second, but I want you to leave the landing page, understanding what our product does and if it's going to be useful for your team, I'm tired of landing pages where I scroll through the whole thing.
Oh, it's pretty. I like screenshot it. I'm like, Oh, that was a nice interaction. That was a cool. Yeah, that was nice. Oh, I should , tweet that and get some likes. And I get to the bottom of the page. I'm like, I have no clue what this product does. , we're going to unlock creative collaboration for your AI generated team workspace.
Like what, just tell me what you
like, like the bento grid where you have these ridiculously [00:27:00] robust, beautiful animations, and then you have like 18 point font. With a title underneath this, like really big graphic and then like 14 point font with like 60 percent opacity underneath it. And I can't even read the text. I don't see any text.
I scroll it and I don't even see a single line of text.
I think we've gone too far. I think we'll pull back, but we are definitely in , the flashy era of landing page design. And Hey, if you do that and you can communicate really well, what your product does more power to you. If you're in a pre product market fit startup and you spent three months doing that, you wasted your time.
, and so that's where we are, like someday we will have a really flashy, gorgeous landing page. We're going to have the perfect brand. Just not now. , right now, like let's get people in the door and make sure the product actually works for them. , so that means, yeah, I think we did the current landing page in 24 [00:28:00] hours.
Which maybe it shows, I don't know, maybe people look at that and they're like, yeah, I think it's, I think it's fine. , but that's like the level of investment we wanted to put in right now. 'cause we're just all in on talking to customers and building the product.
The biggest challenge for Campsite
You've mentioned this , pre product market fit era. A couple of times now, what are the biggest questions that you're trying to answer or de risk right now at campsite?
Holy shit.
What we're trying to figure out right now is how do you create a space where designers can share things at the right time with the right people, get the right feedback. And there's a very interesting paradox that happens, which is as campsite becomes more successful within a company, the harder it becomes to use. So here's what I mean. Imagine you're a five person design team and you spin up campsite for five [00:29:00] people.
The five of you start posting, everyone kind of knows what everybody's working on. There's a lot of shared trust, a lot of shared context, so you can just post whatever you want. It could be a scribble. It could be a lo fi mock. It could just be like some crappy screenshots, not framed, whatever. And you're just sharing and having fun.
Right. Then one day you're like, Hey, I just uploaded something that I need to show it to. An engineer, I'm going to show it to my PM. Oh, Hey, campsite has like free viewers and commenters. I'm going to like add them in and they can come and view and comment on this thing, rinse and repeat. And all of a sudden you have, , not just your five person design team, but you have your five person design team, plus an unknown number of viewers and commenters who could be anyone from the engineer that you work with every day to the CEO of the company.
When that happens, you no longer have a group with shared context as much shared trust. , and by the way, we're talking about like a five person design team. Imagine this is like a 500 person design team. It gets nuts. Right? , and so what happens is people get really anxious about posting. I think [00:30:00] designers right now, I think this has been exacerbated by remote work.
Are really anxious to show work in progress. , there's a lot of downside to showing work that might be considered unpolished or low quality, even if it's part of the process of getting to high quality, just having posted something that's low quality can be risky depending on the culture of the organization. So what are we trying to figure out? How do we actually help companies make that transition from being a place where the design team with a lot of shared trust can be posting, bring people along for the ride, having a lot of fun to also pulling in people from other functions in the organization while keeping anxiety low.
That is a really hard problem. But I think that's like the key problem that's the top on top of our minds right now is , the more embedded campsite becomes within an organization, the scarier it can become.
To use.
The biggest challenge for Campsite
You've mentioned this , pre product market fit era. A couple of times now, what are the biggest questions that you're trying to answer or de risk right now at campsite?
Holy shit.
What we're trying to figure out right now is how do you create a space where designers can share things at the right time with the right people, get the right feedback. And there's a very interesting paradox that happens, which is as campsite becomes more successful within a company, the harder it becomes to use. So here's what I mean. Imagine you're a five person design team and you spin up campsite for five [00:29:00] people.
The five of you start posting, everyone kind of knows what everybody's working on. There's a lot of shared trust, a lot of shared context, so you can just post whatever you want. It could be a scribble. It could be a lo fi mock. It could just be like some crappy screenshots, not framed, whatever. And you're just sharing and having fun.
Right. Then one day you're like, Hey, I just uploaded something that I need to show it to. An engineer, I'm going to show it to my PM. Oh, Hey, campsite has like free viewers and commenters. I'm going to like add them in and they can come and view and comment on this thing, rinse and repeat. And all of a sudden you have, , not just your five person design team, but you have your five person design team, plus an unknown number of viewers and commenters who could be anyone from the engineer that you work with every day to the CEO of the company.
When that happens, you no longer have a group with shared context as much shared trust. , and by the way, we're talking about like a five person design team. Imagine this is like a 500 person design team. It gets nuts. Right? , and so what happens is people get really anxious about posting. I think [00:30:00] designers right now, I think this has been exacerbated by remote work.
Are really anxious to show work in progress. , there's a lot of downside to showing work that might be considered unpolished or low quality, even if it's part of the process of getting to high quality, just having posted something that's low quality can be risky depending on the culture of the organization. So what are we trying to figure out? How do we actually help companies make that transition from being a place where the design team with a lot of shared trust can be posting, bring people along for the ride, having a lot of fun to also pulling in people from other functions in the organization while keeping anxiety low.
That is a really hard problem. But I think that's like the key problem that's the top on top of our minds right now is , the more embedded campsite becomes within an organization, the scarier it can become.
To use.
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Ⓒ Dive 2023
