Ep. #4, Building on Quality at Heroku

Fred Stevens-Smith: Hello, podcast listeners. Today I'm joined with my friend James Lindenbaum. James is the founder of Heavybit, which is the thing that does this podcast. Great description of Heavybit. And also was one of the founders and CEO of Heroku, right up until five minutes before it got sold to Salesforce, as he just said. So hello, James.

James Lindenbaum: Hello.

Fred: We had a little chitchat before, and we kind of think we have some ideas of what we want to talk about here. You said that one of the real obsessions for you so far, professionally speaking, has been quality.

James: Yeah.

Fred: So what do you mean by that? Do you mean quality assurance, like RainforestQA could help you with? Or are you talking quality in very broad terms? What does that mean for you?

James: In the broadest term, quality in terms of the quality of what you produce, the quality of your work. So not so specific to QA. QA is certainly a way to achieve some parts of that, but I think that's one of those things that's personal.

What does quality mean to you? I'm a very design-minded person, craft-minded person, and so to me, quality has a lot to do with those ideas.

The question is always, how much is enough? That's always the problem. And how do you define quality? That's always a problem, too.

It's very hard to strive for quality. When you do, you often end up in this situation where you're pushing somebody, saying we need more quality, and they're saying, "What does that mean?" Sometimes it's definable, but sometimes it's sort of ineffable. It's like one of those things that you can feel. It's kind of like that old Supreme Court quote, where they were asked to define pornography. It's like, I can't define it but I know it when I see it. There's something certainly intuitive about that.

Fred: Are we thinking in terms of the finish on an office furnishing, for example? Or are we talking about how a product looks and feels? What are the tangible examples that come to mind when you think about this?

James: Just to get a little bit more specific, a classic example is Apple products. We can have a debate about today versus yesterday, but let's say 10 years ago. No question, Apple products were just of a caliber, of a quality, that were above and beyond anything else around.

It wasn't just one particular thing, it was everything. It was the way it looked, it was the way it worked, it was the way it felt.

A lot of times, you can measure quality most easily in the emotions that occur in the people who are exposed to that product.

Some products, you just get this sense that a tremendous amount of craft and care went into them. And other products you don't. You can imagine a spectrum. You can certainly imagine a product where it's clear that a tremendous amount of care went in. Every detail was considered. And you can imagine the opposite end of the spectrum.

I won't name any names, but you can think of products where, just, holy shit, who said this was okay to ship? What kind of person was okay with putting their name on this? And so if you can imagine that spectrum, it's how far to the right, how far to the quality of the spectrum do you want to go.

One of the really tricky things about that, in terms of managing that with a product, is that you can't define, okay, we want 80% quality, 90% quality. You can't really define that at the beginning because it doesn't really mean anything. What really happens is it's an accumulation of decisions along the way.

You have all these little decisions constantly all the time, and it's, is this good enough? Is this good enough, can we move on, do we need to go further? The problem is that you know you're okay with, you want great, you want good enough it doesn't have to be perfect, but you want it to be pretty close.

And whatever your bar is, let's say it's 80% or 90% or 98.6% or whatever, the problem is that you don't know how to land there, because you don't know how many more of these things are going to come up. You end up really needing to focus on 100%, especially in the beginning of a project, because you just don't know how many of these bullets you have to spend.

When you get closer to the end of a product, and you really feel like the polish is there, you really feel like the caliber is where you want it to be, you can start to let go of a few of those last things.

In the beginning you have to be really careful about sticking to your guns. It's this slippery slope to mediocrity, always, that you're fighting against.

Fred: This brings up several questions for me, I guess. One is, what are some examples, if you can share them, of contentious decisions that you made, early on probably in the life of Heroku or in the life of Heavybit, where everyone was like, "What the fuck, James? This is bullshit." And you were like, "Quality, quality, quality." The guy. Let's start with that.

James: Yeah, sure. If you take a random sample of Heroku employees I am sure you'll have no shortage of those stories.

Fred: James as a Service?

James: Yeah, exactly. Photos of me standing over people's desk. At Heroku in particular what we were trying to do was simplify something that was complex. And simplifying things is very, very hard. Simplifying things really is a lot harder than making things more complex.

To simplify something you have to really, really understand it and you have to often rearrange the entire solution, rearrange the whole paradigm of what you're doing, in order to just remove one part of the complexity. And then you have to do that whole thing again to remove another part.

You're trying to from 10 parts to, I wanted to go from 10 parts to one. Some people would struggle and struggle for months to go from 10 parts to eight, and then say, we've got to ship this thing. We've spent months on it, it's much better than it was. But to me, it doesn't matter how much time you've spent on it. What matters is whether you reach the bar that you're trying to reach.

