Ryan Singer Head of Strategy at Basecamp

(Joel Beasley at 00:00:00) Today, we have on the show Ryan Singer, the Head of Strategy at Basecamp. And we discuss UI, UX, and how to make sure that a product provides value directly to the customer. We also get an inside scoop on how Basecamp runs their six-week development cycle. Ryan and I talk about staying ahead of tech trends and exactly how they do this at Basecamp. And we also debate Alexa and the future of voice.

(Joel Beasley at 00:00:31) All of this right here, right now on the Modern CTO podcast. Here we go. This is the Modern CTO podcast. I am so excited. First of all, I'm a huge fan of Basecamp.

(Joel Beasley at 00:00:51) I had my PR people that I have helped set up the show and get guests. I kind of just tell them that I want awesome experts in these subjects, and they go find people. So if I had known that they were going to talk to, you know, go get Ryan Singer at Basecamp, I'd have been like, nervous. I'm like, "No, don't talk to him. He's too important and busy. Like, don't bother Ryan."

(Ryan Singer at 00:01:15) So tell me a little bit about, you know, what are you doing here?

(Joel Beasley at 00:01:20) Yeah, right? It's kind of crazy. So I started out as a developer and became a CTO and then started working with different asset holding companies and venture capital, things like that. Being a CTO and, you know, acquiring different businesses and injecting capital. So I've been doing that for a long time and also a Ruby developer for many years. And yeah, so I learned all these things, and they kept coming up over and over—these lessons and, you know, CTO-related business things and everything that's on the track from developer to CTO. So I went out and I started looking at how many other developers CTOs were there were, and wrote, and I wanted to share and kind of give back.

(Joel Beasley at 00:02:04) And I found that about 60 to 80% of all the people that were the CTO badge were first developers.

(Ryan Singer at 00:02:11) Mm-hmm. Yeah, makes sense.

(Joel Beasley at 00:02:13) Blew my mind.

(Ryan Singer at 00:02:14) Yep.

(Joel Beasley at 00:02:15) So all of a sudden, this experience that I'm having that I feel is very rare is something many other people have.

(Ryan Singer at 00:02:21) Mm-hmm. Yep.

(Joel Beasley at 00:02:22) So I figured, all right, well, I'll start writing and sharing how I screwed up. Right? Because I'm the first one to stand up, raise my hand, and say, "Hey, look guys, I messed up, and here's what I learned." And hopefully that'll bring other people value. So I did that, and it did. And now people are reaching out like crazy.

(Ryan Singer at 00:02:38) So your audience is mainly people who are kind of in this intersection of developer background and currently in a CTO role?

(Joel Beasley at 00:02:48) Yeah. So we have lead developers, people that are in the middle of transitioning from developer to CTO, and then we have very experienced CTOs. Our first guest was Adrian Jura. He is a CTO of Epix Entertainment. They're one of the largest mobile gaming companies on Earth with 600 developers. So we have a wide variety of CTOs and developers, and I'm just looking to provide them value. So one of the things that comes up in my life in this role was designing, you know, products and interfaces. And so I figured, all right, well, that's a category that is something I know about. Like, I know enough to build a product, but I don't eat, sleep, and breathe it all day.

(Joel Beasley at 00:03:33) Why don't I bring on an expert? And he can kind of share some awesome tips with the audience about, you know, where he could provide value for designing best practices for UI, UX.

(Ryan Singer at 00:03:45) Cool. Okay. Well, let's see what comes out. I hope you have some questions.

(Joel Beasley at 00:03:49) Oh, I have plenty of questions. And so I'll start with a fun question. Have you ever raced Ferraris with DHH?

(Ryan Singer at 00:03:57) No. No. I wouldn't say I live in the high-end car racing sphere, you know. But I think it's pretty awesome that he does it.

(Joel Beasley at 00:04:10) Right? Those are well-designed, beautiful machines, so there's some symmetry there.

(Ryan Singer at 00:04:14) Yeah. No, I've made it around the track in a go-kart a few times, and that's my level of experience.

(Joel Beasley at 00:04:20) And you wear the title of Head of Strategy at Basecamp. Right?

(Ryan Singer at 00:04:25) Yeah. You know, that's sort of something I write when I need to fill in the title field. It's been hard to find, you know, kind of the right way to explain what I do. Basically, my background is in UI and UX. But, you know, by the very nature of the UI/UX role, you're on the one hand trying to physically shape the product. You know? So you have to have the technical capability to actually create some product. And on the other hand, you need to have understanding of market fit and what people are trying to do and what's valuable, both from the supply side and the demand side. So, you know, if you really kind of go deep down the UX, UI kind of rabbit hole, you know, and you really take it seriously, you come to a point where it's not about making pretty stuff anymore, and it's about getting a deeper understanding about what matters.

(Ryan Singer at 00:05:25) So I think that's kind of how I ended up more in a strategy position. But the output of my work is actually still mainly concrete concepts for here's what we could build, here's the rough outlines of what it could look like, here's technically how we think it's possible, and then giving that to the team so that it's something that they can implement and figure out.

