From the moment your beta app lands on Product Hunt you’ll ask yourself what way it should grow.
Should we add more features on more platforms, or better features on one platform? Should we capture the complete user’s workflow, or excel at just one piece? These questions are core, and no one but you can answer them.
For most startups, advice means limited experience and overgeneralizations. So when I spoke at Business of Software last year, I focused only on what we’ve learned to be true in our journey from 0 to (then) 8,000 customers, as well as the lessons invariant across many companies, rather than extracting from a data point of one. Hope it’s useful!
When I worked as a consultant in Ireland, I worked for government websites and library websites. And then I started a consultancy with some other folks and we built web products for startups. That gave me a lot of raw experience with the binary outcomes of startup. Four or five products we worked on went on to have multimillion dollar acquisitions. The rest netted out to zero. That’s typical of how startups play out. Since then, we built a product, sold a product, and then built Intercom, the business we’re all-in on today.
A lot of what I’ve learned has been about product. I firmly believe that you can mess most things up, if you get product really right. Conversely, you can have perfect financials, perfect accounting, and beautiful marketing, but if your product is terrible, you get found out. Reality really bats last.
So, rather than talk about Intercom as it is today, and how our company’s structured, we’re gonna talk a little bit more about what we learned when Intercom was a small, embryonic idea that we were trying to turn into a big business. And the first common trait I see across startups, that ones that make it and don’t, is they differ on this.
Your vision is the ceiling for your success
If you want to build the world’s fastest time tracking software, you’ll build the world’s fastest time tracking software. And that’s exactly what you’ll do. But you won’t necessarily transform how businesses are conducted, or even how time is tracked for that matter. Visions are really, really important. They’re the guiding principle for your entire company. I really like this scene from Alice in Wonderland.
Because if you don’t know what you’re trying to achieve, all roads are equal. Either equally optimal or equally terrible. But you don’t really care because you don’t actually have a sense of the grand destiny you’re going for. Without having a vision, you’ll flip-flop frequently cause you don’t actually know what you’re trying to do.
It’s easy to sort of talk about vision in a really high level way, that’s best visualized in PowerPoint Clipart. When I’m talking to companies, I never actually ask what your vision is. I ask specific questions that I think are indicative of how you see the world. Like what does the future of your domain look like? What are the tech trends that are making your product possible today? That’s kind of what I really want to see when I talk to younger companies. The answer to these questions distinguish people who are playing startup from people who really want to grow a business.
With the relative ease of access to capital and relative ease of developing software these days, a lot of people are definitely playing startup. I think they should be thinking a little bit more to break into these components such as the future of your domain. So if someone says I’m gonna build a project management tool, I ask what’s changed in project management? If their answer is ‘Basecamp’s UI is a little bit older’, that’s not a thing. It might be true but that’s not gonna be a driving force behind any sort of significant shift.
Trends worth betting on
On-demand purchase is changing. Anything that can be delivered real time wins. Subscription purchasing is changing. We’re now at a time where the dude who did the dollar shave commercial is now at $316 million. So, the joke’s on us, you know.
What he saw was the rise and the growth of subscription services for recurring commercial purchases by consumers. He piggybacked that trend for a very specific recurring purchase for guys. If you’re building a messaging app, what’s changing in messaging that creates an opening for a product like yours? Or in marketing, what’s changing in marketing to create an opening for a product like yours? If you don’t have this, it’s usually signed over to the domain expertise.
That means you’ll hear people say things like, “Oh, we’re gonna make a medical play.” I’ll ask “What’s changing in medicine?” Just because you don’t see any software there, doesn’t mean it’s enough to base something on. Similarly, what tech trends are you gonna bet on? Your product doesn’t exist in isolation of technology, which shouldn’t be surprising given that it’s a technology product.
Consider what trends are worth betting on. Does Apple Watch mean anything for us? Or does the connected home mean anything? You know, the connected home idea that your television can make toast, and your toaster can call you and turn off your thermostat. How does it affect your domain?
It’s now cheaper than ever to build software, deploy software, to store information, to compute information, to retrieve information. Bandwidth, hosting, storage, computational costs are all falling off a cliff thanks to the prevalence of technologies like Amazon, Microsoft, etc. That’s enabled a lot of stuff that previously just did not make sense. It enables things like we’ll hold a terabyte of your photos for free, and will work at a different way to make money. It’s a whole new type of business that’s supported by this type of stuff.
Interestingly, one of the common arguments as to why we’re not in a bubble right now is predicated on this idea that you had to raise money to go and buy a fleet of service, or buy a load of database. All of those costs are now no longer upfront capital anymore. They’re all subscription capital. Which means that when you’re raising money these days, you’re not actually throwing away the first two million into hardware. You’re actually putting it all into product. Obviously the cost of building a product has gone down as well which means you’re actually putting it usually into growth or scale.
Take the prevalence of all these messaging apps. Everyone single one of these is a messaging app. But there are four or five multi-million businesses on this slide who are not necessarily jokes. The idea that 30 people can build WhatsApp and take down the entire global SMS network by outpacing it 6 to 1, and selling the business for $19 billion dollars, that just wasn’t possible in 2000. That’s the type of things that are possible today.
Why do you exist other than to make money?
If we forget about money for a second and think about why you’re actually setting out to do all this, that’s the the piece that will last, and cause you could have commercial success. The question is what change you actually want to make? I think it’s a really, really important one to reflect over. As I said, if things aren’t going so well, right, and your only motivation is cash, your inspiration is just to walk out the door and go get a job at Google. And if things are going well and you get the cash, then your inspiration is to stop doing things and retire. So, you’re real determined desire to change is actually the thing that keeps you going.
When I ask people like, what are you actually trying to do, I don’t want to hear, “We’re gonna do 10 million in revenue, or we’re gonna be the leading provider of hosted.net. “ They’re stepping stones to what? It’s best captured in short statements.
With Intercom we want to make internet business personal. Stripe want to increase the GDP of the internet. Instacart wants to build the best place for anyone in the world to shop for groceries. Uber wants to make public transport as reliable as running water. It’s fair to say, London cabbies do not. And I say that only because I’ve had way too many £200 taxis from Heathrow.
If you are doing this, it’s crucial to start small. One of the guiding principles for us at Intercom is to have an insanely big idea but to start with an insanely small step. It’s like Gall’s law. Gall’s Law says loosely that, a complex system built from scratch will fail. It can’t ever be made to work. The only way you make it work is to build a simple system and evolve to complex. If you find yourself with a complex system that isn’t working, throw it away. You cannot pivot or iterate or hire another 100 engineers. There’s no recovery. You are in trouble. I’m choosing my words carefully based on the age group.
Take Salesforce. You could argue Salesforce is either complex or not. But one thing you can’t really argue is that, they have, by anyone’s standards, a fair whack of products. Salesforce are now a complex system but they didn’t start that way. They started on something that was much smaller, right?
Here’s Salesforce initial launch page. They have two highlights. One of them is free membership. And the other one is that you can forecast the pipeline. This is what they shipped.
They absolutely did start with a very small offering. Using their end goal as your starting point is a really, really messy way to look at it because if you’re modeling yourself off one of the big successes like Salesforce or Microsoft, start where they started, not where they finished.
Microsoft Word today (on the bottom), Microsoft Word where it started (on top). If this looks complex, that’s just because somebody launched the About box. Word is the whipping boy of UX designers. But it’s also the second most commercially successful piece of software of all time. I always like to use that for my UX designers. Maybe you all don’t know what you’re talking about.
If you want to sit down and build a Word competitor today, you don’t start here. You start somewhere like here. And if you want to see what that really looks like, have a look at the first release of Google Docs. Which is exactly all it was, and now look at where they are today and you’ll sort of see that shift evolve. So, starting small is really, really important.
What kinda feeds that is when you know your problem well enough, you can distill the solution down to small set of workflows which you then build features to enable. Your first release should be like the smallest product that solves a problem for your user.
The feature drop – the biggest fallacy you can fall into
Thinking you’re just one more feature away from mass adoption is a fallacy. If that is true, it means that you didn’t start from the right place. Which means you probably don’t know the domain well enough. If you can’t get adoption of your first release, you either don’t understand the problem, or your execution’s broken.Neither of those problem is worth ignoring.
The easiest thing in the world is to fall into this sort of death trap of “no one’s using our product”. Why don’t we ask people why they’re not using our product? Then they’re gonna tell us, Here’s another 10 features I just daydreamed. If we build those features, we’ll get even less people are using our product.
That’s the death trap described by Andrew Chen: if you can’t distill the problem you’re trying to solve down to an initial release that people actually do want, forget about expanding it. Lord knows we don’t need more software nobody uses.
I see a lot of people mess this up when they decide to launch a beta. It’s a default tendency of startups to think that betas are pretty straightforward thing to do. You collect email addresses, make a vague pitch and see how many people respond. But a beta is something you have to manage just as much as you manage any other release of your software. You don’t get to wave some sort of flag saying “It’s OK that it’s crap”.
Putting a crap landing page together is very easy. There are whole products that will do this for you. You put up some vague background image, some vague piece of text and collect email addresses. And you might consider yourself a success. You might even go and print up business cards saying you’re an entrepreneur having doing such a thing.
It’s important to realise that’s not actually doing anything per se. A small list of target users beats a big list of non-customers, or even a big list of some customers mixed in with a load of people who don’t really care either way.
One trend I really hate is this idea of giving away something free to grow our list, or giving away a free Apple watch if you want to grow a list of people who want Apple watches. That’s what giving away a free Apple watch does. Now, if you happen to sell Apple watches, that’s a great list to have. So, Apple should totally do this.
If you happen to sell software that works on Apple watches, that’s an OK list to have. Although it does mean most people on your list don’t actually have one. But what’s certainly not useful is if you’re trying to build the next generation of photography tools or project management. You’ve got these 10,000 people who are psyched about an Apple watch, which is not really relevant. You may as well hand out flowers at your local church for your software. There’s no consistent pattern that unifies these people.
The other thing people do with a beta is they build really vague pitches for their product. This is one I made up. It’s photography reimagined. You all have a different opinion about what photography reimagined does, right? Some people are thinking, what if there was no camera? While a lot of people are thinking, we should bring back that filter in Instagram they removed.
There’s various different opinions about what this means. If you offer a really big vague pitch for your product, what you’ll get is a big set of vague customers for your product – or would be customers for your product. That will get you is a wide ranging feedback for loads of different problems that exist only in people’s head. One person wants to sell their photos. Another person wants to collaborate with their art director. Someone wants to export to Instagram. Someone else wants filters. If you don’t really check yourself, you will literally wreck yourself. You’ll go and build such a tool.
That’s what happens when you run a beta that tries to include everyone. By definition, your product has to exclude people. I don’t mean form a typical exclusion sentiment. If you’re selling photography tools, people who aren’t photographers shouldn’t be interested in your product.
Building stuff to satisfy your entire beta list when it consists of a really varied group of people will get you a one-size fits none product.
Good and bad beta users
Good beta users will give you good data to let you know when you cross this mythical, good enough to use line.
And bad beta users will tell you that you’re still just one feature away, and that’s the end for that previous trial. You’ll never get a beta user saying “I think you’re good to go. You should start charging me.”
That never happens. If that happens to you, you’re one of the lucky few. Most people will just say: “You haven’t even built account reset yet. How could you possibly exit beta?”. It’s like that quote: when you say, iterate, I try to hear working until it’s great. And that’s the trap you might fall into frequently.
Another example of this was Steve Jobs’ when he was describing the iMovie Export Flow. He was probably had a load of wireframes on the wall, analyst reports and all that sort of stuff. He thought, what is all this junk? But then he said “Here is the new application”. It’s got one window. You drag a video into it. You click burn. That’s it. That’s what we’re gonna make. That’s the sort clarity of thought that actually lets you know what done looks like.
Another example is Lorne Michaels, creator of Saturday Night Live. I love this quote from Tina Fey’s book, where talks about her early days as a writer, comedy writer on Saturday Night Live. It was 9 o’clock on a Saturday night. She said, “We’re not quite there yet. The jokes aren’t exactly ready.
She was used to that being OK to even say. Lorne just said, “Ready?” The show doesn’t go on cause it’s “ready”. It goes on cause it’s 11:30 on a Saturday night. We don’t get our own definition of ready here. They’re 15 million people about to start watching this. It’s ready, you know.
The key point is, you have to exit your beta via the Steve Jobs model. Here’s what it is, and here’s what we’re going to do. Or you exit by a deadline which is, whatever we’ve got by August 1st, that’s what we’re gonna try out with our users. If it’s not in by then, c’est la vie.
But above all, get out of beta. Don’t do this sort of Web 2.0 thing that was perpetual betas.
The real reason for this is that betas are horrible sign-up flow. If you think of how you design a sign-up flow, and think a of the time people spend optimising these things. A beta design flow looks like this. You visit a website, sign up to be notified, get an email address. Then a long period later, you get an invite email. You create an account, complete a free trial and sign up for a real account.
You’ve introduced this incredibly lousy step, with a 1-6 week gap in it for no reason. And you’re gonna lose a lot of potential customers while you’re in beta cause they sign up for something when they’re motivated to use it. And then they just forgot about it.
The actual attrition is horrible, especially in consumer products, but also in B2B products. Consumer products are like people goofing around on the Net, they stumble upon this thing, and it sounds cool, so they try to use it.
In business products, what you’ll see is, people have this need to solve this problem. They actually can’t wait seven weeks while you decide to rollout invite list number four because they actually have a problem today. So, they’re just gonna go and use somebody else’s product that solves the problem.
Another option is to keep quiet while in beta. Talking is so cheap. It’s easy to sell all these new things that are coming in the future. You’re setting yourself up for disappointment in the eyes of your customers. And there’s nothing worse than a non-existing disappointment. The less you say, the more people listen. The press only cares about new.
Your best angle is when you launch. The irony is AirBnB launched three times or four times. Because if you launch and no one notices, that fine. The worse thing that happens is you launch, peoplenotice and they don’t like your product because it’s not ready or whatever. And then you’re like. You’ve spent the only PR credits you have.
The danger of dogfooding
Another classic thing I see is when you actually do go to market, someone tries to sign up and they act confused as hell. They ask “Did you guys not do any QA?. So, we don’t need to?”. They’ll say “ We used our own product. Or “We’re dogfooding”. Or some nonsense that basically translates to, “We forgot to actually try and use this thing like real people.”
Interestingly, signing up for your product is the one thing that every user will do. It’s your widest adopted feature if you like, right? It merits a lot of effort, a lot of reconsideration, a lot of improvement, consistently. It’s the only thing that everyone’s definitely gonna do. And conversely, the disappointing part here is that, most product owners sign up for their product once. And they think that’s fine except for when they did sign up for the product, it looked like this. Right?
This is how most entrepreneurs sign up for their own product. They do it as this byproduct of creating an SQL database. And as a result they will meander through all of these and forget how janky it can be to have a seven step sign up flow, or how annoying it is to have to click all these boxes, or enter all your friends.
The other cost if you’re not doing it frequently, is that your product will go out of date. Your docs will go out of date, your welcome emails, your videos. All that sort of stuff is out of date because no one in your team is actually doing this recurringly, so you forget to realise that Step 2 is gone now. Your entire flow is basically broken because no one’s job is to actually consistently do this.
If you’re dogfooding, like most people you should feed your dog every day. Similarly, you should never stop signing up for your product.
In Intercom, we have a growth team. One of their core things to do is to consistently innovate on what it feels like to start using it Intercom. It’s phenomenally high impact team. An undying focus on what it means to become an Intercom customer has been hugely valuable for the company. And honestly, I just wish we had done it years earlier.
When you do get out there into the market, you’ll see competition. And there’s a very naïve view people have about competition which is, you know, I’m a time tracker on the web. Therefore, my number one competitor is other web-based time trackers. And that’s only true when your customers are people who refresh product into time tracking category. But most customers aren’t like that.
Similarly, if you’re selling flowers, you might think that your competitors are all the other people who sell flowers and that’s a fair assumption. But then I’d ask you, “When do flowers and chocolate compete?” When do flowers compete with chocolate? Valentine’s Day. Like lots of similar things. It’s a general gift of sorts.
One of these products thinks it’s in the fast moving consumer edible industry. And the other one belongs in the gardening industry. They’re two different industries. Two different categories. Two different everything but they’re probably direct competitors for certain jobs.
Understanding real competitors
Twitter competes with games every time you’re bored. And you’ll play whichever is quickest. The decision is “Should I use Twitter or Facebook or Angry Birds or Monument Valley or any of these sort of millions of things that I can do to entertain myself?”
The way I think about this is you have direct competitors and direct competitors that do the same job in the same way. So, direct competitors are like McDonald’s and Burger King. You have indirect competitors which do the same job in a different way. So like Skype versus business class travel, for example. And then you have like sort of territory competitors and they do conflicting jobs. So, Weight Watchers and McDonald’s are actually competing for the same customers quite often. There’s only one unit of purchase to be had there. You’re either doing one or the other, but they’re both fighting for the same person.
A point I often make to people who do project management or like a to-do-list software is that a Post-it is your number one competitor. I have a friend who works on a to-do-list app. I told him to look at a Post-it and realise all the features it has.He thought I was crazy, so I left like a Sharpie and a set of Post-its on his desk.
Lo and behold, he started to use them. Why did you use them? “It was actually quicker.” So speed is actually an attribute taking a note. “I also wanted to give it somebody else.” So sharing is an important trait as well.\
“I needed a physical reminder, so that I can’t do anything else.” So there’s a blocking element here as well. You don’t even want to see the rest of your list. And that’s important to realise. We take all these things for granted. His road map did not have these types of trait on it. It was also more about building an API. I’m sure you do, but bear in mind you’re still losing to 3M here. Similarly, email is a ferocious competitor. All your customers already have it. In that regard, they don’t even need to fight. How many people here send emails to themselves? How weird is that?
Most to-do-list entrepreneurs out there that are denying this behavior. They say: “People aren’t going to email themselves. My tool is way better than that. It’s way cleaner to log into mine, connect your Facebook thing, add a note, and then like stick it into two lists, and then set up notifications, sort of pings your phone.”That’s not easy at all. You’re competing with a Post-It and an email here.
You have to understand your competitors, and your real competitors. And that’s what lets you understand switching behavior. Switching behavior is when you actually think you have a superior product, understanding how people will get there. And as I said, your competitors aren’t necessarily, the people who are in the same crunch category as you. Switching behavior is what takes you from the old to the new. And there’s some really good research on it that I’ll just quickly walk through, but it’s very easy to remember.
The four forces
Bob Moesta calls this the four forces. There’s two reasons why you would change to a new product. And there’s two reasons why you would not make the change. The green arrows are problems with the current product. So, why are you considering changing your email client? Because Mailbox doesn’t have this feature. So, what are the actual problems with your existing solution? Where do Post-its fail, for example, right? Does the attraction of the new product, which is your product? So, what are you trying to sell? And how do you make yourself seem as attractive as possible as like, as smooth, and slick, and sharp, and modern and fresh? And all of these that are sort of traits that people desire?
You can control the attraction of your product. Then why don’t people switch? Well, one of them is anxiety, or the uncertainty of change. If I switch to your product, will you still have my Slack plugin or that I need, that my whole work flow depends on. Will my team adopt it ? What happens if they don’t? Will I look like a fool having to roll back on the decision?
And then lastly, there’s existing habits and allegiances. For example, I’ve already bought this enterprise plan. And we’re already taken all these training courses and we’ve already bought the manuals. And in the world of phones, I’ve already bought the car plug, and the lamp plug, and all these other things that make my phone work really well.
That’s the way a switch happens is. If the green forces are both aligned or have the red forces below the line, somebody will switch to your product. If that’s not the case, they won’t. Basically, the switch is not worth the risk. So, you need to maximize the top forces and minimize the bottom ones.
And what does that mean? Remind people of every single problem that they have with their current solution. Maximize your attraction – look as good, as fresh, as modern, as fast as problem-solving as much as possible. Minimize the anxiety, so they don’t need to worry that you’re not gonna work with all of their files, or that you’re not gonna integrate with all of their tools.
The best campaign that ever did this, in my opinion, was the, “I’m a MAC” campaign. It presented the MAC as being this young, cool, attractive, popular thing, and the PC as being this old buffoon. You’re attacking every single fear that people ever had. And what do they call that campaign, does anyone remember? The switch. The entire thing was deliberately done.
The 9x effect
When customers are evaluating what they have, there’s three reasons that leads them to over evaluate. They typically over evaluate their current work flow. No matter or bad or good it is, they over evaluate by about three times. There’s the endowment effect, which basically translates to: “I already have this. I don’t like changing things. And also, this just sounds like a risk to change.”
And sadly a company has over valued their benefits by three as well. Most companies think their product is about three times better than it actually is. They didn’t focus on the exact job that they solved. They got too obsessed with the category. They built something that only matters to a few niche cases. They’ve built a load of features that certain people don’t really want. Even though people only care about two. Those other 43 that you’re really excited about literally couldn’t care less.
Being diligent with your roadmap
Roadmaps are a fight. They are a mess. They’re usually, the cause of people to break down and fight, alcoholism, all sorts of things could be caused by roadmap discussions. I’ve presented this diagram a few times. So, I’m gonna skip over this piece quickly. But suffice to say, it’s important to be able to understand and answer this.
This is basically a question of who’s using your product, and how often are they using it? Every single time I talk to entrepreneurs, they’ll say they don’t know what to build next.
So, I draw this axis. By the way, this isn’t a literal tool and you should never expect software to do this for you. This is a way to think about your product. On one axis we’re gonna say: “How often do people usually use your product? Very little or all of the time.”
And then the other axis, we want to say: “How many people have used it out of those that can? Very few, or all of them?”. Then try and place your features along here. Lo and behold most people do that and their first guess is almost always wrong. You can actually tell the sense of delusion. Product managers or owners will have based on how wrong they are here. They’ll say that everyone uses our photo filters.Then you’ll go to a database and run a query like: out of those who can use photo filters, how many did?4%.That happens very frequently. You’d be shocked.
I’ve come to the conclusion when you actually have the data, and I’m not a data-driven person at all, don’t let them be overridden by opinion. And the fact is, do people use this feature. There’s a lot of biases that will force you away from answering that one honestly. Which is, I spent months building that. It doesn’t matter. It really doesn’t matter.
A simple way to think about this is that the features in the top right are actually your core product. Anything here is something that is not used that often by your customers. It doesn’t mean it has to go but it does mean you should question why it’s not used more. And if that’s a desirable behavior it looks like you’ve tiptoed into consulting where you built a feature for a specific customer, and it’s just for them them that use it. And now you have to maintain it and no one else cares.
There’s hard questions you have to ask about removing those features, or trying to get them better adopted. Which is basically what it comes down to – you have to be insanely diligent about your roadmap.
This is one of the things that isn’t true for startups. It’s just true. You have four times the work you’re gonna do, like improve a feature, that is to make a feature better for those who are currently using it. Get more people to use the feature. Get people to use the feature more. And then add a new feature to support a new workflow.
Understanding tradeoffs
When you’re improving features, you have to understand there’s tradeoffs between the quality, the importance, the satisfaction, and frequency when you’re improving things. And what that looks like is:
Quality – how well-executed is it currently?
Importance – how important for users is it? So, like, is tagging photos really that important versus uploading photos?
Satisfaction – how happy are users with it today?
Frequency – how often are they actually using it?
You have to realise: if you’ve got something that’s frequently unsatisfying, that’s going to upset users. If you’ve got something that is unsatisfying, but not important and infrequently used, it’s probably fine. You know the forgotten password form? Whenever I see people have put in some nice slick animations and stuff like that, I’m like, either you guys have a sincere problem with people forgetting passwords, or you’ve just thrown away many, many weeks of a development effort to polish something that no one really wants to use.
Anthony Ulwick has a very simple framework for this which he calls the important satisfaction opportunity. For any given product, be aware of any problems with any of my projects. He assigned an importance from the user’s point of view. Like how important is it that they can do it? And maybe give that like 9 out of 12, or 9 out of 10.
Satisfaction means how happy are users with it today? The opportunity is basically it’s the importance plus the data between importance and satisfaction. It’s a simple framework, I don’t believe necessarily in this science behind any of these. Just like the whole 3x, 9x thing. What I do believe is that they present really good ways to rationally think about your product. For example, Anthony’s point here s that the opportunity for working on any given feature has got to do with how important it is, and how much it sucks relative to how important it is to customers. And that’s a very simple way to think about it. The temptation, by the way from any of these frameworks, even going back to mine with the thing with the two axis, is that you’re gonna go and draw up a list. And, you’ll be like, ok, these are all the things you’re gonna work on.
Be careful how you use lists in your product map. This sounds like a meta point, but I see this happen a lot where people do some research and they come up with a list of things we need to work on. And here’s our team. But what does your roadmap look like? It’s tempting to go and ship all of the things that matter. That seems somewhat rational but you’re ignoring a lot of things here. You’re ignoring how important any of these projects are and how hard any of them are as well.
The guy from Google Docs, wrote a simple article about this. Google Docs did exactly this, and then eventually they met some actual customers. And they said to customers: “We’re working on everything that matters.” But the customers were really upset. So the Google Docs guys gave each customer $100 and let them can choose where to spend all your efforts.
So he gives $100, and said, just drop it in the bucket of whatever feature you want. The most incredible thing happened. The funniest thing was one user went over, dropped their $100 into the bold, italics, underlining and formatting box, opened up their wallet and put in another $100 of their own cash.
That’s hilarious but it touches on something that’s not well captured in lists – where your users care has nothing to do with the list of things as you’ve prioritised them. And if you actually knew that, you would do as Google Docs did. Which is you’d say, well, actually let’s get everyone on that until that problems gone away. It’s the Babe Ruth problem. If you sort all baseball players by all time, it will look like Babe Ruth’s number one and someone else is number two. But the gap is huge. Just like if you ranked the solar system by habitability of planets, you can’t say we should go to Mars because Earth is probably too packed. It doesn’t work like that. Sometimes there are binary, very significant players on your list.
So now, how could we get people to use the feature more? The simple tricks here which are relevant are things like: how can we create habits, or use triggers or create rewards, or use smart defaults, or smart contacts, or more ways to get people to use this feature. For example, if we take something such as: I want people to refresh their Twitter feed more. Well, we could either put more stuff in it. We could trigger them to send them notifications. We could send them more triggers. We could make it refreshable and mobile. We could send them an email list of it. We could make them refresh it on their watch. But all of these things make it easy to use the feature more.
Take the push for pizza example, a popular app in SF at the moment. It has one button, you push it and it will order pizza for you. They’ve used smart contacts to where it defaults to make it very easy to do something frequently. So, when you’re sitting there thinking,if you want food, could actually have a pizza show up in 20 minutes if you just press a button. You’re gonna do that more than you are going to go to the Domino’s pizza configurator and go through a five step wizard asking you all these various question. When you’re looking for frequency, these are the things you need to think about.
Looking for adoption
If most, but not all people are using this, what’s going on there is your question. The best thing to do is work on why they’re not using it. Specifically isolate these people. So, you say: “Most of our users use or data visualization tool but you don’t. I’m interested to know why.” Keep asking why until you get to something that that is actually actionable for you.
All you’re interested in here is what is stopping customers from using this feature. Not whether they want to use this feature. If someone says I do not ever want to do this, no problem. Don’t take their feedback because they’re not the right person to talk to. But as you get this, you can then rank and resolve these things as being reasons that customers aren’t currently using our feature. And you’ll see things like: “I don’t know how to share them.” “I don’t know what to use it for. “ “It doesn’t work on mobile”. And these are all the reasons, why all your users aren’t using it. Every single one of you has unadopted features in your product, guaranteed. Most people would use it if they just knew what the hell it was. What they could do with it? Why they should use this?
Deploying code isn’t always the solution when these things happen. Sometimes, for example, you can actually use communication to make these points. If someone says, I don’t know what to use it for, well then maybe the first time they go to the screen, you should start a conversation saying, here’s three cases that people actually do with this thing. Or maybe if somebody says, I don’t how to share, you could show off your sharing tool. Any of these things.
What I’m really saying is that you shouldn’t fall into product blindness, which is we need to feature our way out of this. Sometimes you need to communicate our way out of this. You can’t fix the problem with code when it exists in your customer’s heads. If they don’t know why they should bring your report to a meeting, that’s the problem you need to solve sometimes. Otherwise, they’ll never use your report.
New features are like the kind of the sexiest part of software. The ones where you get the marketing push and the drama. You get to do like your whole write up, and the whole team gets to celebrate. Most features flop. That’s the sad reality of software. One of my favorite stories comes from Microsoft, who have the wonderful press page where they make this really interesting boast. In a recent customer survey, we asked users, what they wanted from Microsoft Office. And more than 90 percent of the features that they asked for, were already in their product. For some reason, they were happy about this. You can sort of see why. We built all those things. And they never actually joined the second dot and then Jesus Christ, what happened?
What happens is interesting. Most new features, even if you build them well, polish them well, and they actually represent a real need of real customers, they can still flop pretty badly. A few things that help: sell what the feature lets the user do, not what it is. We can easily sell the ingredients of a feature. And that’s actually the bios for most people. Let’s break it down by all the things we built to enable this, and here’s what it is.
And you spend so much time describing almost in minute details that only developers care about. It’s got a really fast API and all this. Whereas what the user actually cares about is what can I do today because of this. If you haven’t answered that question, what they’ll do is they’ll archive their email and jump to the next thing that they have on their plate. Because you haven’t given them any new power. When you’re selling people what you can do, that’s the best thing to be able to say to users.
Another thing is to announce features in context. I guarantee you that when Microsoft Word or Office launched all these features, I’m sure that they did put it into a manual somewhere. And maybe it was on their blog, on their marketing site. It might even have been in the Help notes of their product. But none of those places are you likely to be when it occurs to you, when you need to insert a table of contents. Instead, you’ll say: I wish Microsoft had a table of contents.
If you announce it in context, by telling someone to try our new date picker or by showing to them when they’re in your product looking to set a date. That’s the useful thing to do. Emailing them on a weekend to say, hey, we just launched the new date picker, it’s like, so what. I don’t care. So,Announcing it in context of the time when users are likely to have the need, is always really impactful versus the alternative.
Think about tomorrow’s customers
If you launch something today, with a big furore, a big press launch and all that, that’s all great. That will tell all your existing customers how something works. And then somebody signs up tomorrow. And they didn’t see any of this because they weren’t your customer. How are they ever gonna find out about this feature? You have to have a plan for this too. Spotify is great for this. Every time you relaunch, they’ll say check out all this new stuff. But if you’re a new customer signing up they don’t bother explaining it all. Because they think if you’re new you must already understand it for some reason.
After you launch like, it’s important to fight for usage. People just think that once it’s gone out the door it’s done, my job is over. But you actually have to fight for usage. Talk to people who are using it. Does it do what you hope it would do? Talk to people who aren’t using it and ask why you’re not using this feature.
So they’re actually sort of tips to actually help you launch new features with some elevated degree of impact. That was the four types we talked about. So, improving a feature, adding a feature, getting more people to use it, getting people to use it more. It’s worth saying that your balance for those kind of defines what company you are. But it really shifts over time. When you’re starting out, you’re mostly building new features cause you don’t have any features. That makes sense, right?
If you do a big release, then you’re gonna be chasing adoptions. You’re gonna be trying to get more people to use the feature you built. If things are going well, and loads of people are using it, you’re going to spend a lot of time improving the stuff you’ve built. Right? But your roadmap has broken down, it’ll shift it over time. But it should be a cognitive cognitive shift. Not something that kind of happen by happenstance.
Revisiting assumptions
Startups move ridiculously fast. That’s a trite thing to say; you never hear like CEOs Fortune 500 saying, our goal is to move really slowly as a company. We do not want to innovate. But it is true startups move fast. And what that actually looks like is you make a phenomenal amount of decisions, where you don’t know the right or wrong answer but you have to make a decision to move on. So, you do it. And you pick a particular decision path and that’s the history of your company to-date. And then the sad part is someone comes along and they something like the social network or whatever. And they say here’s the A to Z story of why Facebook was inevitable. Except they do even better. They kind of present this as linear narrative. And whenever you kind of read about any sort of startup that’s been successful, whether it’s a Twitter or whatever. You’re kind of reading this perfect narrative of the inevitability of their thesis. And as the Founder and CEO of the person who’s actually ringing the bell on NASDAQ, of course, you kind of want to be like, you know what, you’re right. I was actually right about everything I ever decided to do in my life.
But because we’ve got this deluded sense of past, we built this into a deluded sense of future. We plan our roadmap to be something like this as well. We’re not ever gonna revisit a feature. Because we’re gonna get it right the first time, and everyone’s gonna use it. Why would we look back? That’s a waste of time. The thing is, looking back is actually really useful because it does tell us that we shouldn’t really plan. In Intercom, we kind of have like a three months and three year perspective. We know what we’re doing, and we know where we’re trying to go. But trying to talk about what we’re doing next February is a waste of time. It’s just a waste of time. We don’t know because, what we do this month could keep us busy for a year. Or it could keep us busy for a week. So, it’s worth thinking about that.
The piece that pops out of all that is when you’re making all these decisions, you’re actually getting smarter over time. So, you know a lot more about your company, and your domain, and your team and everything. People often say, hindsight is 20/20. And I’ll say, yeah,it’s awesome. We should use more of it, right? But for some reason we just ignore it.
When you get new information, as you get more aware of your domain over time, you may change your opinion and you should act on that change. So, if you knew then what you know now, would you still have built that feature, would you shift that into integration, chose that architect, or design that screen, structured your company that way? You know, hire that person?
The point I make is that the mistakes you know about, what you aren’t correcting, are just mistakes you’re making every single day. So, it is as I said, there’s a lot more going on in companies and product for sure. But product’s what I’m closest to. What I wanted to do was talk a little bit about bringing you from here to the sort of complex messy stage when you’ve got much bigger and messier problems. And if this talk brought you anywhere along the way, that’s been great.
Comments