The Heroku command line interface was sort of a classic example of this, where we wanted to have as few switches, commands as possible.

Fred: And the command line interface, for the less technical people listening, is basically the way for the nerds to interact with services through that strange matrix-y looking window of white text on a black background.

James: Of just text, right? It's just text. When we think about design, the user experience design and developer experience design, in the context of just text, just a command line interface--

Fred: Because that's still design, isn't it? That's still the interface that they use to interact with your product.

James: It's very much design.

Fred: And probably one of the only interfaces for developers that they'll ever want to use.

James: That's right. That's right, very few developers, especially at that time, used the web interface. They instead used the command line interface.

Fred: Did you build that first of all at Heroku, or was that something that you guys added on once you had the core functionality?

James: That's a complicated story. We basically built them in parallel. There was an earlier version of Heroku that didn't really have that kind of command line access. But then when we moved on to the second version of Heroku, we built both in parallel. We can talk more about that if you want, but the concrete example of this was that a huge amount of work went into trying to...

The classic example is the "create" command. This is a way to create a new application that lives in the cloud on the web, ready to go. Prior to this tool, basically what you had to do was 100 steps. Anything that was less than 100 steps was an improvement, but we wanted it to be one step. Or possibly zero steps.

You had this command line tool where you typed "heroku" and then something, "heroku create" was the way to create a new application. And then you could just push your code to it and it would be up and running.

The issue is there are a lot of things that we need to know at the time that you create the application, like what's the name of the application, where does it live, is there a domain name? There's a whole bunch of configuration, and the idea was to reduce and remove as much of that as possible. The issue is that it's not very straightforward.

When we first sat down to do it, if you do what I always call the "naive implementation," this is the first thing that comes to mind when you design a solution to a problem, without having really considered all the details and done that extra work to simplify it. We had 10 switches. "Heroku create" and then, blah, blah, blah, blah, blah. Ten things that you had to specify.

So, then the question was, how do we get rid of these things? There wasn't a clear answer. Each one was different. One of them, we needed to basically rebuild the entire way that our back end worked, so that a thing that we previously required you to specify up front you could specify later. We had to rework the entire architecture so there could be flexibility later. Really, solely, to remove this one flag from the command line. And that met a lot of resistance with the engineering team.

There's a lot of layers of infrastructure at Heroku. So as you dive deeper into the stock, you go from app developers to platform developers, into pretty deep infrastructure and dev-ops folks. It's a lot work to re-architect these things, and in particular, they're responsible for reliability and stability.

And so changing things, you have to have a really good reason. This is a classic example of, is this a good reason? Is it a good enough reason just to remove one thing from the command line? My argument was yes, because we had to get it down to none. We literally had to get it down to where you type, "heroku create."

Fred: And that's it.

James: That's it. There was a huge amount of effort expended on this. And then you have something else. Another classic example is the naming scheme of these apps. It turned out that having to name something was actually a huge point of friction. You wouldn't think that it is, but it turned out in practice it was.

Because what we wanted was to get people very, very early. They weren't even sure what they were building yet, they just needed to deploy this piece of code that they wrote.

When you stop and you're like, hey, what's this thing called? Suddenly it's this existential dilemma.

What am I really doing here? What is the purpose of this thing? What should it be called? Does the name collide with this other thing? And then you finally think of something, and it's a global namespace and somebody else already has that. That was actually a meaningful problem.

Then the question was, okay, can we have a default? Can we have sensible defaults? That's another means of reductionism. Again, naive implementation. Think of some other thing you've done that's probably like, "Untitled178394. We just didn't like the feel of that, because you're still trying to create something that has a sense of value and that you can remember and identify with, has some personality.

How do you create that without requiring the user to do anything? We ended up coming up with this haiku theme, where we basically wanted to have... It was a pair of words, originally. And so it would be like, "gentle river." Or, "quiet samurai."

Fred: Every Heroku knowser use it--

James: That's right.

Fred: Every Heroku user knows it very well.

James: It became this famous thing. It was sorta cutesy, and I'm glad we did it. But the thing about it is that it was actually hard to do. Because, again, the naive implementation of that would have been two giant lists of words. But then you end up with these combinations that don't make sense or some of them are not appropriate, or just weird.

I remember we had one that was like, "golden rain" or something. Certain combinations that didn't make sense, that weren't good. This ended up being a multi-week project where we had these different sets of words and there were algorithms for which ones could go with the others such that you would always end up with a haiku-esque thing, made sense, and didn't have collisions.