(Joel Beasley at 00:05:51) Oh, that's super interesting. So I read your—well, actually, first, I was thinking when you were talking. Right? You said that you want to make sure, like, the product is close and brings value to the user. Right?

(Ryan Singer at 00:06:06) Mm-hmm.

(Joel Beasley at 00:06:07) And so I'm a firm believer that a business's job and the reason why they exist is to bring value to a market. Right? And so if you're a product company, it's important to keep your product's value. Because you don't buy a car. You buy the value of transportation. Right? So people don't buy your product. They buy the value that your product delivers to them. Would you agree with that or no?

(Ryan Singer at 00:06:32) Yeah. The question is, what is that? Because every product category has a sort of generic, off-the-shelf idea of what that is. So, for example, you just mentioned the car—that the idea is to get you transportation. You really start to dig into it, you'll find that the reason to buy a car can be very, very different. And it's very different depending on different parts of the market. And in the software world, it's the same thing. So you might think that people buy something like Basecamp to manage their projects. Um, but actually, it's more specific than that. People buy Basecamp sometimes when they can't grow anymore with the system they're using, or they buy Basecamp because they can't get enough accountability so that people follow through on the things that they're trying to get them to get done. You know? And if we were to just kind of say it's project management, that's too abstract, and it doesn't give us requirements to design against. But if we get to a point where it's like, you know what? We need to—there's people who need to be able to communicate faster in order to keep up with the demands of their growth. You know?

(Ryan Singer at 00:07:53) Like, they bring on a few more people or they take on a few more clients, and all of a sudden, digging through emails isn't viable anymore. That's a much more specific problem. Or the accountability thing. Like, how can I assign work to people and be sure that they know that I asked them to do it? I know that you know that I know that I asked you to do that, you know, and making sure that the thing gets done and following up on it in a timely way. That's hard to do when you make the transition from one person to three people or three people to 10 people. So those are the types of kind of very specific circumstances and outcomes that we try to understand, you know, so that we get to a point where—it's one thing to say it's about transportation or project management. It's another thing to actually understand specifically why these customers choose us out of the available set of options they have.

(Joel Beasley at 00:08:42) Oh, that's super good. So do you develop personas for these different groups?

(Ryan Singer at 00:08:51) So, you know, when I think of a persona, I'm sure some fancy design researcher might say differently. But, you know, if you just look around at the literature on personas, you're going to have a kind of make-believe person who has a lot of attributes. You know what I mean? So this person is maybe female, 30 years old, works in a certain role, has a certain amount of familiarity with technology, blah, blah, blah. Right? Or certain amount of domain knowledge or whatever it is. Right? It's a lot of attributes. And the thing is that if you think in terms of attributes, it doesn't help you because the real reason that people buy things isn't because of their attributes. It's because of the chain of cause and effect that they're in. It's because of the circumstance that they found themselves in and the outcome that they're trying to get to. So the fact that I happen to be, you know, whatever, 35 and living in Chicago doesn't explain why some nights I order pizza and some nights I go get steak. Right? The reason that one is appropriate at one time and the other is appropriate at another time is because of the circumstance that I'm in and the outcome I'm trying to get and the constraints that I'm under. So we want to go from a kind of demographic type of segmentation to a causal segmentation.

(Ryan Singer at 00:10:19) Right? And these are totally different worlds. So rather than having a kind of prototype set of attributes, I want to have a prototype circumstance and kind of chain of cause and effect. So that would look more like instead of, you know, it's a company with three people and in a certain industry, blah, blah, blah. It would be more like a company that is—there's the owner of a company, and the company is in a growth spurt. And they're using email to communicate. And they have some people who are not on—who are separated by time or space. So either they have external partners or they have people who don't sit around the same table all day or, you know what I mean? Some people who are remote, some kind of space-time separation. And because of the growth, they reach a point where they can't keep digging through emails anymore because there's more than they can handle, and things are starting to slip. And as they're trying to grow, they start to realize, you know, if we can't let things slip like this anymore, otherwise, we're going to start losing our clients. Right? So in order to maintain the level of quality that they had when they had fewer clients and fewer people, they need to up their game in terms of how they communicate. So they need some kind of a way to put everything into one place so that they can stay synchronized and everybody knows what's going on now that there's more happening. It's like that's a situation that's evolving through time where they need to make a change.

(Ryan Singer at 00:11:48) That's really what a market is.

(Joel Beasley at 00:11:50) So the attributes for the persona. And so I was asking, you know, how you guys use personas there, and you mentioned the attributes. And this is why I like talking to people because everyone has such different experiences, and different experiences breed different perspectives. Right? So my—the way I use personas. Right? So I primarily, my experience is with more niche, like, take a niche industry like legal or fitness or something like that, and then develop a product in a specific niche. You guys have a different experience because you develop systems that can be used in multiple places. Right? So it's more abstract in the situations that can be used.

