An interview with Ryan Singer

I talked with Ryan Singer from 37signals about design practices, product management, the merits of UX processes, and lots more.

You can download an mp3 of the entire interview here (40m, 50MB), or read the (lightly edited) transcript below. Please note the visuals used here were not created or endorsed by Ryan.

Des: Hi, and welcome to Inside Intercom. I’m joined by Ryan Singer, the Product Manager at 37signals. Today’s topic is going to be about building software to solve problems, by focusing on what the users really need to get done. Thanks a lot for having us Ryan.

Ryan: Hey, thanks for having me here.

Why Feature Checklists Don’t Help

Des: Let’s get straight into this. Could you tell us about Jobs-to-be-Done, and how you discovered it? And, what was the immediate realization that made it influential in what you do?

Ryan: I’ve been frustrated as a software designer for a long time, because when you look out at a lot of the software people are selling, it’s just lots of features all over the place. And it’s even worse if you’re trying to buy software. I was trying to buy some hosting the other day, and just looking at all the feature comparisons, it’s like the people who are selling this to me aren’t connecting with me on what I’m trying to do. They’re just giving me a lot of capability, and I need to figure out how to piece it together myself. I’ve always wanted to be the opposite of that somehow. I always wanted to make products where the purpose of the product is really clear, and it really connects with something that somebody’s trying to do.

The core idea that turned me on about Jobs-to-be-Done is that products are also services. They’re not just a bunch of features that people pull into their lives to get from point A to point B, and there’s this idea that people are always trying to make some sort of progress. And, the only reason that people bother to buy your tool, or use your software, is because they are in a specific situation and they’re trying to make some progress—get from here to there—and they’re struggling to do that.

So, that point of view kind of gave me the language, or it gave me some words to understand something that I, kind of, understood at a gut level. I heard about the terminology in a Clayton Christensen book called The Innovator’s Solution. And I’d been hearing it here and there, and then there was a podcast from Critical Path, where Horace interviewed Bob Moesta, who is one of the guys who created this way of thinking.

A big lightbulb went off when I heard that podcast. It was like: here’s the real story behind this way of thinking. So I got in touch with Bob and have been able to get to know him a bit, and learn from him a bit. I still feel like I’m at the very corner, just learning a little bit about what he calls Jobs-to-be-Done. The core idea is that people are trying to make progress, and my job in making products is to give them something that will really help them to solve their problem. Not just to make a bunch of cool looking stuff, or something that has a bunch of features.

Des: What was it like to get it adopted or into your workflow, or by a design team? Did you have to sort of spread the word, or was the take-up pretty good?

Ryan: Everybody likes the idea, but I wouldn’t even say that I’ve gotten it adopted, and I’m also not sure what that would look like. You know, I think if you look at it in a more strict fashion, what Bob is often talking about is doing some serious research to get to know what the customers are actually trying to do. And, we did a round of that research for a Basecamp, and we were surprised by some of the answers.

But, I can tell you that we aren’t doing that research all day. And, honestly, the DNA of the company is to not do research. Our company DNA at 37signals is make things we want, and to make them the way that we want them. We’re lucky in that some of the things we want, other people want too, you know? That’s how Basecamp came about; it’s because we had that problem ourselves, and same with our other doable things.

So, in a way, we haven’t adopted it at all, and at the same time I think of this question, what is the purpose, what is goal? What is the definition of progress? Why is somebody using this and where are they trying to go with it? This new point of view has kind of hardened that, or at least given me more ways to talk about that. It still comes up mainly when I’m talking to the other folks about an idea. It’s not that we have a process or a new kind of conveyor belt in our factory, where we can just put things through an algorithm and get different results out.

Des: So it’s more like a new perspective from which you can speak?

Ryan: Yeah. It’s especially a good way to push back on any kind of development that is unclear. You know, if there are some features that we’re working on, or some interface that seems cool, we can say “What is the real purpose here? How is this helping people?”