It was this whole thing. It was really ridiculed inside the company. It was interesting. Half of the company, maybe a third of the company, was really stoked about it. And two-thirds of the company were like, "What the fuck are these guys doing? This thing has been ready to ship, we worked our asses off on it. What are they doing?"

Fred: Because floating over their shoulders the whole time, conceptually, is this dumb hash, which every other app ever does.

James: "It's just a fucking name, guys. Let's wrap it up and let's ship this thing."

But there was a set of us who just felt it was really, really important. It wasn't that that by itself was the critical thing, but again, quality is this thing that's the aggregate, right? And so all the different pieces of this needed to be to a bar where, in other words,

some people think of quality as an average. I think of quality as the weakest link. The lowest quality thing in the system is the quality of the system.

Fred: Which is definitely true. Look at the old, when Microsoft was moving to Metro and you would spend a very short amount of time in this beautiful Metro tiled interface that felt like 2020. And then you get dropped into bloody Windows.

James: Bam.

Fred: Oh, there it is, there's the "Start" bar. Yep, thanks.

James: You experience this in life. You set up a fantastic vacation and you're going to Hawaii. The whole thing is dialed in, you get on the plane, you start clearing your head, your inbox is empty, you spend those five hours drifting into the zone of vacation, relaxing away from work and hassle. You land and it's all warm and pretty and nice and there's flowers.

And then you go to the fucking Hertz rental car place. And it's just like a clusterfuck for an hour. You can't get out of there and you've got to fill out these forms with information that they already have. Nothing aggravates an engineer more than that.

Yeah, I'm big on arrivals for that same reason. The weakest link is the problem. We pushed really hard for that, and a lot of people had a problem with it. But I think we were vindicated, ultimately, at least in that case, because it really affected the feel of the product and the experience you had, especially as a new user.

You also have to remember, this is the way it's done now, but

back then the idea of putting design and craft and really caring about user experience, for a highly technical system engineering-style product, that was unusual.

That was a big part of why we wanted to do it, because we just felt like everything else felt terrible. I don't know. There are countless examples of that sort of thing.

Fred: I remember very clearly that shift happening and it definitely felt like it was driven by Apple, for me. This notion that you would actually expect good design. Good design wasn't just this fun thing that just happened, good quality, as maybe you would say it. But something that was put in place from the very top level of the organization.

I guess that's something that's interesting to me. I would be interested to hear from you to what extent you did that deliberately. How does one create an organization that is able to figure out what that 90% or that 95% bar is, beyond the feel? Because at some point you're not in every single design meeting, every single wire frame, every single discussion. Lots of people in your organization get to decide what is good enough. How do you do that?

James: I will preface by saying, I don't know. It's really hard and I will not claim that we have mastered that. It's probably one of the great mysteries for me. But I think there are some things we've learned along the way.

Personally. I do believe that design and quality result from a sort of cohesive understanding of the whole product. The philosophy, the principles behind the product, the way it's built, the way it's implemented, the way it looks, the way it feels, all those things are interrelated and are important.

Products that we all make are pretty complex. It's difficult for one person to have the entire product in their mind, but it's equally difficult for a set of people who, as a hive mind, have the whole product in their head. It's difficult for them to actually make great design and quality choices, because really, each individual is only looking at a piece of the puzzle.

My experience, both on the cases of good and bad examples, and in my own work, is that it's very difficult to achieve as a team.

All the cases of really excellent work of the highest caliber, it tends to be a design czar.

That design czar maybe could be two people or three people, but it's usually one person. It may be different people over time, or different people on different projects, but usually the case is that you really have to have the entire world loaded in your head in order to make the right decisions. It's hard to share brains, right?

Fred: It's hard to delegate that.

James: That was me for a long time at Heroku. That was tough because it's really more than a full-time job and I had a couple other full-time jobs at Heroku. And it caused problems. I mean, in the early days, before we'd figured out how to scale that a bit, I was a blocker on a lot of things. To get James' approval was one of the steps in the pipeline.

Eventually I was able to hand the baton off to other people, Todd, Max, a couple of different people at Heroku over the years who did a great job of picking that up and doing it their own way, not my way, but doing it and doing it well. So I think that's part of it, is just recognizing that you have to have a design czar and you have to give that person enough responsibility and authority.

That person also has to be the kind of person who can command respect. Because I'm also, and this is a whole other discussion, but I'm of the mindset that responsibility can't be given. Responsibility and authority are connected, and it can't be given so much as it has to be taken. You also have to be the kind of person who can command the respect for those decisions.