(Joel Beasley at 00:12:35) But for me, the way I deal with personas is I look at how people are using the MVP. You know, let's imagine we have an MVP developed. I look at how they're using it, and the people I know are using it, and I develop personas around the actual users who are using it and how they're using it. So I don't say, like, oh—I don't look at them detailed first. I kind of look at them as relationship first. So I'll actually pluck the individuals that are using my software and develop the relationship with them, right? And then I will, you know, look in a pie chart and see how much of my population they make up. Right? So if we're doing like a legal software, and let's say I have a divorce attorney, right, because divorce attorneys use it, but also litigating attorneys use it. So I'll have a relationship with a divorce attorney or two, and I'll have a relationship with a litigator or two. And as I'm cycling iterations of the product, I will be involving them in the process, and that's how I refer to a persona.

(Ryan Singer at 00:13:37) I see. I think that makes a lot of sense, and that's helpful. The thing that I imagine you're doing implicitly is you're not saying that just because somebody is a divorce attorney that that automatically means something. You still need to make a step to figuring out how does the divorce attorney value it differently than the other type of attorney.

(Joel Beasley at 00:14:04) Correct.

(Ryan Singer at 00:14:04) Otherwise, you wouldn't be segmenting. Do you know what I mean? There must be some difference in how they value it or what kind of requirements they put on it.

(Joel Beasley at 00:14:14) Absolutely. Well, I segment as needed. Right? So if I notice that they're using it—and the way I do that is rather than necessarily waiting for the data to mature or to gather to be big enough just to get some valuable insights, I will instead just go directly to the person, develop the relationship, and I will segment based on the needs. Like, if they are using it differently, I will create them as separate personas. Right?

(Ryan Singer at 00:14:40) Mm-hmm. Mm-hmm. Yep.

(Joel Beasley at 00:14:42) We have a question.

(Ryan Singer at 00:14:45) Yeah. Let's take one. Sure.

(Joel Beasley at 00:14:46) Super pumped. All right. So Miles Cook says, "Can I ask Ryan, how do you prioritize developments? Is it hard to find the best, most efficient path in line with marketing initiatives, technical roadmaps, finance stakeholders? He's always thought that the optimum strategy is when all the stakeholders, including tech, are locked into a room a few times?"

(Ryan Singer at 00:15:07) So, you know, there's a lot to that question because you have to look at how does resource allocation actually happen. So at Basecamp, we work in six-week cycles. And we start off a cycle, and that means that there's going to be a few dedicated teams. Our teams are very small. And those teams are going to take on some projects. Those projects are going to take no longer than six weeks because that's the cycle. At the end of the six weeks, something is going to ship. And they will do nothing but that thing. They have complete dedicated focus on that, which, by the way, is pretty rare. So before a cycle starts, we have to figure out what to spend that kind of time on. Right? Which projects are we going to take on and what are the teams going to do? And that is—we only look ahead to the next six weeks, and that gives us some constraints. So whatever we pick off has to be doable in that amount of time. We're going to look at who's actually around. You know? For example, some people might be on vacation. Some people might have just wrapped up a really challenging project of a certain type. So we're going to look at who's available. And then we're going to see, like, out of the long, long, long menu of things that we could all think up to do, kind of what are the things that are most valuable and also most fitting to what we have available right now.

(Ryan Singer at 00:16:38) So that already actually narrows it down a lot. And then each of us—Jason and David and I—pretty regularly, we'll get around a table before a cycle starts. Sometimes Jason will have a bunch of ideas. Sometimes I'll have a lot of stuff to bring to the table.

(Ryan Singer at 00:16:57) It can be different each time. But then we just have a conversation about here's the things that we think, here's the things we learned about that we think are broken or a problem that we think need some urgent attention. Sometimes those things exist. Sometimes there isn't anything like that, and it's more like, here's the thing that I've been thinking about for the last few months, and I finally got to a really clear concept. I think we can finally fix this part of the app that none of us have been happy with for six months or something like that.

(Ryan Singer at 00:17:25) Right? It's different every time. So that's how we do it.

(Joel Beasley at 00:17:31) That's awesome. Yeah. That sounds, I really like how you guys sit back, you segment it into the six week cycles, and then you say, alright, well, what project are we gonna pick off? What are we gonna knock out? What value are we going to bring to our own business and then to the market in these six weeks? And then the fact that, I agree 100% when you said that it's rare, because usually companies look similar to a Chinese fire drill, right? Just everyone going crazy, everything, starting projects, dropping projects, and completing projects.

(Joel Beasley at 00:18:00) So I like that you guys have that six week rhythm.

(Ryan Singer at 00:18:03) Yeah. It works really well. And the other thing too is that we really do, it's not six weeks of chipping away at something and then continuing for another six weeks. There's a lot of people who run agile type processes where they're using a cycle just to chip away at something, and then it kind of loses its meaning. We use the cycle as a budget.

(Ryan Singer at 00:18:26) If we only have six weeks, then that's gonna lead us to make different decisions, both in terms of what we choose to bite off, but also how we make cuts and scoping changes and requirements changes during that six weeks. Because the only way that we're actually going to ship something at the end of the six weeks is if we adjust our plan as we go and actually drop some parts and kind of change our focus throughout the process. And without that deadline, without knowing that we actually have to release something, that's not gonna happen.