Des: That’s interesting. I’ve read in previous interviews that you’re working on a new product that’s a membership application for a non-profit?

Ryan:Yeah.

Des: When you’re building a new product, how do you apply this line of thinking when you don’t have active users yet?

Ryan: Well, I’m an active user, and I’ve got friends who are active users. So, it’s not like I’m really starting a business. It’s something that we need, and there’s no good options out there. Man, the software out there for doing automatic member donations, like monthly donations to something, those software products all suck! I looked really hard, and my first idea wasn’t to build something, it was really hard. And they’re all terrible!

If you look at fundraising software or donation software, there’s 2 classes. One that is very enterprise, for big national non-profits where it costs thousands to get set up, and you track every single donor, so that you can harass them by phone and send mailings all the time. Then, the same companies also have “low-end” offerings, but all they do is take their enterprise product and put a monthly price tag on it.

Then, there are a lot of social fundraising tools which are social platforms. There’s no simple way, for a representative of an organization to just take somebody’s money every month, or from the administrative side, just see their members and how much they’re giving.

It’s amazing how poorly the existing options handle these basic needs, to see how many numbers you have, and how much they are paying and if their cards are going to expire. I have a couple of really clear jobs to be done, and the products just don’t cater for them.

Des: You could have designed this product five years ago. Do you think you would have designed it differently?

Ryan: Not at all. It is very easy for us to take something like Jobs-to-be-Done and think of it as this transformative thing. For me, it’s putting words onto something that I didn’t know how to describe before.

I think that whatever it is that I’ve been doing, in a successful way, with software design over the last 10 years has been this kind of thinking. Where it’s all about standing in the customer’s shoes and thinking “What do they need in order to make progress? What are they trying to do?” And this is just a simple common-sense notion, to intuitively feel yourself in their shoes, understand their situation and where they’re trying to go. We feel like we need Jobs-to-be-Done to flush it out and give us some ways to talk about it, because just saying it plainly is too obvious, too common sense.

On UX Process & Deliverables

Des: Did you ever consider techniques like personas or user journeys, or any of those UX design methods?

Ryan: That that stuff is all terrible. The problem with personas is illustrated really well with an example: You’ve got a couple and they’re middle-class Americans. They’re in their early 30’s, and they have all these attributes: the car they drive, ethnic background, the city they live in, etc. And then you ask “Is this person going to go for pizza? Are they going to go to an upscale Italian restaurant, and have an expensive entree and a romantic evening with wine?”

The attributes don’t determine that at all, because on Monday night, the couple orders pizza. And, on Friday they go to the restaurant.

Des: So, you’re saying that knowing details about a user is useless independent of knowing what they actually want to do?

Ryan: That’s what Clay talks about in Marketing Malpractice. He talks about how your attributes don’t cause you to do things, it’s the intention that you have, where you’re trying to get a certain kind of result. So, that same couple, who has this exact same persona, on Monday night, they’ve had a long day at work, a long week ahead and it was a busy weekend of running errands. And, it’s Monday night and they just don’t feel like cooking, and they just want to take a break and have an easy night in front of the TV, because it’s been a long day already and the week is just getting going. So, they order pizza.

Des: Do you see any role for understanding the attributes of the user? Say, their level of income influence the manner of when they have a consideration set?

Ryan: There might be experts who can comment on that, but I’m not one of them. From what I’ve heard, you can do slicing and dicing in terms of who is going to be your best bet to speak to you about something. So, if you’re going to be selling the newest, latest, greatest home sound system, where you can stream all of your Internet services through your wireless sound system, I don’t think that the retirement home would be the place to market that.

That’s kind-of common sense. So, I think there’s a basic level of segmentation that makes sense that way. Honestly, since I’m not a marketer, I think the whole thing when you’re looking at jobs is that you’re looking at causality.

Des: Causation is the driving factor. It may be true that like, Rolex customers all make over a certain bracket, but that’s not the trigger, because there are plenty of people who cross that salary threshold, and still don’t think a Rolex solves a problem for them.