Part of that is that you need to end up being right most of the time. That's a big thing. That's part of it. Another part of it is it's a cultural thing. Another part of it is how do you get your team as it grows to actually have those values, to actually care, to say, hey, what this company's about? What this product is about, is this level of quality. This idea of, let's ship it, there's this implied objective there that shipping more is better. Shipping it sooner, shipping it faster, shipping more.

I'm a bit of a contrarian right now in Silicon Valley, in that I don't think more is better or faster is better. I am 100% a quality-over-quantity person. A lot of that is about trade-offs.

You can't just sit on your high horse and say, hey, it's got to be really high quality and it's got to be fast and it's got to be good and it's got to be cheap. The classic trade-offs, right? For me, you have to be realistic. And so for me, what that means is if you're going to have a really high bar for quality, you have to be willing to give things up in order to get it.

Usually what those things are, are timelines. You have to be willing to basically blow deadlines or be unwilling to commit to them in the first place, which is difficult to manage around. You also have to be willing to be hard on people. I would say that's the one that would, probably for me, be a lifelong journey to try to continue to be better and better at that.

I think, fundamentally, it's very frustrating to work on something, to work hard on something and to find out that it's not good enough. Regardless of the means by which you find out, it's just hard. There's sort of the canonical Steve Jobs bad actor version of that.

Fred: "This product sucks. You suck."

James: Yeah, "You suck. I hate you, get out." But you know, it's really about the work. It's not about the person. It's not, "You're terrible." It's, "This thing is a problem."

Fred: This thing that you made is terrible.

James: This thing that you made is terrible.

Fred: And a lot of people are not willing to do that. It's much easier to say, oh, you spent 100 hours on this. It's not quite how I would have done it. That's the passive-aggressive way of saying your work is terrible. But it's good enough, fuck it.

How do you avoid that? Especially when, and I'm thinking about this through the ears or whatever of somebody who's likely to be listening to this, probably goning to be a founder, thinking about starting something, working in the core team of a late-stage technology company, how do you balance that?

Like you said, it's a trade-off. But how the hell do you balance that, when you have your monthly growth rate that you're thinking about and your investors and all of these other resources in the company are queued up behind. How the hell do you do that?

James: It's a dynamic tension. An important part of this is that you have to have, there's some counterbalancing forces. At Heroku the biggest thing was, there were a number of good counterbalances, but the most core was our founder partnership, the three of us.

In particular, Adam is sort of a ruthless pragmatist. He has a visceral desire to ship things and get them off of his books and mark them as done. His visceral desire for that is as strong as my visceral satisfaction or sense of betrayal around quality.

If you can have two people who counterbalance each other like that and can find a way for that to be a productive tension rather than just a destructive tension, that was a really big part of what the magic was at Heroku.

Because, I would be saying, "No, we've got to go further. No, we've got to go further. No, it's got to be better." And Adam would be saying, "Got to ship it, it's good enough. We've got to ship it, it's good enough." Without me, he would ship a lot more stuff. But it wouldn't be nearly as good. It wouldn't have been taken to the level that he's capable of taking it. And without him, I would just sit around polishing things in a cave forever and never ship them.

Fred: The utopia of every designer.

James: That's right. Exactly.

Fred: And then you pull the curtain away and say, look what I've polished over the last 10 years!

James: Over the last 10 years. That's the problem, though, right? You never really end up pulling the curtain away. Or, by the time you do, it's not relevant anymore. You need those counterbalancing forces.

On the second thing I said, in terms of riding people hard, it helps to have counterbalancing forces there, too. Orion, our other partner, he's one of these big-fish storytellers, everything is an analogy, very creative, mad scientist.

He reads people very well and he was often able to translate my feedback or translate my objectives into the language of the person, that mindset of the person who was working on it, so that they really could grok it. It's funny. That's a skill that I have, but I find that I can't simultaneously critique work and be careful with people's feelings.

Fred: Yeah, you go into that hyper-objective mode.

James: Yeah. You need help with that. The third thing I'll say is around, there's the cliched thing around, "A players, get more A players," etc. But in that vein, when you have people on the team who are capable of incredibly high caliber work, it makes this a lot easier because you may have to be push a little bit to get it, but everyone else sees that.

Instead of this, "You're asking for the impossible, this can't be done, this is frustrating." You see this other thing being shipped, and you're like, wow. Okay, I can't really say that it's not possible. These guys just did it, so I just need to get back to work.

Fred: The bar has been raised.

James: That's right.

Fred: And I also find that those kind of people, they tend to be hungry for critical feedback. Rather than rejecting it or being offended by it, they're desperate for criticism in some ways.