(Joel Beasley at 00:18:58) Right. Well, the constraints in anything in life, constraints, they create creativity. Right? If you have a cycle and you have six weeks and you have a goal, then you have to, it activates everyone's creative aspect of how do we achieve this, and that will create an entirely more creative, interesting product and end result. So I was reading your Fidelity Curve, when it comes to the mock ups and everything that you wrote about.

(Joel Beasley at 00:19:26) And I love that you started off the article, you started off very well, by the way, saying that it's not black and white. And that's what I get a lot too. People ask, you know, what program do you use? How do you do it all the time?

(Joel Beasley at 00:19:38) And for me, a lot of similarities. You wanna just talk a little bit about that, how you guys do your wireframes and design?

(Ryan Singer at 00:19:47) Well, so in general, we're skeptical of anything that's not the real thing. So a wireframe is not gonna produce a lot of confidence, and an actual spiked prototype, like, built in real code that's rendering in the browser, that's something that's gonna inspire confidence. So the closer to the real thing it is, the more we're gonna believe it. And the further away it is, the more it's kind of somebody's intention or somebody's hypothesis.

(Ryan Singer at 00:20:20) So that's just the main theme of the article. And we have to communicate at a high level with sketches when we're first working through an idea. But what we try to do is get to spiking some real code and some real interface elements as soon as possible because that's the only way that we're really going to figure out what this thing is.

(Joel Beasley at 00:20:43) I agree. We have another Facebook question. They wanna know, how do you keep people that you work with, how do you keep them motivated when things aren't getting done or just in general?

(Ryan Singer at 00:20:54) You know, I wouldn't say that we have that problem. I love it. Yeah. I'm not exactly sure where to attribute that, but we have a few things that I think are working well for us. First of all, if you actually give people the time to do what you've asked them to do, then that's a completely different situation than most working environments.

(Ryan Singer at 00:21:19) In most cases, you get tasked with a project, but then you get interrupted all day from people in other departments. People from support, people from sales are tugging at your shoulder asking you to do stuff, and you're kind of squeezing in your real work. And we don't have that culture at Basecamp, and we don't have it because we've been very intentional about not having it.

(Ryan Singer at 00:21:39) So when a team is asked to work on a project, they're left alone completely. Nobody has a license to interrupt them. And they're not being called into meetings. There's nothing for them to do other than work together on the thing that they're taking on.

(Ryan Singer at 00:21:57) So that already makes a huge difference in productivity and morale. And then the second piece is we have a culture of shipping, so we expect to ship every six weeks. And it's extremely rare that we don't. And on the occasions when we don't, we look really hard at that and debug it and make sure that we don't repeat the same mistakes. So we're all working really, really hard at shipping, which means, actually, that everybody gets the satisfaction of feeling like they did something.

(Ryan Singer at 00:22:32) Shipping gives you that celebratory moment. It gives you that feeling of accomplishment. It shows work. It's real work. It's not just showing up again and chipping away at a list somewhere.

(Joel Beasley at 00:22:46) Yeah. When you're, so you have these six week cycles, you have a team, they don't get bothered. What's the composition of that team?

(Ryan Singer at 00:22:54) So, fundamentally, the team is a designer and a programmer, and that's how it starts. In some cases, we have one designer and two programmers, but it's basically like that. And then after they have some stuff that's built, then also, usually, one QA person will come in and start helping to test all the edge cases and look at lots of different browsers and stuff like that. And that's fundamentally it.

(Joel Beasley at 00:23:24) I like that it's lean. So I get a variety of individuals and experiences that I've had with going into other companies. In some companies, you'll actually see some of the business people, they think more is better, so they want a larger volume of developers. And I find myself more often than not chipping back at saying, no, we want higher quality people, smaller, leaner teams, and that's gonna be the better product. Case in point, healthcare.gov.

(Ryan Singer at 00:23:51) The challenge is that you need to have people who are a bit more of generalists in order to accomplish that. So, for example, we don't have anybody in the company who designs but doesn't code because that just doesn't work. You can't have small teams and short cycles if you have a translation process or a wall that you have to throw things over where somebody is making a visual design and somebody else is coding it as a front end view. We don't have that separation anywhere in the business. So that makes a huge difference.

(Ryan Singer at 00:24:20) The other thing is that the technical choices have a huge impact on whether or not you can actually do this. You simply cannot do this unless you're working in a highly productive programming environment, and that's the main motivation behind Rails and now Stimulus, the new JavaScript framework that the guys just released.

(Joel Beasley at 00:24:40) Wait. What is this?

(Ryan Singer at 00:24:41) There's a new JavaScript framework that just went online that David and Sam and Jovan worked on here, and it's in the spirit of Rails. If you look it up, you'll find it. It just went online within the last couple days. But these technical decisions, these frameworks that we're using, they're critical for our productivity. We couldn't work in small teams without them.

(Ryan Singer at 00:25:08) So I think it's important not to just tell people to have small teams because if you have a big, gnarly stack, you're not gonna be able to work in a small team. And if you have a wall between visual designers and front end engineers, you're not gonna be able to have a small team. And it takes a lot of conscious effort to put those conditions together so you can do that. But, man, when you do, it's really rewarding.