Ryan: Absolutely, yeah.

Des: I find your take on the User Experience side of things quite interesting. You’re one of the more prolific people when talking about software design, though I know you never identify yourself as a UX designer. It’s interesting that you don’t adopt any of the practices there, from wireframes all the way down to personas.

Ryan: The things that get called User Experience come from the agency world. It really seems to be like that. Every time you meet people who are doing all of these UX methodologies they come from the consulting world. My background isn’t in the agency world; it’s in the product world. The whole game changes when you don’t have the pressure of delivering to a client on time, or trying to convince a client that you’re worth hiring or worth sticking with.

For example, if you’re working on products, and you’ve got a really capable team that can prototype things in real code, of course you don’t need wireframes, because you don’t need to get sign-off on something from a client.

Des: So UX is about solving agency-client dynamics, more so than building great software?

Ryan: Yeah, I really think it’s like that.

The whole UX world was defined by agency and client services people. People like Adaptive Path defined what UX is, and those of us who didn’t identify with that—but wanted to make software products—we kind of grew up in a world where the only way to talk about making interfaces was to use all this agency-client services stuff.

And I think that’s kind of backwards, because the fundamental challenges that we have are: how to make a good product—and whether you are doing that for yourself or someone else, you have the same fundamental challenges—how to define the problem, how to deal with all kinds of constraints, how to get the different roles—a designer, developer, support, strategy, all that stuff—working together.

If you put the product problems in the center, then adapt that to deal with all of the trust issues, the communication issues, and payment issues, and all that stuff. All that stuff is a corruption of the core process. If you all trusted each other and were working together on the same side of the table, you’d do it one way, but because you have a few people who are skeptical you have to keep gaining the trust, trying to prevent them from asking for changes, all that stuff.

Then, you have to corrupt your process a little bit. Those processes, where you have to learn how to do sign-offs and stuff, those all became central to product design. They’ve become the definition of UX: You have to do all these different stages, wireframes, stuff like that.

Des: It’s a heavy bit of baggage to bring on to a product team, if there’s no client involved.

Ryan: Right. You don’t need all that stuff. At the same time, I understand why it’s like this, because they had a big problem; you know, there were a lot of people in the agency world. And it was valuable for them to articulate the way they solved the problem and their solution for solving it. And, the thing is, people in my position, who just make product and aren’t in a client/service model, we haven’t offered an alternate view. So, it’s totally understandable that the sort of agency perspective on things would be dominant, because there really isn’t another perspective you can pick up on things and learn.

How to expand your product

Des: Let’s move on to sort of a higher level. As a Product Manager, when people are using a product you designed in a way that you didn’t intend it, do you see that as a new job the product can do, and should be improved for? Do you see new product opportunity? Or do you just think it’s interesting that people are using this for something we didn’t design it for, let’s leave them be?

Ryan:: I think this comes back to the thing about DNA. Some companies have the DNA for chasing opportunities, and it seems like at 37signals, our DNA is to find the problem ourselves, and we don’t have to chase it through measurements, interviews and statistics, and nail it to our own satisfaction. I think that cuts pretty deep for us, to the extent that if people were found out to be using our tool for a totally different purpose, if we can’t really identify with that purpose, we’d have to be really pushed by, let’s say, falling revenue or something dramatic, to start designing around that. We have a really strong preference to stay close to what we know, from our own experience, even if we’re seeing a lot of success in another direction.

We’re lucky in that the main use of Basecamp is very clear. People who are client/service firms, who need to manage their projects, it’s just a no brainer that this is good for that. And people who work with a fair number of other people, and need to collaborate on projects, who are mainly interested in communicating their status on projects and not tracking dependencies, like that. Basecamp is just a really good fit for that.