James: Yeah. The people who produce that kind of work, it's because they've been pushing their own bar forever. It's like anything. It's like working out at the gym. The heavier you lift, the heavier you can lift. It's the same thing with the quality bar.

People who are really of that caliber, they've been pushing themselves forever. They won't feel satisfaction from their work unless they have completed something to their quality bar.

And that quality bar is always going up. The thing they ship today has to be done to their satisfaction to a level of quality that's higher than they've ever done before. That keeps going up, every day, every project. The only way you get there is through true ruthless criticism, self-criticism.

You'll find that people who are of this quality mindset are very self-critical. You produce something and everyone in the world says it's the best thing ever, and they're like, yeah, I mean, it's okay. But this sucks about it and this sucks about it. I would have rather done this thing. I had to ship a little sooner than I wanted. That's a really common pattern.

Like anything with a team, the beginning really matters a lot, those seeds of the culture, those seeds of the team. You start with a person or two like that, and it may go a little slower. The things you produce, they just stink of this quality. It's just wafting off of them and it attracts other people like that.

Those kinds of people want to work in a place that at its core respects that level of work. Nobody who has that kind of bar wants to go work someplace where they're told, "Yeah, yeah, we've got to ship it, it's good enough, stop working on it." They want to be at a place where somebody says, "You, your amazing work? It's not good enough."

Fred: I find myself making this mistake all the time, where the trade-off, it seems to me to some extent, is between authority, or "ownership" is the trendy word, against maybe this unified vision or this central sense of quality. As you can probably imagine, and as I think probably most CEOs of early-stage companies are, that's pretty much me in our company.

Something that I see quite a lot is having an internal dialogue of, do I say to this team, "No, this is bullshit"? "This is nowhere near good enough. There are these five usability edges that I spot in five seconds of looking at this. How can you even think about shipping this to our customers who are paying us lots of money?"

I have to balance that against this notion of, well, maybe the more I eat into their ownership of that thing that they're trying to deliver, the less motivated they become and the more like, "Well, fuck this guy," that kind of thing. It's less about being popular, and I feel more about making sure that you have a super motivated team. Did you encounter that much, or do you think it was just fundamentally set up differently?

James: That's a constant battle, and it gets worse as you grow, because you have more and more surface area. You have to have more teams. You have more fragmentation of ownership, which generally is good. It allows you to decentralize decision-making, allows you to move faster. But it becomes very difficult to maintain that bar.

To me, also, and this is talking more specifically about design as one of the aspects of quality, to me,

one of the most important aspects of design is cohesion. Consistency, cohesion, continuity.

When you have different teams making decisions independently about how a product looks or feels or works, it's very difficult to have cohesion. So even if you have three different teams who produced fantastically-designed products, if they're all slightly different but they're all under the same product banner, that still is bad design, in some ways.

What do you do about that? Again, there isn't a right answer, but I'll tell a few things that we've learned. I think the model where you hand somebody total ownership, you give them this whole pump-up speech about total ownership over this area of the company, "Do whatever you want." And then they go to do something and you say, "No, I forbid you from shipping this," that doesn't work very well. Because it's a fundamental violation of the ownership. It makes ownership feel like a bullshit thing.

However, you also can't just be fine with it if you care about quality. So to me, the balance that I've found works best is that you give feedback. It's not, "You can't ship this." It's, "I wouldn't ship it, and here's why."

There's two parts to this, let me back up. The first thing is, in my view, the way we always did it was we wouldn't give ownership to a person for a team or a part of a product until they have already been through the crucible of feeling like something was good enough, being told it wasn't, and then breaking through that barrier.

Just as a sort of tangent there, we found at Heroku there was a really clear pattern where people would come onboard and we were very fortunate in that we got going in a good mojo direction early.

I think part of that was that we did really care about quality, and that attracted really high-quality people.

We were going in a good direction with talent coming on board who were used to being the best on their team, and they would come to Heroku and they would go through this difficult emotional adjustment period and they would come on board and they would feel like they were the worst. They would be constantly told, "Your stuff isn't good enough." And there would be this valley of despair.

What was interesting was there was a bifurcation there, there was an inflection point where some people would just eventually get frustrated and leave or never overcome that hump. But others, they'd bottom out and then they would double down and then they would come back and they would finally get over that hump of quality.

Once they did, they would look at this thing where two months ago they said, "This cannot possibly be done any better," and we said, "You're wrong." They didn't agree, but then they went back to the drawing board and eventually they built this thing that was dramatically better. And we said, "Oh my God, you did it, good job. Let's ship it."

It was well-received, and then they felt this really deep sense of satisfaction. That has been true, I've found, in general.