(Joel Beasley at 00:25:36) I agree. Yeah. We develop apps. So I have a company. That's how I fund this whole thing. Like, so there's no ads on the podcast. There's nothing to buy. There's nothing like that. We just, I wanna give value to other people, so I just use the profit from my app company to roll into here. So that's how I deal with it over there is I keep everybody in small, tight teams, but they're all, like, uber experts.

(Joel Beasley at 00:25:52) And the only way the thing that gives me the edge is that I've been writing code for fourteen plus years. So when I go and I meet with people on a business side of things and we're going back and forth between what's possible, I'm real time able to calculate effort and cost in my head. And there's no going back. There's no two business people meeting them, going back to their separate camps, and then coming back and then saying, oh, it is possible. This is the thing. I can give real time interaction. I wanna know team composition, typically design a program, highly skilled people.

(Joel Beasley at 00:26:31) You reduce the points of communication by having people that can write code and design and all those great things. When does it hit marketing and communication that you got, like, how do you, where does it in the cycle? Does it hit inside of the six week cycle, or is the six week cycle only building? How does it get communicated what you did?

(Ryan Singer at 00:26:49) Well, we don't really have marketing. So we have one guy who takes care of basecamp.com and our sort of marketing website. Just one person, and he's fantastic. And then we have kind of a routine where usually the designer who worked on the project writes up the announcement. And then sometimes, if it's a smaller project, then we've got some great writers over in support.

(Ryan Singer at 00:27:23) We're not too tightly defined in terms of who can do this and who can't, but somebody will write up an announcement on the day that the thing ships on our blog and says, hey, this is this new feature. Here's what you can do now. Here's how it works. And then we have a kind of an in-app announcement area.

(Ryan Singer at 00:27:46) So when people sign in to Basecamp, they'll see a kind of a yellow bar at the top of the screen, and that will link them to the blog post that explains the new feature. And that's basically it.

(Joel Beasley at 00:27:57) Are you leveraging any of your six week cycles? Have you played with or leveraged at all any sort of machine learning?

(Ryan Singer at 00:28:03) We don't have any problems that call for machine learning right now.

(Joel Beasley at 00:28:08) So have you, you personally, have you experimented or played with it at all?

(Ryan Singer at 00:28:12) Yeah. I'm familiar with it. I've played with it a bit on the analytics side, but we don't currently see any kind of connection between what we need to do for our customers and what machine learning does on the supply side.

(Joel Beasley at 00:28:28) Excellent. For an individual that is a developer and they're listening to this and they, let's say, let's give some, let's make up a situation. Right? Let's say there's a developer who's wearing the CTO label, and he's working on a single product right now. And he is getting ready to ship it or he just has shipped it, and he's pretty much the only person involved. He's maybe working with a designer, but he's mostly just him or her building this product.

(Joel Beasley at 00:28:56) What sort of ideas or what's the most valuable advice you'd give that person in relation to UI, UX, product design, life cycle, anything?

(Ryan Singer at 00:29:08) I would say that the main thing to focus on is what we have a, we have a term in the UI world called affordances. So the affordances are the things that you can act with. So like, the buttons, the scroll bars, the links, the way that you can collapse and expose something, so all the interaction points. And the real kind of meat of an interface and a user experience is actually the placement of the affordances and then the processes that you can move through by using those affordances. And everything else, you know, the visual style, the colors, the fonts, and stuff like that, that's all just a layer on top.

(Ryan Singer at 00:30:08) And what happens very often is when people start talking about design or UI, it's so easy to get distracted by the visual kind of graphic elements. And those are important. If you don't figure those out, then it's not gonna look right. It's not gonna feel right. It's not gonna be attractive to people, but it's not the bones. It's more like the clothes. And the bones are the affordances and what we call the flows. And so in order to judge those, you can't, you don't look at a, you know if you wanna judge whether the door opens or closes, you don't look at what type of metal the knob is made out of.

(Joel Beasley at 00:30:55) If you're reading my mind just so you know, I have a Google doc open. Right? I'm gonna break from this for a second. I have a Google doc open. Okay?

(Joel Beasley at 00:31:02) And I'm writing affordances, buttons, scroll bars. And then as you're talking, I'm sitting here saying, alright, oh, it's like a doorknob, and it's more like the placement of where the knob is in relation to the door versus the material. And then as I type that, and then you say that. You say, you start talking about doorknobs, and I'm like, whoa, what is going on?

(Ryan Singer at 00:31:21) The classic example. Yeah. It's totally classical. If you read any kind of text on this subject, these are the door handles and handles on teapots and stuff like that are what everybody talks about.

(Joel Beasley at 00:31:33) Really?

(Ryan Singer at 00:31:34) And, um, yeah. Yeah. It goes back to a book called The Ecological Approach to Perception or The Ecological Theory of Perception, something like that. It's by J.J. Gibson. And he's the one that really cracked this thing open. And it's very, it's the point of view, really, for doing interaction design.

(Joel Beasley at 00:32:00) Interesting.

(Ryan Singer at 00:32:01) Because it's the question of not designing visual experiences. It's a question of affording actions.

(Joel Beasley at 00:32:11) Right.