The thing is that there is no end to the number of problems that you can solve. There’s just no end to it. If you are the type who wants to look for, and chase, more and more opportunities, you can do that all day. Especially when you’re good at making products. I mean, we’re pretty good at it, and I think that if we were really chasing after lots of different opportunities, from where we could make something happen, really nail it for an individual use-case, we could do that all day. But it would dilute our focus, and this is always the trade-off. There is so much cool stuff that you could do, but how much of it do you want to do?

Des: And, also, how cool will it be when if you have to do all these things in parallel?

Ryan: Exactly. I’ve been thinking about this lately, because I really like to focus strongly on the fundamentals; on really getting good at solving problems. Because then, whenever a problem comes up, we can build something pretty good to solve it. The main question isn’t whether or not there’s an opportunity somewhere, it’s more like we know we have the ability to work well together, we trust each other, we can build great things together, and if we’re going to build something to target an opportunity, then we do it in a diligent, very, very focused way. You know? So, rather than building 10 vertically narrow different versions for different industries of Basecamp, or something like that—we could do all that, but is it worth it? I’m not sure.

I would just rather keep doing really good work for the cases that we care about and then, if the landscape changes, and there’s a new idea that comes up that we’re excited about, or we see usage start migrating away towards something else… it becomes a concern then. Then, we can always take a look at those opportunities and decide what to do, but I just feel that you can go crazy with so many opportunities out there, it’s like you brain turns into Hacker News.

Des: What would your stance be for plug-ins/modules for web software? It’s alleged by a lot of thinkers out there that you should maintain a product core, but make it extensible to different domains through plug-ins.

Ryan: Well with Basecamp in particular I’ve noticed that you can distinguish between projects that have an end (i.e. a definite point at which they’re over) versus things that are more like an ongoing process. If we really wanted to, we could clarify this for people and have recommended ways to use it. You know how you open up Pages, you have these different templates? You’re using all the same bundle of functionality, but you’re putting it together in different ways: to make a business letter, or a newsletter, or whatever.

Des: I guess the way you would do that, while keeping a broad product, would be to ask “What type of problems you are trying to solve?”

Ryan: Yeah, what are you trying to do? Are you trying to plan and coordinate work? Are you trying to record information for later, to protect yourself… what is that you’re trying to do? But again, this is all a bit speculative, and what I meant to illustrate is that there are different ways that you can use the tool to different ends without going all the way down to building something that is really narrow for a specific vertical.

The role of a product manager

Des: Lets talk about the role of ‘product manager’. What problem occurs in a company that causes them to need a product manager?

Ryan: I had the experience whenever I was at a cocktail party and somebody asked what I did at 37signals. For a long time after I got this title, I’d say “Well, my title is Product Manager, but I’m not sure I know what that means.” And, maybe even a couple of years went by before I stopped saying that, because I know better what it means now. But, it took an experience to clarify it.

What I noticed is that we reached a point where one day I looked around at what was actually happening. Actually, I took a bit of a break from managing projects. I took maybe a month or two, where I stepped away to really focus on playing around with iOS and learn some things. And, when I came back, I noticed that things weren’t going totally smoothly.

Des: So, then you knew what your job was.

Ryan: Well, then I tried to find out what my job was. We really value self-management at 37signals, and it’s been experimentation over the years just to see how much self-management can people really do, and what can you get out of it? In some areas, it’s been really successful. I mean, there’s a lot of self-management happening at 37, but at the same time, what I noticed was that despite a lot of success with that, projects simply were not getting shipped. I wanted to see people picking up an idea, developing the concept, implementing it, reviewing it, changing it as necessary, reviewing it again, and then deploying it. And, I wasn’t seeing that happen.

So, I was asking myself “What’s missing? Why isn’t this happening?” And I realized that what it really takes to ship product is coordination. Somebody has to actually pull the people together, and get all the different roles to connect with each other. Whenever you build some product you’ve got to have design, you need to have programming, support has to know about it, it has to get QA, it has to be reviewed by people who can say no to things. All these different pieces have to come together.