People always feel this deep sense of satisfaction when they ship something at a really high-quality bar no matter how much they disagreed with the process that led to it.

Anyway, there's this crucible you go through. We would only put somebody in charge of something who had successfully been through that crucible. Now they were on the same page. They cared, they knew what it took. They pushed the rock up the hill. They know how much energy it takes.

That's part of it, and I also, I'm using the language of, "Put someone in charge." But really, like I said, ownership has to be taken, not so much given. It's kind of the same thing in that, in a culture that respects that kind of quality, that kind of effort, you really couldn't take ownership of something unless you had achieved that, because people just wouldn't follow you. That's part of it.

You had the cultural background, then the people who were running these things are those kinds of people, so that's a big part of it. And then step two is the way you manage that is you give them the real-deal feedback. You leave it with them. You can ship it. You have the ship button, not me. You have the ship button, you have the key. I don't have a veto, but I think your stuff is not good enough and here's why. You can do whatever you want.

The power that you do retain is that if they do ship things that shouldn't be shipped, whether it's once or many times, you have the power to replace them, basically. You have the power to shift that ownership somewhere else. In some organizations, that ownership will shift by itself because people will look at the quality of things being produced and they will not want to follow that person. Now, the organizations that are a little bit more hierarchical or more authority-driven, that person will just not be in charge of that project anymore. I think that's sort of a balance.

The hard thing for you as a CEO or as a leader is you have to be okay with seeing some things ship that irk you.

Fred: Oh, yeah.

James: Now, you don't have to be okay with it forever, but you have to be okay with it, you have to be tolerant of some of it, as somebody gets their feet under them, learns. What you want is to see the trend going in the right direction. For me, as a perfectionist, that's very, very, very difficult.

I want everything that ships to be perfect. I see these couple of things and I'm like, ah. But the truth is you're managing a lot of things. There's a lot of surface area. There's a lot of things that are shipping. If things are generally of a really high quality and things are trending in the right direction, is the most important thing, it's worth that investment.

Fred: Super interesting. The other thing that I think would be great to dig into a bit is the trade-offs that you mentioned. And like you said, it always is a trade-off. You said just before we started this, that you have a framework of thinking about that, and that's something that you're big on. Can you expand a little bit?

James: Yeah, to me, everything is a trade-off. Every decision that you make is a trade-off.

If you don't think of things as a trade-off, then you don't really fully understand the decisions that you're making.

When you choose one thing you're trading off something else or maybe multiple things. This is true in general.

With the quality discussion, we talked about a couple of things that you're trading off, and the question is, how far are you willing to go in that direction? For me, let's take quality over quantity, which is sort of this mantra. For me, it's much better to do fewer things and do them well. Everybody says that.

People kind of say that and get it, but to really internalize that, you have to think about, okay, imagine a product that you're going to release. You want it to be really good. There's this minimum set of functionality that obviously you have to have for the product to work. How much of that are you willing to cut?

You've already cut from the scope of all the cool things that were possible down to what would be pretty good down to the absolute bare minimum. How much of that are you willing to cut, 10%, 50%, 85%? Can you ship this thing that barely does anything at all, that does maybe one thing, but it's perfect?

For me, I find that most people have a really, really hard time accepting that. To me, this is related to Paul Graham's "Dig a deep but narrow hole, rather than try to dig a wide hole." If you drill deep but narrow, you're going to have just a tiny thing that's applicable to a tiny number of people, but they are really going to see that you care.

They're going to feel the craft, they're going to care about it and they're going to expect that whatever you do next is going to be at that level. It becomes part of your brand. Richard Branson defines brand in a way that I really like, which is effectively, to paraphrase, "What you can expect from a company is its brand."

When you do things to that level of quality, people expect that level of quality. It's then very easy to roll out the next thing and the next thing and the next thing. And people will stick with you and they will celebrate as you do those things. Back to the Apple example, I remember, I don't know, maybe it was in the '90s, when they would roll out the new version of the desktop. And Steve Jobs would spend like 10 minutes on the design of the handle.

Fred: Yeah, yeah. I miss those days.

James: And people loved it. People loved it. They were like, yes! The handle is so much better now! I remember these famous quotes from Bill Gates and people on the other side of it, who were like, "What the fuck? It's a handle! Jesus!" But that totally works.

Whereas if you deliver all the functionality that people want but it's all kind of mediocre, or even some of it's mediocre, that's your brand now. Your brand is kind of mediocre. You can add a bunch of stuff later and you can maybe even fix the quality later, although in reality that never happens, but that's it. People are going lose it.