(Ryan Singer at 00:32:12) Right? What can happen, in what order, and then how do you do it? And it's more about the wiring. So in my mind, and maybe this is something that developers can relate to more than people who have a sort of a more artistic background, is when I think of an interface or UI design, I kind of imagine a whole bunch of audio components connected with patch cables. And they could be just in a big pile in the middle of the room, and then you have all these patch cables to connect things in the right way so that you get the signal processing you want to get the sound to come out.

(Ryan Singer at 00:32:47) And this is a really good metaphor because, honestly, the way that things are connected—the topology—is much more important than the kind of the 2D arrangement and the colors and the styles and stuff like that. Yes, you need the 2D arrangement. Yes, graphic design is valuable. Visual design is valuable. It's essential.

(Ryan Singer at 00:33:08) But it's not the thing that's going to make or break it when you're thinking about whether you functionally do the job or not.

(Joel Beasley at 00:33:17) Right. And there are way too many boardroom executive hours wasted in meetings arguing over what color the button is.

(Ryan Singer at 00:33:25) Right. Well, we have that too. You know, we also debate about, you know, the font is a little bit too thin or too thick. I mean, like, we have all that stuff too. The difference is that we don't allow it to block us from making progress, you know?

(Ryan Singer at 00:33:40) I mean, like, we're all human beings, and we get into the same debates, and we all care about the same things and stuff like that too that anybody else does. The difference is that we don't let it get in the way. One of the things that I wanted to add on, you know, when it comes to how should the CTO developer think about UI. So there's the affordances and the flows. That's the thing to think about. And then the other piece is, how do you actually judge whether the affordances and the flows are right or not? And that is the way to think about that is in terms of fitness. So you want to think of it as a fitness function that you have somebody on the demand side, so somebody who's wanting something, who's trying to get somewhere, who's trying to do something. They are in a process of cause and effect. They're trying to do something, and then they're going to come to the tool, and your tool is either going to enable that or hinder that, or it's going to afford that or it's not.

(Ryan Singer at 00:34:43) Right? So the way to figure out if the tool is doing the right thing is to look at the flow of what the person is trying to do kind of outside of the product, like, regardless of the product. You know, you have to kind of make the thing that they're trying to do sort of the fixed parameters, you know, and then the requirements of the things that you're going to allow to change to say, "Okay, what does this feature actually need to do in order to deliver on that?" You know? So it's really about—it's about that coming back to that kind of the causality instead of the attributes. Right?

(Joel Beasley at 00:35:24) Right.

(Ryan Singer at 00:35:25) It's not enough just to think that it's the divorce lawyer versus the other kind, but that what is it about their circumstance that defines what they're trying to do and what's valuable right now?

(Joel Beasley at 00:35:36) Correct. Have you come across this book called Inspired by Marty Kagan?

(Ryan Singer at 00:35:44) No, I haven't seen that.

(Joel Beasley at 00:35:46) My buddy Derek lent it to me, and I started flipping through it. And I don't know. I just got a lot of good information. I haven't read the ecological one that you mentioned, but I'm assuming most of the stuff when you read it, you're like, "Yep."

(Ryan Singer at 00:35:59) Yeah. You know, the books that had the biggest impact on me were the ones that took me years to understand. And anything that I read that I just say "yep" to, I actually kind of throw away because it's not giving me any value if it's not challenging me. Right. You know, because I can look in a mirror any day and see what I look like today and then be like, "Okay, there I am." You know what I mean? But to run into something that I don't understand that seems to kind of hold something worthwhile, that's where most of the growth has come from. So, you know, I remember picking up that Gibson book, I don't know, 15, 20 years ago and being like, "Man, this is like, what is this about?" Right? This seems important and I don't really understand it, and really, really chewing on that for years. And the same thing with, I learned a ton by studying Christopher Alexander's work. He was a big inspiration for the way that we emphasize kind of—so he's coming from the architecture world, and his main thing is that he doesn't believe in blueprints as the way to design. He thinks that you need to actually go to the site and stand up pieces of wood and put pieces of cardboard around to figure out in the actual space, in the real location, kind of, what the right arrangement is and what the right configuration is. And then after you figure that out, then you draw a blueprint to record that, which is a total opposite thing. You know? And so, but these things, you know, it's like some of these things, they really—you spend years going back to the same books and learning. That's those are the things that have the biggest impact.

(Joel Beasley at 00:37:43) Yeah. I find that there's things I've learned, principles or concepts that I've learned, and they mean something new to me every two or three years, like, layer on top of them. We have another question from Facebook here. He wants to know how much time are you spending looking outside? Like, we all know that we look at inside, how our customers are using our product and the value we want to bring them. But how do you balance that with looking outside at, you know, maybe what competitors or other trends, like, different solutions that are coming out? How do you look at the outside world? How do you balance that?