And, if somebody doesn’t actually take care to schedule everybody’s time, so that the right people are available at the right time, with the right context, to work together and make all those things happen, it just doesn’t happen on its own.

So, I’ve come to see it in a big way as a coordination role. Where I’m taking a sort of strategic point of view, where I understand the value of what we’re trying to do. And, I also understand the value versus the cost of how much time we’re willing to spend on it. As an overall frame, in that, to get the different roles and the different people, so that they can each contribute what they need to contribute, and the thing can keep steadily moving and eventually get deployed. I just learned that that doesn’t happen by magic. Somebody has to make that happen.

Des: Like the conductor to an orchestra, they themselves don’t play the music but if they’re not there to coordinate then the tunes won’t get played.

Ryan: The review is a really big part of it too, I have to say. The coordination is huge and then, at the same time, there also needs to be somebody—at least the way that our company is—somebody needs to take the role of editor or grand editor, or curator. At the end of the day, that’s always Jason at 37signals, but I also play that role. And, that’s important to have each step of the way. Because it’s very, very easy to get inspired to build something and to release it.

But, man, if you don’t watch out to curate what you’re releasing, soon you’re going to accumulate a lot of stuff. You know you’re going to have a lot of settings and a lot of options. And it’s so important to have somebody saying no, and to really curate what goes out, so that the product stays coherent and stays simple, and it always has free space in it for something new to come later.

Different Designers for Different Jobs

Des:Do you think you could hire a second product manager, based on your experiences of the role now?

Ryan: I’d love to replace myself and I haven’t figured out how yet. So, that’s an open question.

One thing though that I did learn about is that years ago I didn’t really differentiate between different types of designers. As time has gone by I’ve become more sensitive as to which person I can ask to do which kind of design. Some people who are really strong with what you would call interaction design. They’re really good at positioning buttons and elements on the screen for functional reasons. Other people who are really good at more of an artistic kind of design, it has to do with color and typography and art.

There’s a third person who is really good thinking about the right words and the right copy. And I find that you’re lucky when you get all three of those together at the same time. But very often you find it in different people, in combinations. Now what I’m learning is that there are certain people that I can bring in, I can hire them, even though they’re already in the company.

Des: And you’re hiring them for a specific skill or perspective, right?

Ryan: Yeah. Because I know that the job is to bring a little bit more visual style in, or to bring more clarity to the text, or to put some UI together that’s going to really work well. I’m even noticing this on the programming side too.

I used to think that we just had programmers, and now I’m noticing that we have some programmers who like to work alone, and come back with a stroke of genius type solution to a difficult problem. And that there are other programmers who like to stay close to the rest of the company, and communicate their status on a daily basis. There are other programmers who don’t really like to take risks, so they really like to take every step possible to avoid bugs.

Other programmers are really progress-oriented, and they would rather make some big leaps, without checking every stone under their foot along the way. Where there may be a few issues in the end to clean up, but they really move things forward. And, again, it’s a hiring criteria, even though they are already in the company, you still have them for a certain project.

Becoming more sensitive to that has become more interesting for me lately. Nobody is 100% of one thing, but becoming more aware of somebody’s strengths, I think that if I were to hire somebody new to the company, this would be more on mind than it was in the past.

Des: So if you know you are re-architecting something fundamental, you probably want people who are risk adverse, and won’t make any mistakes. Whereas, if you’re going to build a new product, you know you are going to hire specific people who can move mountains pretty quickly, but there might be some fallout along the way.

Ryan: It’s also a challenge, because people are changing all the time, and I don’t want to put anybody in a box. There are some people who come in, being really artistic and not very clear with the technical interaction type things, but they might be interested in slowly learning it over time, from the others. It’s also somehow really important to keep a fresh state of mind, when you’re looking at everything in the moment, instead of the box you put them in six months ago, you know? It’s an interesting challenge.

You can read more from Ryan at his personal blog: Felt Presence, his posts on Signal vs Noise, and follow him on Twitter as @rjs.