Everybody can think of that one product they got that maybe was incredibly simple, did one thing. Maybe it was a fucking carabiner, you know what I mean? Maybe it's just one tool, one little piece of something, but it was just perfect. You told everybody about it. People were like, "Which carabiner should I..." You're like, "This one. This is the one, it's got magnets. This one." I think that everything's like that.

How far are you willing to go? There's an exercise we do often where there's a couple different ways to do it. As a planning exercise it's fun to make the list of things we're not doing.

What we used to do at Heroku was we couldn't leave the room until we had listed 10 large things that we weren't going to do, that were just unthinkable to not do. Like, you had to do it. Every customer wanted it. People were complaining about it. Everyone wanted to build it. It was totally doable, it was super important, whatever.

If you're not super pained, just super, deeply pained by the things on the "we're-not-doing-it" list, then you're not recognizing your trade-offs.

I'm also of the mindset, the sect of people who believe that when you set goals, that a goal isn't the goal unless you're willing to trade things off for it. You should be able name what those things are. I think everything is a trade-off like that.

For the engineers in the audience, you can go to the CAP theorem. Or the equivalent of that is the old, "Quality, speed, or cost: pick two." Everything is a trade-off. It's often a good exercise. We actually just did a little quarterly planning thing for Heavybit, and we set some areas of values that we wan to focus on. We stated the value, but then we also went through and stated what the trade-offs were. If we want to achieve this value, what are the things that we're not going to have? Things that you want, but we're not going to have.

I think that's a really important way to think about things, and it's an important tool. It also forces everyone in the company, when they have asks, they've got to pay. Anybody, whether you're the CEO or anybody, if you want something, you have to pay for it with these trade-offs. When I demand quality, I'm paying for it with budget, with time, with feelings, hurt feelings. So I think everything's a trade-off.

Fred: The final question that I'm still fascinated in is something that seems to be happening, and I think you and I both obviously agree on it, and this is in some ways part of the founding thesis of Heavybit, is that business applications, however we want to define those, are becoming more design-conscious and less shit, basically.

The counterexample that you used earlier was the thing that does everything and all of the things are shit. That's most business software. Most of the stuff that we pay today to do our fundamental business processes, be it operations or be it development--shout-out to AWS, but guys, your interface is outrageously horrible.

It seems like this is a wave that's perhaps emanating from certain areas, hopefully Heavybit, several other places as well. How do you think about that? If someone's listening who is like, "Yeah, James, this is all great if you can afford to do it. But I have 100k MRR, I've got these users to please, and I've got this roadmap to hit." How do you think about the trade-off there where you've already trained the customers, or the customers already expect a basic level of shittiness?

To put it another way, so many people have come in to the sales CRM space and said, "We're like Salesforce but well-designed." None of them are Salesforce. That's something that feels like a hard argument to counter for me.

James: Yeah. Well, okay, there's a few things in there. Firstly, I'd say that most of the people who might be listening are probably starting companies now or recently, and most of them get a little nauseous when they hear the word "enterprise." Because for most of us, that conjures these pieces of software that you're talking about that are just, you open up this piece of software and it just feels like every customer request that was ever made was said yes to.

Just anything that anybody ever asked for, even if it was an edge case, they said yes and they put it in there. And so you just have this sprawling mayhem of chaos.

I'm going to go on a tangent here, into one of my design principles. I used to give talks on this and it was a big thing we did at Heroku. In addition to thinking everything's a trade-off, related to that, I think everything's a spectrum. I talk about almost everything as being a spectrum. It's easier to understand things if you think about the extreme ends of the spectrum.

Fred: Agreed.

James: One of the design spectrums, to me, is we used to call it "machete design." On one end of the spectrum is a machete and on the other end of the spectrum is a Swiss Army knife. There are some really interesting things about this.

The Swiss Army knife is the equivalent of enterprise software. There's a lot of different things you might need to do. Let's make sure you got a tool in there for everything. One time somebody asked for a whittler. So there's one in there. There's one in there today. There's a toothpick in there.

Fred: Whittler 2000.

James: The problem is you have all these tools in there, but they're kind of mediocre. The screwdriver in a Swiss Army knife is kind of a terrible screwdriver. There's no discoverability and there's no ability to enhance these tools or to use them really well.

This is not the kind of tool that you carry around like your precious prized katana that is your friend. This is a tool that you throw in your pocket, you know it's mediocre. It's going to maybe come in handy sometime, but if you're in a life-and-death situation, you're going to be pretty bummed that that's the tool that you have.