(Ryan Singer at 00:38:17) I don't think it's very relevant. For the most part, the real challenge is fitness. Is, like, can I understand the—there's some market of people who buy Basecamp. And I want to understand that. And the more that I understand that, the more that I can stop doing things that take us in the wrong direction, and I can do more things that put us in the center of that. And the more things that we figure out and get right, the bigger our moat is. Because, actually, it's a kind of a fallacy that you can just copy another piece of software. There is so much hidden complexity in all of the decisions, especially something that's been kind of running for years. You know? It's a very, very high-dimensional space that has been kind of finding its fit over years and years and years and years. And that's hard to copy. So I think that kind of our competitive advantage is our depth of understanding of our customer.

(Joel Beasley at 00:39:38) Understood. No, thank you so much for—oh, I have one last question I want to ask you. Sure. Voice. Okay. So what—agree, disagree. I think voice is the future, all right, of interacting with these devices such as the HomePod, Alexa, Google, the soon-to-be pod if it ever gets released. But I feel bad for their product teams over there. I don't know. They need to adopt your six-week cycle or something. But because they haven't been able to get the HomePod out. Yeah. So big fan of it. Have you guys any plans to run one of the six-week cycles on voice interaction updates for Basecamp skills or anything like that?

(Ryan Singer at 00:40:19) I have not yet run into a really compelling situation where I feel like we're not doing the job because we don't have voice. I think I think we could think of a whole lot of, like, "it would be cool if" kind of situations. You know? For example, maybe it would be cool to just say, like, "Hey, Basecamp, has anybody updated the to-dos on blah blah blah yet today or whatever?" You know? But but I feel like I'm totally making that up. No. No. No. I don't have any—

(Joel Beasley at 00:40:55) It's effective. I—so I'm for—I love it. So I don't think that you have to do everything.

(Ryan Singer at 00:41:03) Right. But the—but no. But my question is, I don't understand the circumstances under which it's effective where somebody says, "If this isn't there, this isn't doing it for me." Like, it's not enough to say it's good. It needs to be necessary, and it needs to be important so that we do it instead of other things. See, that's the thing. That's the thing. You know? And voice is never going to take over.

(Joel Beasley at 00:41:29) I did—I just—

(Ryan Singer at 00:41:30) Voice is going to—it's not going to take over because the amount of—there are a whole big set of tasks that you can only do with your eyes. We're talking about, like, human biology here. I mean, a huge chunk of our brain is dedicated to working with visual input. So, for example, when you use your eyes, you can see lots of things at the same time. But when you use speech, everything has to be segmented through time. You can only have one thing at a time and things have to happen in sequence. This is a huge, huge difference that vastly separates different types of task domains because you can't do some things sequentially. I think if you—no. That doesn't mean that there isn't edge. I think there's a huge—no. But I think there's a huge amount of non-consumption. I'm sure that there's a ton, ton, ton of use cases for voice that are going to come up. Right? So I'm—because we haven't really had computing in that domain. Right? So all kinds of use cases are going to appear, and I'm sure that there's, like, tons of businesses and big money to be made, but that doesn't necessarily mean that there's an either-or relationship here. It could totally be a both-and relationship where you have a ton of growth in the voice side of things. But at the same time, you have also a ton of stability on the visual side of things.

(Joel Beasley at 00:42:58) So I agree with how you're talking about that you guys are developing what's necessary and what's effective, like, 100%. Do you believe that there's any room in your sort of, like, pie chart allocation of resources for a cycle on the future or a cycle on what's coming next or some sort of like, 80—let's say 95% of your development time is spent on everything, bringing the current value and everything like that. But do you allocate any sort of budget of your time?

(Ryan Singer at 00:43:28) Yeah. I don't see any difference there. Like, everything we do is the future. Everything that we that we haven't built yet is our vision of the future. And every six weeks, we have to make an allocation decision. You know what I mean? Like, so whether it's something that the tech world is excited about or whether people feel like it's a big new wave, whatever it is, it's competing with a lot of other really good ideas that we have that the tech press isn't writing about that we think might be the future. You know what I mean? So for example, like, this new JavaScript framework that the guys put out called Stimulus, you know, this is not in sync with what everybody thinks the future is. It's a totally different point of view on how to do a JavaScript framework. And but for them, it was the future.

(Joel Beasley at 00:44:20) Right.

(Ryan Singer at 00:44:21) And I think that that to me is way more interesting than—

(Joel Beasley at 00:44:24) But you do allocate time to—I mean, that I would say that that's—we're on the same page. We're just—it's semantics. Right? Like, that would be, in my mind, you guys allocating towards what the future is. You know, rather than allocating the time towards trying something that you hear about in the future, you allocate towards time to building something that will be available in the future. But not directly connected to your product. Right?

(Ryan Singer at 00:44:43) It is directly connected to the product. Everything we do is connected to the product. We don't do anything that isn't something we're going to sell. And the thing is that sometimes, you have something that you want to build, and you don't like the way that you build it, or you don't like the tooling you have, or you feel like the tooling that's available is a hindrance for you. So so then so then you might you might make an advance in terms of the what you're doing on the supply side, but but it's in the service of building the product.

(Joel Beasley at 00:45:16) No. I think we agree on a lot of these things. With voice, I believe one day, it will come up in your six-week cycle as something that is important enough to be the thing that you choose to work on, even though it's not today.

(Ryan Singer at 00:45:32) I could imagine that. I'm open to that possibility. But we—because we look at it every six weeks, we are in a very good position to respond to that.

