Intercom on Product: Rise of the “keyboard-first” generation
A recent trend in app design has raised a fascinating question: is speed a feature or is speed the product?
In the latest episode of Intercom on Product, our co-founder and Chief Strategy Officer Des Traynor and I dive into this question, and unpack what the sudden rise of a new generation of “keyboard-first” apps that focus on speed says about product design and how products evolve over time.
In particular, we discuss the trend for a sort of command-line interface in a new breed of productivity apps that offer “shortcuts to superpowers.” How do we think about information architecture (IA) in a world where command-line context-switching is coming back in fashion? What sort of tasks does this focus on optimizing for speed really suit? How does it change our perception of finding product-market fit? Do these apps risk overserving their target customers?
We also discuss how products can evolve from being highly targeted at certain users to becoming bloated pieces of software trying to appeal to a mass of different users. What steps can you take to avoid introducing bloat into your product as it grows with the addressable market?
You can listen to our full conversation above or read a lightly edited transcript below. Stuck for time? Here are a few highlights:
- Apps focusing on speed through the command line are on the rise.
- Avoid overfitting for your customers.
- Beware the risk of feature bloat.
- Look out for losing your religion as your product evolves.
- We share our take on the Cmd-K trend for Intercom.
If you enjoy the conversation and don’t want to miss the rest of the series, you can subscribe on iTunes or Google Podcasts, stream on Spotify or Stitcher, or you can grab the RSS feed in your player of choice.
The need for speed
Paul Adams: Welcome to the Intercom on Product podcast. I’m Paul Adams and with me today is Des Traynor. Today we’re going to talk about products and how they evolve over time. We’re going to start with a question Des and I were discussing earlier today about all these new apps that are command-line driven, for example, Linear, Superhuman and most recently Height. Des, you have a few thoughts on this?
Des Traynor: I do. One, many of them have a dot.app domain. Linear.app and Height.app are two. And you’ve definitely heard of Superhuman if you’re listening to this podcast. There’s actually another one, now that I think about it: Quill, which is a really fast version of Slack, really excellent messaging for teams. I guess the interesting thing we’re going to learn over the next couple of years is: is speed a feature, or is speed the product?
“The challenge with anchoring your product pitch around speed is that you have to work out what makes the existing process slow”
For the longest time, speed has been one of those things that is important, but there are so many other things you can do. Maybe something like Gmail took your eye off that for quite a while. And the meteoric rise of Superhuman has shown that, yes, people want really, really fast ways to do things. I have yet to use, fully, Linear, but I can see the exact pattern it follows, which is high information density and rapid context switching through a Cmd-K command-line tool. Height is of the same order, and I’m going to guess Quill’s in that nature too. Every now and then, people pitch me on various products; I received a pitch today for the Superhuman of blogging. The challenge with anchoring your product pitch around speed is that you have to work out what makes the existing process slow. So if I have to sit down and archive, as I do every morning, 60 emails or maybe read-scan-archive, read-scan-forward types of flows…
Paul: Read my emails, yeah.
Des: Yeah, exactly: I read all Paul’s emails, but anyone else’s emails automatically get forwarded out. Yeah, des+straightoarchive@intercom.io. But there’s a phrase Jared Spool uses, which is about the difference between tool time and task time,: tool time being how much time you’re wasting dealing with the messiness of the actual product. How long does it take to pop the labels dialog and type in the label and all that junk? And then there’s actual task time, which is: when I’m writing an email, the thing that actually takes me time is thinking about what I want to say. The delay between the key press and the character appearing on screen is not the problem here.
Which got me thinking about this Superhuman-of-blogging approach. If I was to sit down to write, it might take me four to five hours to get a good post out – maybe longer if there’s graphics. The WordPress piece is not the high-order bit. Shaving minutes off a five-hour process is really not worth it. Now, it doesn’t mean speed’s therefore irrelevant. You can certainly go so slow that I won’t use your product. But as far as it being a unique selling point (USP), you really have to make sure to focus on areas where the speed improvement will be notable relative to the task time. And that’s one whole piece.
“We ultimately moved away from the command line because of the problem of discoverability. That is, you’re staring at a blank line, and you don’t know what to type, and you don’t know why you can’t type”
The interesting thing I know we’ve talked about before is the rebirth of the command line inside products as a way of enabling speed. Slack had a little bit of it with Cmd-K for switchers, but you totally see it elsewhere, too. Superhuman is all about it, as are these other apps, seemingly. There’s an interesting thing happening here, which I’d love your opinion on: we ultimately moved away from the command line because of the problem of discoverability. That is, you’re staring at a blank line, and you don’t know what to type, and you don’t know why you can’t type, and you type things, and you press return, and you get told that’s not a valid command. We figured, “Why don’t we just put all the valid commands on screens with icons and words underneath them, like ‘save’? Now all of a sudden, you can just click the thing you want instead of having to type it.”
By the way, chatbots did this whole dance recently as well, where you start a conversation with a chatbot, and you don’t know what you can say. I’d love to hear your thoughts on this, as we seem to want to go back here. Maybe it’s just power users, maybe it’s just people whose hands never leave the keyboard, but from a design perspective, how do you think about IA in a world where rapid access and command-line context-switching may be coming back in fashion? This could be just a 2019 thing, but I suspect it might go on.
A return to the command line
Paul: There are loads of different dimensions to it. One is understanding who your customer is, for a start. Different types of people will be more attuned to using command-line interfaces than others. For example, Height is a project management tool, and if you’re familiar with project management tools and quite sophisticated in project management, you might know that you could type something like T-A-S-K, something smart comes up, and then you can work away. Whereas if you’re new to it, or maybe your job requires project management but you’re not a project manager, you just don’t know what to type. I think the Slack example is interesting, because if you think about the tool time and task time in Slack, it’s definitely not on the scale of blogging on WordPress. You’re in the mix of tool and task time, where you’re typing to people, you’re writing chats, and then the chats are so quick and ephemeral that often you’re switching between them.
As I’m sure most people experience, we have many, many different types of chats, channels, groups, everything. I don’t know if many people listening have it set up this way, but our Slack has all the left-hand channels and groups hidden. I need to know to look in groups and know their names so that once I get into Cmd-K and start typing it, it works. All the suggestions pop up. So for that, it’s a nice blend where it’s worth it; the tool and task merge.
“The starting point has to be at least equal to – if not greater than – the actual task time”
Des: It’s interesting: the ratio there is the thing, right? If it takes you more than two minutes to say you’ll be there in two minutes, you’re not going to bother using the product. If you have to launch Slack on your phone, and it takes you a while to find Des just so you can say, “On my way,” or whatever, it becomes useless. The thing that’s invariant across all of it is that the ratio has to make sense.
The starting point has to be at least equal to – if not greater than – the actual task time, or something like that, where you spend most of your time not even doing the damn thing you’re trying to do. You’re actually playing with all the crap around it, right?
Paul: Yeah, exactly. Slack’s IA, in many ways, is dead simple. It’s just chats and different permutations of people in groups or whatever, whereas with other pieces of software like Intercom, for example, you have messages and an inbox and very distinct different things, and you might want to navigate around those because each one inside has a bunch of sub-options and sub-menus. So the IA challenge we have is not insignificant.
I’d argue the IA challenge Slack has certainly is not as hard as most other apps, at least apps that people use for workflow and for business and so on. So for us, designing an IA is quite challenging. Then further imagine having a Cmd-K for Intercom will be harder, because people won’t know what to type versus Slack. Slack is just trying to remember people’s names.
Des: And that’s all you need to remember, versus, “Hey, I’d like to configure a custom bot on the pricing page.” You’re back into this idea of: “The thing that I’m trying to do is actually a pretty serious thing. It’s not going to be a seven-seconder.” Maybe one area we could optimize would be just the actual Inbox itself, because sometimes you are answering quick questions from customers, and in that case it is worth speeding up.
Paul: Slack, at least in my experience, is lots of navigation, whereas it’s possible that the command interface we would design and build for Intercom would be more about getting through the actual tasks and focusing on getting things done. And it could auto-populate as you start typing it out.
“It would be hard to pitch a recruiting system or a human resources system purely on, ‘Hey, look how fast it is,’ because the person who’s buying it probably doesn’t actually care about how long it takes everyone else to use it”
Des: It’s interesting to hear of the interchange between these and ye olde keyboard shortcuts, which we’ve had forever. The last piece on this new era of speed-focused apps – actually they should brand the movement as “keyboard-first” – is that there has to be a sense of bottom-up consumer adoption of the thing, because it’s hard to sell into a big company. It would be hard to pitch a recruiting system or a human resources system to track your staff or whatever, it’d be hard to pitch one of them purely on, “Hey, look how fast it is,” because the person who’s buying it probably doesn’t actually care about how long it takes everyone else to use it. Versus a bug-tracking thing, where actually the person who’s buying is probably a lot closer to the person who’s using it. Before you get hell-bent on creating the Superhuman for X, it’s important to ask them a few of those questions along the way.
Paul: One thing we’ve noticed is that a lot of people in marketing had very little technology experience and didn’t need it, and the software they used had the big icons, the big buttons and so on. But over time, as things like targeted messaging and ads have evolved, people have started to become way more familiar with how all these things work. There are actually databases, and people in them, and they have attributes. I don’t think people go learn SQL, but they’re starting to learn the basics of and/or logic. So natural sophistication is happening. The expectation of the marketer these days is they can understand and/or logic. And I wonder: would that extend this so that the floor is different?
Overfitting your target customer and the risk of bloat
Des: Yeah. I think the task you’re doing has gotten more sophisticated, in a sense, which is interesting. The other thing in this space we’re talking about is that it’s quite tempting when you’re in the early throes of application development to be so workflow-obsessed about speed that you can actually overfit or overserve your target customer. The challenge you bump into there is – because you’re designing so much for yourself and for a workflow you know really well, you might start to bake in the peculiarities of you or maybe just a small group of your own customers. The tension there is that when other people sit down to adopt it, you realize pretty quickly, “Shit, not everyone likes to archive their email and go on to the next one automatically and open a reply dialogue and pre-tag the email the way I do.” Do you think that shrinks your market size? How do you think about baking in those opinions early on?
Paul: I think email’s a great example, actually. People use email very differently. I apply some version of Inbox Zero, where every day, I have about 20 or 30 emails. I know you’re Inbox Zero-oriented, as well, but I know people with thousands of emails.
Des: Oh, that freaks me out.
Paul: And they would say, “I’m in total control of this.” They’ve got a completely different workflow to me. It freaks me out, too. Looking at it stresses me out.
Des: There’s no way you’re on top of things. That’s my only conclusion.
Paul: So people use email in different ways. Some archive, some don’t. So there are definite differences, and within any product’s customer base, obviously people should go out and understand those customers’ differences and needs. One thing we’ve experienced over the years around overfitting is that you go out, and you talk to users of your product, and you see gaps, and you fill those gaps with features, and the product grows over time. That’s natural, and any product, over the course of years and years and years, adds features. It’s easy to then become bloated software full of features that only some people use. And it’s easy, then, for the products to become really complex. So this concept of overfitting that we started talking about is a really powerful way to think about it.
Des: There’s one end of spectrum is overfitting where we’ve absolutely nailed your workflow. Unfortunately, the Paul Adams email client has a target customer base of one, and you’re not going to pay a couple million for it, so our revenue is not going to look so hot. Then the other extreme is that we are the sum of all email client features, and we are all things to all people, but most people are only going to use part of it. This is the old Microsoft Word argument – okay, there’s some 80/20 thing at play. You know all you need is bold and underline or whatever, and then when you actually get into details you realize, everyone uses a different subset of these features. So it turns out all the features were actually necessary, if you want to have the big market.
If the spectrum is super-tight fit, and it’s really specific to exactly how you think issue tracking should work or how you think marketing automation should work, and then the other end is an un-opinionated toolbox that can be used to support basically any which way you could ever imagine working – the costs are different. On the overfitted end, you have a really small target market, and that’s bad, because it means you really need to jack up the price, and this is why some of the people call this the “luxury software” end. Then on the other side, you have this ridiculous upfront configuration cost which is: ”Welcome to ‘thing’ management. Please tell us what the things are and what you want to do with them.” Then you end up configuring everything. And there are systems like that, where there’s a three-day onsite install where engineers come out and tell you how it works.
“Bloat is a way of saying there’s a lot of stuff here that a lot of people don’t need. But when you add them all together, someone needs everything”
Every single feature needs to be self-stitched in, based on your needs. In that world, you have maybe the high price, but you also have the ridiculously high adoption costs. You probably have no self-serve business. The statement that occurs to me – and I hate saying this, because it demoralizes people – but it’s true that for software to be commercially successful, there’s some fundamental requirement of shittiness. If you’ll hear me out, what I mean by that is that, if it is truly the perfect fit for you, almost by definition it’s imperfect for somebody else, right? Because what it means is, at the very least, you didn’t have to crawl through all 1,150 drop-downs on configuration settings to get a fitting for you. If it was a really perfect fit for you, it would just have to have been bad for somebody else.
And then the other extreme is if you want to have a large addressable market, you need to work for a lot of people, which means that you can’t actually bake in all these opinions as first-class citizens. You need to be really flexible. And that’s the tension we see.
When we talk about systems, “bloat” is a way of saying there’s a lot of stuff here that a lot of people don’t need. But when you add them all together, someone needs everything. For every feature there is a user, not for every user there is a feature. There might be a 5 percent adoption for all of your features, but again, it’s a different 5 percent of customers. So, to expand your addressable market, you have to start peeling back some of the opinions that, on the one hand win you customers who say, “Hell yes, we want automatic archiving of emails that are greater than seven days old and automatic tagging…” Appealing to those people is going to get you your early customers, but you have to wind that back as you think, “Now, let’s talk to people beyond that.” The point I often make to early-stage startups when they really want to overcook or overserve is that every opinion costs you money. If you’re selling me a project-management app, you’re already down to a certain sliver of the market.
And then they’re going to say, “We have an OSX client only.”
And you’re thinking: “Okay, grand. Well, now you’re reeling in all the Windows users. What’s next?”
“And we believe all tasks must have an owner.”
“Okay, now you’re down to only people who believe that, too.”
“And we believe all tasks should auto-expire if they’re not completed in five days.”
And you’re thinking, “Okay, you’re getting pretty peculiar here.”
You’re whittling down your opinions so tight, and the challenge you always have to have as a software owner is for all the opinions that I’m hard-coding; what’s the ROI of them? They better be paying you off in marketing and the attractiveness towards the peculiar bunch that you are building for, because they’re costing you everything else in the market. If you are successful over time, you get to start – in the words of R.E.M. – “losing your religion” in a sense, because you have to start saying: “All right, maybe to-dos can be unowned for a period. I know we said never, but I guess now is never.” So you have this tension.
Losing your religion and changing your beliefs
Paul: Yeah, that’s definitely a journey we’ve been on: losing our religion for a couple years for sure. A lot of the strong opinions we had in the past we’ve let go of. As you’re talking, it makes me think there’s a relationship between a product growing and the market growing. So, as you add a feature, the addressable market’s growing, and the product is growing, and everyone’s together.
“For me, when software gets bloated, it’s when you see things in the product that you just don’t know what they do”
It also reminded me of the way we work with our sales team here, where we’re building deeper and deeper collaborations with our sales team. They obviously talk to customers; they talk to customers all the time. They have a very deep understanding of the needs, the gaps in the product. The easiest way, of course, to fill those gaps is features. It’s our job in product engineering to build those features. And one of the things we are very strong on is that we will never build a single feature for a single customer.
Having said that, when a customer says, “Hey, we need feature X,” we will then go and ask: “Do other customers need feature X? Is it a common thing?” I think that’s how we are navigating (and hopefully avoiding) this bloat that comes. And most of the features that most of the customers see, they understand. I come back to email here, too. I’m thinking about Gmail. There are many, many features in Gmail that many, many people don’t use, but they make sense. Archive, tag, filters: these are understandable things. For me, when software gets bloated, it’s when you see things in the product that you just don’t know what they do.
Des: Which basically means either you’re sharing the same product across multiple types of users – such that one person gets it and another person doesn’t – or you’re crossing into different use cases, and you’re speaking the wrong language or whatever. An interesting way to think about bloat as you look at product surface area is that it’s a ratio of the usage statistics to the software footprint. So if you have a whole tab in your email thing called “to-dos” that no one has ever clicked into, that’s a pretty significant chunk of your product that you’re going to have to design, maintain, support, improve – that no one’s using.
As a result, the ROI of work there is really, really low. Yet, it still sits there, and it dilutes your energy. The key thing to keep your eyes focused on is some sense of the footprint of your software relative to how much adoption it has. If you take Gmail, it might be the case that you and I don’t use, let’s say, folders. But when you have a few hundred million users (as Gmail does), they probably still have 35 million people using that feature, so it’s not insignificant. And that’s the piece you have to bear in mind: adding that has probably enabled 35 million more people to adopt Gmail, and as a percentage, that’s been worth it relative to the size of the feature. If the feature was massive, it would’ve been a bad idea.
“When you’re playing in companies of hundreds of people, there’s so much inside that company that’s very specific and unique to them”
Paul: Yeah. It reminds me, too, that you and I may not use folders, and yet we understand why they’re there. Adherence matters a lot. Another thing I was reminded of was a point you made to me, which I thought was really, really insightful: as companies grow, most startups in the world start off with a small customer base, with small companies using them. As they go upmarket, their customers are bigger companies, and as companies get bigger, they become more unique and have more unique needs. So when you’re playing in companies of hundreds of people, there’s so much inside that company that’s very specific and unique to them: the ways they work, the workflows they have, their relationships with departments, the way they’re set up.
One thing we’ve noticed recently is the term “customer success”. It means wildly different things in different companies, so I thought that was really insightful, because it reminded me that it’s very easy to overfit. And you’re looking for this lowest common denominator. Basically, it gets into the world of customization.
The essential naivety of the startup mindset
Des: Exactly. That is the other half of the overserving thing: you need to find the most common paths everyone takes, and then you want to have your options, and your preferences, and your customization and your last-mile integrations, they fill in small remaining gaps behind you. So you might say: ”Hey, for 90 percent of the support workflow, we do all of this excellently. If you really, really need to drop into this, we integrate perfectly with this other tool. But we don’t step over there, because most people don’t need it.” And then the ROI of that customization can be judged independently when you haven’t stitched it into the whole product by itself.
When I think about all this and then I look at some of our aspirational competitors further up the market, or just large companies in general, it’s hard not to admire them in a way. Let’s just be polite and say I didn’t always. When we were younger and Intercom was a smaller company, it was very easy to guffaw at the challenges or the slow pace of innovation relative to people who could bang out five features in a week or whatever. It does become more tempting to actually gaze admiringly and say, “Wow, you’re doing incredible, given what you’ve created and given where you are.”
Paul: Absolutely, very much so. That’s something that’s close to my heart these days. It is true: there’s a naivety in the early days, and maybe that turns people away.
Des: Probably an essential naivety. You have to believe that’s terrible, in a sense.
“In the early days, you feel like you can disrupt these companies that have big, bloated software, but then you start to realize a lot of those features that looked like bloat now look like money”
Paul: Absolutely. Your view changes over the years as you go. In the early days, you feel like you can disrupt these companies that have big, bloated software (and in many ways, this is disruption theory), but then you start to realize that a lot of those features that looked like bloat now look like money. Again, there’s a fine line there.
Des: Yeah, there’s a healthy tension there, and the flip side is also interesting, which is when you see a new early stage startup saying, “We’re like Intercom, but with a twist.” When I hear with a twist, what I hear is “a much smaller target addressable market.” Part of this, I guess, is just growing up. And people who’ve been through multiple mature software companies are probably listening to us thinking that we’re children in a sense, but it is natural, as you get closer to those larger companies, to see, “Wow, they actually have a lot of this stuff figured out.” To be sure, evolving a product is hard, but when you see a company like Zendesk have $600 or $700 million dollars in revenue, you realize: “Wow. You don’t roll out of bed and get that. You have to be doing a lot of things right.”
Paul: When you’re a small startup and you’re plucky (and again, you probably need that in the early days to be successful), you do love those companies and forget, quite conveniently, that many great people make many great decisions in those companies day after day, year after year.
Des: Yeah. Shock, horror: some of the best companies of our generation were built by fantastically smart people.
When the command line meets Intercom
Paul: Let’s bring this home and connect all the things together. As we think about the future of our product – where we are adding features – there are bigger companies using Intercom, and they have more sophisticated needs. How might we marry together the classic IA and this new Cmd-K world? Do you see this thing as just being too early, too nascent? Right now, you have the Linears and the Superhumans and the Heights, and maybe Slack is a hybrid. Then, you’ve got your traditional software without any of this stuff.
Des: One of our designers posted a mock-up recently and said, “Hey, here’s how something like this might work.” Not to be totally purist about it, but my take on this was that I wanted to zoom out, and I said: “In true Intercom values, let’s understand the problem. Let’s not start with the solution, right? It sounds like you’re proposing that Intercom needs to be faster? Okay. Let’s trickle down from there. In what way is Intercom slow?”
And you might say, “Well, it’s still to load.” All right, well then let’s go talk to the Ember team and see if they can get it faster. Or you might say, “Well, it takes me too long to get context on the user.” Okay, well maybe we should redesign the screen to get the context on the user.
“It’s not speed of technical performance. It’s the idea that your hands don’t leave the keyboard, and you can really get in the zone”
With regard to the command line, for us, it’s not speed of technical performance. It’s the idea that your hands don’t leave the keyboard, and you can really get in the zone. And that’s what Superhuman really tapped into. It’s this idea that like you shouldn’t ever touch the mouse. You should be able to sit there with your hands on your keyboard and get through a hundred emails immediately. The similar use case for us is actually the customer support team. Put another way, I don’t think building a command-line switcher for people who are sending out marketing campaigns is going to be that useful. They’re okay to click around a bit, because it turns out the thing they’re doing is a lot of work, but it’s a single task.
It’s when you’re doing high task-frequency and repetitive tasks (read-reply-read-archive) that you want all that stuff to be doable without your hands leaving the keyboard. I still want to pull back on my earlier question and ask why did the keyboard shortcuts get bypassed in this world? It’s possible that the command line thing has just been a highlight that people don’t really know or remember keyboard shortcuts, but they will remember “close” or “send” or things like that. It might actually be quicker or conceptually cheaper to just press Cmd-K and type the first two to three letters of the thing you’re trying to do, instead of remembering that Y is “archive” in Gmail.
There’s something going on there. So what does this new world of command-line-driven ops mean for Intercom? It means there is a class of user for whom a high task-frequency and repetitive tasks performed in a really fast, dynamic manner is definitely a thing in a lot of tools, and for us it’s definitely a thing. And we need to design the right solution to do that. Separately, gosh, it does seem fashionable to have one of these things right now. And if it does catch on, and everyone starts to expect it, we’d better be there, because it’ll become a standard pretty soon if it’s not already. You have to come at it from both sides. But if you’re asking me, should we ship it? Yeah, sure. Go for it.
Paul: All right. We’ll leave it there for today. Thanks, Des.