Versus the other extreme, the machete. The thing about a machete, it's a single-purpose tool. Sort of of the Unix philosophy: "small, sharp tools," right? Tools that have single purposes that can be strung together with other things.

A machete is very intuitive. You don't need to use your manual. You don't need to know what each tool is or where to find it.

There's often a manual with a Swiss Army knife. There's a thing that you open that tells you what the tools are. It's crazy. A machete, it's pretty straightforward. There's a sharp side, there's a handle. It's weighted in a way that you almost are forced to swing it in a particular way.

The interesting thing about that, that's a little deeper, is that your ability grows over time with a machete. You can unlock features, you can become an advanced user of a machete, by becoming familiar with the tool. As you become familiar with it, because it's a simple tool and it's well-made, it becomes an extension of your arm.

So maybe, you're starting out, you're slashing brush or whatever. But over time, you could use it to shave. You could use it to make a sandwich. You could use the tip as a screwdriver. You could use it as a hammer. As you become really intimately familiar with this tool, and if it's well-made and robust, you can use it for a lot of different things.

What's great about that is that it's discoverable. This is directly related to discoverable interfaces. You can unlock more functionality as you get deeper and deeper into the product. Whereas the Swiss Army knife, you're stuck with this set of mediocre things that you were given.

To me, the equivalent is, I think of Microsoft Excel, is the classic thing in my head. I think spreadsheets are one of the most important tools that have been created in recent years. But you open Microsoft Excel and you've got the classic toolbar. There's like 50 fucking buttons on there. You don't know what half of them do. It's crazy.

The friction for becoming a user in the beginning is incredibly high. Because you pop in there and before you can even enter a number, it's like, pivot tables and just all this crazy shit. It has that feel of, all the things you might want to do are just stuck there in your face.

Anyway, that's sort of a design principle that is, I think, related to what you're talking about. Stepping adjacent to that, there's this philosophy today, very prevalent in Silicon Valley right now, is the lean startup, the iterative development. Listening to the customers, getting feedback. Small release cycles, fast release cycles.

Not that I disagree with any of those things, and a lot of them are a business extension of agile software development, where we learned that waterfall is bad and we basically can't foresee the future, so we need to build things in small chunks and see what happens. But I think that maybe we've gone too far.

I'm a bit of a contrarian on this, but I don't believe that user feedback is valuable in a lot of cases.

I think that you want to observe users using your product, but I think that the things they say they want, I think there's little signal in that. Users tend to ask for the thing that's right in front of them, they're one foot in front of the other. Very, very iterative. Very incremental. No user is ever going to ask you for this fundamentally innovative thing. No user's going to ask you to remove that feature entirely or change the universe such that that set of problems don't exist anymore.

Fred: Because they can't conceive of that world.

James: That's right, and it's your job to conceive of that for them. So if you get too caught up in this focus group cycle, it's a real problem. That's, in my mind, part of what leads to what you're talking about, which is this sense of, customers need these features and the sales guys said that they can close this deal if we add this thing.

Obviously that's a counterbalancing force, like I talked about before. You have external deadlines, you have MRR targets, you have whatever. But you can't lose track of the other side of that force, which is that you have to fundamentally try to simplify the problem.

You have to fundamentally try to build a machete and not a Swiss Army knife. You have to have faith that when you do that, you will have a following of customers that is more valuable than the quantity of customers that you may be able to get, but you're going to have high churn on.

It's like these Kickstarters. The thing with these Kickstarters, they promise all these incredible features that have not even been invented yet, some of which may turn out to not even be possible. They feel compelled to make these promises so they can get enough sales.

I meet with these guys all the time, and I just don't understand. If you sell fewer, if you sell 200 items, it's like Paul Graham's "do things that don't scale." Don't get hard tooling. Don't go to China and figure out how to get good unit cost. Just build them by hand. They get really fucking expensive. You have negative margins on them. But get them to those 200 people. Get that feedback.

But they always, instead, it's like, can we sell 5,000 units? Could we sell 10,000 units? Could we sell 100,000 units? Great! We sold 100,000 units. Now we can afford to spin up a whole supply chain. And now it's fucking two years later before we ship these things, and as soon as we ship them we find out that the design's wrong and we need to change it. But it's impossible to get these guys not to do it that way.

It's a very, very strong fear that people won't buy something that doesn't have these things that they want. I think the truth is that people respond to quality, even when it's missing a bunch of things that they wanted.

If the things that are there are quality, it's much easier to add things later than to refine something, to simplify it, to make it high-quality.

I don't know. That doesn't really answer your question.

Fred: No, that's absolutely perfect, and I can't think of a better place to end the interview. Thank you very much, James.

James: Awesome.