(Joel Beasley at 00:45:41) And that that's what's so beautiful about your six weeks stuff. I'm hitting it from every angle, man. I'm sitting here boxing it left, boxing it right, and I'm like, "Damn, this is a solid methodology." You know, I'm just—it works. Sitting here brainstorming, and, you know, I'm doing it for everybody, including myself. And I love how solid it is. And but here's the one point I have for voice. Okay? It is something you can do passively in the sense that it is something you can do when you can't look at a screen. So it's something I could do on a commute. It's something I could do while showering. While I'm showering, I could say, "Hey. What's—you know, give me an update on my Basecamp stuff." When I'm in the car driving, I could say, "Give me an update on my Basecamp stuff." There's—

(Ryan Singer at 00:46:19) Yeah. But that's against our values. We don't want people to work more. Like, we don't want people to be squeezing more and more moments out of their day when they could have had some peace of mind, and now they're checking in with their Basecamp. Like, that's—we don't want that's not the future we want to live in. I would much rather enjoy the shower and enjoy the drive and then and then open my laptop when I get to work because now it's time to work.

(Joel Beasley at 00:46:46) That's subjective to you. All right. Like, so here let me—I want to counter this. I have time in my life. The amount of time it takes me to tap my iPhone to make it unlock it, to flick it open, unlock it, to go and check the task is much longer. And I don't want to say three times because I haven't actually measured it. I'm not that guy. So that that is a time away. It's stealing time away from me, whereas as opposed to without walking over, grabbing my phone, unlocking it, opening the app, looking, scrolling, tapping to see where we're at, I could just say, "Hey, Alexa, where we at on the Jones project?" So I actually gained time, and that would actually be for your values. So it's all perspective. Right?

(Ryan Singer at 00:47:28) No. You're you're speaking at a level of generality that isn't actionable for an actual business. So the thing is, like, we can't just say saving time is good or having less time is bad or whatever. It's a question about, like, they—there's a sweet spot for what's valuable, and too slow isn't right, but also too fast isn't right. And the thing is that we need to understand what the what the range of kind of target values is, what's that sweet spot.

(Joel Beasley at 00:47:58) All right.

(Ryan Singer at 00:47:59) And and that's something that every business kind of gets to choose for themselves and compete on. You know? So we so we have our ideas about the sweet spot, and we would have to have, I think, a significantly deeper discussion to get into the concrete details of every use case and so on to really talk about that. You know?

(Joel Beasley at 00:48:19) That wouldn't even be that productive. There wouldn't be much. Like, you know, we can get into the details of it, but it's just like, you know, every—it's similar to, like, the band thing. Right? Every band, they have their song. They form their band. They decide what's right for them. And then everyone gets along with all the other bands. Right? Everybody's just kind of, you know, doing their thing, bringing their value. And I love what you guys are doing. I believe that the way you structured and your experiences and all of this is, like, tremendously valuable. So I sincerely appreciate you sharing with this.

(Ryan Singer at 00:48:52) Sure thing. Yeah. No. The thing that I'm trying to emphasize here is not that you and I should come to the same point of view on it, but rather that your listeners who are in decision-making roles, that they should not be satisfied with generalities that, like, fast is good or something like that, but that they should come to a definition of the sweet spot for their market, for their product that's specific to what they're doing. Just I'll give you one quick example before we wrap up here.

(Ryan Singer at 00:49:25) We were tracking the amount—so, actually, Jason and David talked about this. We have a podcast now called Rework, and they answered some questions on the most recent episode, and they were talking about this example. We were optimizing the response time from our support team for a while. And the thing was that faster was better. You know, when you go from one day to ten hours to five hours to two hours, it's better, better, better, better, better. But when you start to get to is it a ten-minute response or a five-minute response or a two-minute response, you start to create a really painful environment where there's unnecessary stress. You know, getting to that two-minute mark is hard on people, and it's not necessarily valuable. So that's exactly the kind of thing that we want to look at in everything that we're optimizing and say that this is a bell curve. It's not just an open-ended rising thing. You know, and we need to figure out where on the x-axis the center of that thing is.

(Joel Beasley at 00:50:36) I fully agree. Over-optimization can be a huge problem just as over-engineering can. That's very valuable advice. Like, so would you say that is just finding your rhythm, being aware of the fact that it is a bell curve and not to just beat yourself up for speed for speed's sake?

(Ryan Singer at 00:50:55) Well, it's about being conscious of what your goal is. Right. If you just think more is better, that's not a goal. That's a stiff policy that's not connected to an understanding of reality, because nothing's like that. There's no system where more is just better. Everything has a limit where it becomes something else.

(Joel Beasley at 00:51:15) Yeah. Law of diminishing returns too. Fantastic. Thank you so much, Ryan.

(Ryan Singer at 00:51:21) Thanks a lot. Yeah. Happy to be here.

(Joel Beasley at 00:51:28) Thank you so much for listening to the Modern CTO Podcast. Share this. Get the word out. Thank you guys so much. I couldn't do it without you. I appreciate it. You guys are the absolute best.