October 20, 2015
Ep. #5, Overcoming the Fear of Shipping Code
In this episode, Edith and Paul talk about the fear of shipping, and whether code is an asset.
I'm speaking about product strategy in startup. That is a beautiful photo of this exact place. I did not realize I'd be standing in front of it twice, but there you go.
"Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat."
When I see any evidence of tactics without strategy, I'm reminded of groups such as shown here, basically 180 startups all trying to do the exact same thing. This thing is some version of social media analytics. What separates the winners from the losers here is fundamentally product strategy.
I think of product strategy like this: You have a vision of what the future looks like. You have belief in your product strategy, and then you build a product based on that.
To flesh that out a little bit more, you have a vision which gives you a mission, you have a mission which tells you the jobs that you need to build a product to solve. The product you build is then what comes out of that. You need to then evolve that to keep it lean so it does not become a bloated solution, which is unfortunately where most of them end up.
Another quote I love is from Alice in Wonderland which I'm sure you've all read and read frequently; she has a blog these days.
She gets to a scene with the Cheshire Cat and she asks the Cheshire Cat, "Which road should I take?"
He says, "Where are you going?"
And she says, "I don't know."
He says, "Well then it doesn't matter."
Literally, if you don't know where you're going every decision sounds like the right decision. You'll hit this frequently in product design.
If you don't literally have a picture of the future of what you're building for or what the product you want to realize is, every decision becomes near impossible. Except for you don't realize it because both answers are correct, because it doesn't matter.
When I talk of vision what I really mean is there is two components to a vision. The strong piece is what's changing in your target domain. If you're building a project management tool and you're ignoring the fact that remote working has basically become almost dominant in the workplace over the last five years then you're not building something for the future. If you're building a music app thinking that people still buy music, you're not building for the future. If you're building marketing and you're still relying on direct marketing, you're not building for the future.
One piece of it is the target domain you're going for, whether it is development environments, or whether it is hosting platforms, or whether it is something like project management. One question is what's actually changing in that area itself, independently? The second side is what's changing in technology that enables you to get there?
The obvious shifts that we see frequently are something like the phone being the primary device that people use. It is true to say, if you look, 70 odd percent of emails are now read on mobile phones or mobile devices.
Most people from Outlook all the way up don't really acknowledge that trend despite the fact that it is the dominant trend. I guarantee you a load of you guys are sending emails from your tools, whether it's a build management system or a hosting platform, or whatever.
I guarantee you, if you're anywhere near my age when you go to design those emails, you draw this square which is like the beginnings of a wireframe and you start to lay out your email. You don't realize what we should be drawing is a phone and drawing an email that sits in it, because that's where it's going to be read even if the dude is in front of his damn computer. I literally see this happen all the time: people with a 30-inch iMac in front of them and they're like this dealing with email because it's quicker.
Other shifts you should be aware of. If you're anywhere thinking about hardware, all of this shift around the wearable devices right now is in that really awkward early stage where most people who have them, whether it's a FuelBand or Google Glass or whatever, are something of the edge case. It's the thing that your mother asks you what you're wearing sort of thing. But it will get there.
Other trends, social networks. The idea that basically all of your customers are connected through principles of sociology called homophily to other people exactly like themselves. Hands up here who's a developer. A good chunk of people. Hands up here who has developer friends. The rest of you. People hang around with people who are like themselves, that's just the way the world works, and because of this they're super connected.
The other trend that popped out of this is all software starts to look like Facebook or versions of it. As was said earlier, I was involved with Exceptional in the early days. I was talking to a dude who's working on an exception tracker because everyone has the frustration of "all the tools are crap, mine won't be." Then they build it, then they get users and then theirs is crap too. He was adding 'like' buttons to exceptions. I thought that was a wonderful principle. I'm like, "I like that this thing just happened." I couldn't even tell him he was wrong because basically most software I use these days seems to have them.
When we talk about the vision for a product what I really mean is what does the domain you're tackling look like in X years and what does software itself look like in X years? That number X is kind of the distance of your vision, if you're being opportunistic and you see that you recognize a small, short-term opportunity.
A classic example would be something like maybe seven, eight years ago realizing there was one thing that iOS developers will definitely need, so we go ahead and build it. Right now, honestly, there's probably an opportunity to disrupt Xcode because there's this meme going around that it doesn't scale, it's too bloated at large sizes. No one's really going after it, it's probably there for the taking. You probably don't have to think about the 20-year vision for that, it's probably actually a short enough term thing.
When I talk about the vision for your product you should be able to confidently answer both of those questions.
The next thing you build upon that is a vision. A vision in it's simplest definition to me and the one I like that's cleanest is, "Why do you exist other than making money?" Making money is the predicate for any business to stay alive, for the most part, but there has to be something else. If you just exist to make money you won't last too long either.
Missions to me have nothing to do with goals or targets and they're not about being number one in any given category. It's actually a stronger question. How will the world change if you actually succeed?
If you get what it is that you want out of this, how will the world actually be different? When I look at companies like Heroku, the world is actually different because of the fundamental shift in how developers work that they enabled; it's literally different. The company could go bust today, but the world is still different.
When I see a GitHub ad, their actual mission statement straight from the website is: "To help individuals and companies, public and private, write better code, faster." When I see initiatives like the GitHub Education they launched yesterday, you realize that maybe this company could never IPO, they could get hacked by 'anonymous' tomorrow and disappear off the world. But the whole world is still different because they existed.
What pops out of this is the jobs that you want to build for. There's a line of thinking that I encourage people to follow, which is called in practice "jobs to be done." One of the principles that it sits on is this, which I think is a really astute point:
The customer rarely buys what the company thinks that it sells.
We'll see this time and time again, and I'll show you some examples. A business has a few different hypotheses that you have to answer in the early days. From what I understand of the Heavybit community, most of you guys are probably post product market fit, but you're not all from Heavybit.
One question is are customers currently doing this thing that you intend to build a product for? Does it actually exist? To see that, you need to see some evidence that they're currently investing to solve this problem. Can you create a product that will actually do that? And that's where your MVP will come in. If you have a product that solves this problem can you actually get anyone to hear about it, can you actually address this market in any way, shape or form?
What Jobs To Be Done tells us is that customers don't actually buy product categories, and they don't purchase your product because of their demographic. I'm a 32-year-old male who earns a certain amount of money and I'm sure people in the Washington Post are thinking, "He's right in our demographic zone, why isn't he buying the newspaper?" Well it turns out that when I wake up in the morning my demographics don't pull me into a shop and be like, "Here, you're supposed to buy this, that's what people like you do."
What actually happens is a problem occurs in your life and then you say, "I need to solve this problem. What can I do to solve it?"
The classic problem that Basecamp and project management tools in general solve is this one, which is you get pulled onto a project and eventually Johnny Client will mail you and he'll say, "I've added three more people, can you forward them all the relevant emails?" You're like, "Jesus Christ, I have to go find all the relevant emails and forward them." Whereas if you have an existing project management tool it's just a case of adding them. That's what PM tools do.
Has anyone here ever freelanced? Do you recognize this problem? You're convinced you have the final version for a client, and they disagree. What you have is version one, version one dash final, version one dash final dash March, version one dash final dash March underscore DT. It just keeps going and going and going. You realize at some point there has to be a product that makes it easier for me to collaborate with a client and agree on what the final thing is. Similarly at some point your build process breaks and you're like, "Jesus, why did this happen. There has to be a better way, there has to be better software out there that does this."
What I'm talking about here isn't customer demographics. It's not about things like checklists or categories or any of that sort of stuff. Sure, some of those things correlate with what one of your customers might look like. For example, if you're selling to developers you might find a lot of them have a certain gender, live in a certain city, are within a certain age bracket and have a certain background. But that's actually not what causes the purchase, that just correlates.
As I often remind people, where I see firemen I see fire, therefore firemen cause fires. Right? Or, the more firemen I see the bigger the fire; so, they're definitely correlated. That's literally the line of thinking that people follow when they assume that demographics drive purchasing behavior.
To test if a product is actually needed you have to understand the job that your product will do and that job has a few different components. There's a problem, the situation that causes the problem and the condition under which somebody will pick the winning product. First piece is the problem itself which is what is the problem that the user experiences? What is the negative impact? You get to this by understanding exactly why does it negatively impact their business.
Someone might say to you, "I don't know what everyone on my team is working on."
I'll say, "Why is that actually a problem?"
They'll say, "I can't tell who is free to take on a new project."
I'll say, "Well why is that actually a problem?"
They're like, "Well I can't plan a feature roadmap."
I'm like, "Okay, you're trying to plan a feature map and one of the things that is important here is the current state of the business. Got it, no problem."
Or people will say, "Jenkins has fallen over again." We used to have this for ages. Why is that a problem? Well, we have to spend time and energy dealing with it. Why is that a problem? We've got all these beautiful, amazing developers who are literally plugging in machines as opposed to doing things like improving the business.
You will find this problem, but the evidence of a real problem looks like a checkbook stub. It looks like a swiped credit card or cash handed over for something. It does not look like a guy gazing at the window thinking, "Wouldn't it be cool if I could get all my social media files in one place?"
You can always tell when people are pitching something without a job because they'll begin with phrases like, "Wouldn't it be cool. . . " when in reality cool does not necessarily pay the bills. Isn't it a problem that I have to spend a lot of money to solve this? Yes, that's a problem.
Situational context. When does this problem occur? What are the events that trigger it and what are the invariants?
It's really important you have to understand any job occurs under certain circumstances. The classic one here is pizza. This example is from a guy called Allen Clement, who is really clever. If you have a real fuzzy definition of a situation: I want something to eat. At that point Harris' Steakhouse, McDonalds, Subway, some shitty Italian on a corner somewhere, Starbucks, they're all in play. They all do that job. But that's not actually enough of a definition.
As you clarify: When I'm in a rush and I want something to eat. When I'm in a rush, I'm starving and I want something to eat. When I'm in a rush, I'm starving and I want something to eat in one hand while I'm on the go because I'm not sure when I'll next be able to eat. You start to get a more precise picture of what the actual solution looks like.
The solution in this case, one could argue, is pizza. When you realize that up here we're saying Starbucks and McDonalds are in competition because they both do the job of something to eat, but down here we realize that McDonalds isn't actually in play here because it doesn't solve the one-handed criteria. Neither is a bowl of soup in play here because it doesn't solve the mobility criteria.
The more tightly you can define your criteria the more tightly you define your problem, and therefore what the solution looks like.
On the right here we have demographics which will tell you basically what a customer would look like, which isn't necessarily useful because it's what the problem looks like that helps you build. The demographics again correlate with the situation, but they don't cause it. This dude eats pizza. I have nothing in common with him, but I guarantee you we both had that job. We both needed to get full, get somewhere quickly. He probably has a little bit less time than I do.
Situations look like this: Someone emails me a PDF that I need to sign, and this is exactly how HelloSign pitched their product. It's brilliant, because we've all had that problem, right? For some reason in 2014 we still think that signatures matter. Someone emails you a PDF and you have to get it signed. The old school world has us doing things like printing it out, signing it, taking a photo with your phone then get that photo somehow back into the PDF to try and convince him it's the same original document. God bless us.
A lot of people have this problem: "I need to show progress to my boss, but obviously I want to show impressive progress otherwise I get fired." It's funny, every time I've talked to anyone who works on reporting tools, if they dig deep enough, they all have the same job â€” get me promoted or keep my job â€” because reporting is basically showing what I did well. That's what somebody sits down to reports tool to do.
Unless maybe you're, I guess, the manager. But for the most part people are looking for good news. They want graphs that are going to go high into the right. That's why they will play with date pickers and group by day, group by month. They'll do that literally until the cows come home, until they get the graph that looks good because that's what their job is.
When we talk about situational context what you want to look for is what's the chain of events that causes the problem that causes the desire for the solution. When you understand that you'll understand where to market and how to market it as well.
You'll understand things like, if you're marketing a tool against a certain library you might realize this library always spits out errors that look like this and the very second someone has that error I can help them. So, maybe it would make sense for you if you're a Rails freelancer to pitch against errors that occur in rails libraries, and maybe look at search terms for that and advertise against those search terms. You start to realize that there's actually a chain of events that causes someone to think, "Shit, I'm actually in trouble here. What am I going to do?" That's where you actually get to real behavior.
The last piece is just the success criteria. Unless you're really unique somebody else has already worked out the first two as well and they've probably built a product for it. The success criteria is the filter most people will apply to try and work out what the winner looks like. This is actually kind of where it's useful to know a little bit about your actual customers: are they rich, are they poor, are they fashion-conscious, are they design-conscious, or whatever. You have to pitch it against what matters to actual users. Does cheapness matter? Does high quality matter, or clear and simple or reliable?
I was talking to one guy who runs a project management app who literally loses customers hand over fist and can't work out why. The answer is in the bottom right-hand corner. He never for a second thought about print preview or any of that sort of stuff. Apparently, people still print out stuff. Of course they do, we know this. We live with these people, they're all around us. They're just not us, that's all. Until you actually realized that that's one of the filtering criteria, you won't realize why you're losing people.
Don't confuse it with what's cool for developers. This is probably the wrong crowd to say that to because most of you guys sell to developers, but it is also true that you should pitch it against what's useful for developers, not necessarily what's cool for them. Don't confuse it with what matters for designers either, which is a classic designer mistake. To say, "Our product is typographically stunning." Well if your end user isn't actually a typographer that really doesn't matter that much.
One way to understand the consideration set of your customers is, if you can imagine a line-up of products can you guess what somebody would pick, from you and your competitors, can you guess what they'll pick and why? If someone's sitting down and they're thinking Engine Yard versus Heroku versus Amazon. Can you guess why certain people will pick each one beyond marketing, because marketing obviously can overcome some strengths as well. That's just a summary of how I consider a product around the job it does.
The jobs that people do, believe it or not, don't change that often. However, the products they use to do them change all the time.
The job for anything is timeless. Here is five generations of product all doing the exact same job. I love the dude at the end with the book by the way; it's always good to see them. This is always used as, "Oh, this generation is so distractible. They don't do anything except for just look at their phones." Like as if that's a new thing.
This guy who knows a thing or two about building billion dollar businesses said a while ago, "Take any human need and use technology to take it a few steps, solve it and you're well on your way towards building a million dollar business." Where he says "human need" I think of as a job, something that recurs. The longer it's reoccurred, the longer the lifespan of your company anyway.
Photo sharing used to look like that on the left. When I was a child that's what photo sharing looked like. You had a photo box under your bed which you hoped your parents wouldn't see. The next evolution which we all were so impressed with and ran around to show everyone was you take photos in the digital camera, pop in a micro SIM, pop that into your computer, load to Photoshop, apply some filters, resize it, upload it to Flicker and then email all your friends.
We were so impressed with that because it did actually take out steps. The steps it took out were getting your friends over to your house or going over there with a box of photos and that sort of stuff. Then, of course, another one came along which is just the same job again, it's just this is taking out even more steps. Now it's how do you get a cool photo spread to your friends? Now it's like three taps. If somebody gets it to the point that it's like no taps or one tap, they'll actually outdo this again. Sad as it sounds, we are lazy as fuck.
Square Cash. How long has transferring money from one person to another existed? Genuinely these guys have reduced it to an email. It used to be get your IBAN number, get your international bank transfer, sort codes, mail all those things around, then call it in to Western Union. All that sort of stuff. Now it's like knock somebody an email. Done. Next problem.
Everyone has been beating this problem since Blogger. This idea of how can we help people share stories and helping connect people to true stories. This is basically the Blogger 2.0 or 3.0 if you want to count Twitter as a middle step.
Jobs transcend technologies. They're not tied to any given framework, any given language, any given type of device or hardware. Your job isn't a laptop job or a tablet job, just like newspaper isn't wood, and Microsoft Word's job isn't tied to Windows. If they hadn't realized that maybe we'd be using Word on our phones a bit quicker.
Phone networks were convinced because all their profit was in SMS their job was to send SMSs, but their job actually was to connect people. Garmin thought their job was to be a SatNav but it wasn't, it was to show someone where to go. That's why Garmin and their TomTom both lost 65 to 70 percent of their market cap in the space of about six months once somebody else found another way to do that.
And the university's job isn't tied to a building. Things like YC, the organizations like this are actually competing with universities because the job isn't red brick and old professor, that's not what people go to university for.
Think about the job first and then think about the product. It's much more interesting to think about the job first because you'll see trends and you won't always be comfortable with them.
You'll see things coming out, "That's going to be a problem for us because that does the exact same thing in a quicker way." The temptation here is to try and belittle it or say, "No one's ever going to try and edit a Word document on their phone." Until they can.
The other thing is that jobs beat categories. These guys here are obsessed with the idea that they're in the newspaper industry, and they're blaming all their problems on the newspaper industry. They're looking to their left and to their right and they're like, "Where are all the profits going? Are you taking them Daily Mail? Are you taking them?" They can't work it out. Whereas their customers just want something to read. That's the job â€” something to read.
Weather websites are hilarious for this. They're obsessed with being weather websites. It's always about precipitation depths and all this sort of crazy shit that no one knows about. That's not what people actually care, but look at all these graphs that mean nothing. People want to know, "Is it going to rain? Do I need to bring an umbrella?" These are the questions people actually have.
Every bit of innovation in the weather space is down to providing information that people actually care about. Not six month forecasts and that sort of stuff.
We learned this the hard way in Intercom itself. In Intercom we built this tool that maps out your users. This is the users of some company mapped around the world. We thought we built a map so we were like, "Why is the map so popular? It makes no sense. What use is it?" Then we realized why do people use the map? "I want to impress somebody at a trade show, I want to impress people on Twitter, I want to impress investors. I want to show them that I've got this global company, that distribution won't be a problem for us, we've got it cracked."
What we realized once we actually learned this is that if we think it's a map we're going to build the wrong product. If we think of a map, what do maps have? They've got precise filtering, geographical accuracy, clustering of hotspots, that's the sort of shit we should focus on, right? Well no! It turns out no because the customer doesn't buy what the company thinks it sells. People are using this to impress people so what do they want? A beautiful map. Why don't we animate it, make it a fullscreen, let them download it as a keynote slide? That's what people actually wanted it for.
We rolled out this thing which is just change the map box and add some typography. Everyone's like, "Oh, I love the map again, it's amazing!" We're like, this is actually a worse map. In every quantifiable way possible it's worse. But it's actually a better tool for impressing people.
One thing is, if you find yourself struggling to identify a job, just be careful, because technology that doesn't find a job, fails.
Segway, for example, was something that everyone thought this is a technological advancement therefore it has to be a great idea. It turns out it's not actually that useful to travel slightly faster than walking, but slightly slower than running at a height about one and a half foot taller than most people. Which is basically what a Segway does if you analyze it. It has some advantages: You don't get tired because you're not doing anything. You're a little bit taller so you can see over groups of people or whatever.
You look at what sort of jobs would you have where not getting tired because you're on your feet for a while and being to see over groups of people matter. You start to realize, tourists have this problem. They want to walk around a city all day and see everything, but they don't want to get tired from doing it. Tourists have this problem. Mall cops or airport police have this problem, and that's why they use Segways. People who want to patrol an area, security guards, they actually have the problem. This is a much smaller market than walking which is what Segway thought it was targeting.
Google Glass is still working out what its actual job is. There is undeniably amazing breakthrough technology there but it's yet to hit on its killer use case. You can evidence that by every time somebody shows me Google Glass they put them on my face and say, "Now say 'take a picture.'" I'm like, that's actually not that useful to me. That's more steps than taking a picture is normally.
Google Wave had this problem as well. Google Wave also had killer real-time technology for collaboration and all that, but they never actually pitched it against what the actual job it should be used for is. It was kind of group collaboration but it was also playing chess but it was also collaborating on games.
They just kept adding stuff but they never actually said, "With all this technology what killer thing can somebody do?"
When we talk about these 180 tools here, they're all going for the category play and they're not actually focusing on the jobs. As a sidenote by the way, breakthrough, whenever you hear, "This is a breakthrough technology," the one worry is sometimes the technology can proceed the job. Breakthrough is up here in the top left where you've made massive technological achievement, but you've yet to actually get much impact in the market because people don't really know what to do with it yet. One could argue Google Glass might end up there. I actually am pretty optimistic on it in certain ways.
Disruptive technologies, stuff like these new weather things, they're interesting because they don't actually have massive changes in tech. Usually what they just have is a much better definition of what the job is. Then you've got game changers which are, this is where you actually unleash new technology and present it along with things it can clearly do.
It's worth considering, when the iPhone was demo'd it specifically showed you all the things you could do that actually were real problems: Where am I? Where is the nearest Starbucks? Those sort of problems. Play some music for me. They focused on that. I say that only to warn.
There's this phrase, "You can recognize the pioneers by the arrows in their back." I think the US equivalent might be, "The first guys get the arrows the second guys get the land."
The point being, if you're out there first what you might do is show everyone your potential, but you won't actually capture it yourself.
When you think about the product you're going to build your product is going to tackle a lot of different jobs. A project manager has jobs of updating clients, reviewing progress reports, checking performance of team members, working out completion dates for projects. These are all different things. You can't really tackle all of them, it's just too hard.
If you tackle all of what it means to be a project you're talking about invoicing, you're talking about negotiations, you're talking about CRM tools, you're talking about post-contract maintenance. That's a big flow. And if you try to take all of that on you'll end up with a bloated piece of work that only suits the workflow of a small subset of people.
When people talk about MVP, what it's really the smallest amount of product you can build to complete a feedback loop. To get the feedback loop you have to actually have somebody using the product you think you're building. This is my worry with people and so-called concierge MVPs. These are the ones where they pretend it's software, but it's actually a human behind it to check it.
If you're a flight booking service, you might have a concierge version which is actually a lot of people Googling. People come to one site and then you mail them with the answer. All you're testing there is market demand. Which is totally fine, that's a good thing to test, but don't confuse that with whether or not you can actually deliver.
As I said, a product MVP should test the smallest subset of a workflow that you can actually capture. A lot of this has got to deal with where you decide your product stops.
The temptation honestly is always to try and say, "My product is going to do all of this, and every other piece of software in the world is junk except for the stuff I write." We all think that, don't worry. You have to still be looking and say, "Our product stops here and starts here." The great products do that.
Basecamp ignores contract negotiation. It ignores sales and invoices and all of that stuff. Nothing about Basecamp implies it's going to do any of that for you. It's not in their marketing, it's not anywhere else. Basecamp is the tool when you've agreed a project. It's not even a consultancy project, it's just any project.
Keynote doesn't care about the fact that I have a lot of Post-its and whiteboarding to do before I come here and speak. Keynote says to me, "Des, when you've got your presentation and you know the slides you want to do, I'll be with you. I'm going to stick around until the very last slide and then I'll go. I know you're going to go to SlideShare or SpeakerDeck and update your slides and upload them and post them to Twitter, but that's nothing to do with me." That's Keynote's attitude.
Skype gets people to call, but it doesn't try and get me friends. Last time I launched Skype it actually asked me to build a social network, so I don't know. Usually it shouldn't.
Where do you start? You start at the first point in a workflow where you can add some value â€” so it's the first area where you think your product can actually improve upon what the existing thing is. From that point you should always look one back and see, "Can I integrate with what happened right beforehand?"
Some great examples of this: I remember in Exceptional we linked the first line of an exception to a Google search because we found that that's what everyone was doing, basically. If you always look at the steps on either side of the flow and try to gel with them it will work pretty well.
If you're building a product to organize your travel plans, it turns out you shop around sites to find flights, you look for the cheapest flights, you share the flight with your friends, you see if they want to do it. If your friends all agree you go and book the flights. Then you share the itinerary, then you hand out a calendar to everyone. That's a whole big messy flow that's done in lots of different ways. You probably don't want to take on Expedia or any of those websites if your goal is travel plans.
What I love about something like TripIt is their job starts the very second you have booked a flight, "Forward your receipt to us and we'll take it from here." That's what they do. They'll do the whole job of updating your calendar and all that sort of stuff for you, but they integrate perfectly with the previous step.
Then where do you stop?
Stop when the next step has a well-defined market leader.
Stop when the next step is completed in loads of different ways and especially if it's loads of different ways geographically.
The classic example for me is always payroll processing. A lot of employee management tools decide, "Oh yeah, we'll do the payroll bit as well." Payroll processing is basically handled differently by most countries around the world. Even those in the EU have different opinions about how you should do it. Tax is calculated differently, all that sort of stuff. You're better off not touching it, unless you want to be a payroll processing company.
Lastly, stop if there's somewhere you can't deliver any value, leave it be as well.
If the next step is ring the client, I wouldn't go and add a Twilio integration. You're not going to add any value.
In an MVP, you should stop where you've solved a cohesive problem, there's a natural stopping point. The reason MVPs are useful â€” a way to think about this is Gall's Law, which I'm sure some of you have heard. Gall's Law says: A complex system evolves from a simple system. You can't start with a complex system, and people who try to always, always suffer.
This is why I advise people to start off with a smaller subset because it just gets incredibly messy.
I call this the Scopi-locks principle. If you're product's too big no one can adopt it because it doesn't map on to any one person's workflow. If you're product's too small you'll be labeled as a feature, not a product. If you're product's just right that's when people actually adopt it.
The way you actually keep it just right is to get good at saying no to things that are pretty much definitely good ideas. There are hundreds of good ideas to add to your product, and there's hundreds of good reason to do so. You'll be told, "We added this little thing and look at the engagement it gets."
One classic problem or fallacy with the engagement thing is that actually new engagement? If you study the engagement of something you add to your product of course it will go up. Where else could it go? What you actually have to concern yourself with is, is the engagement anywhere else in your product going down? This is ultimately why Facebook don't add a dislike button because they're not going to generate any new engagement. People used to write comments, now they click the like button. It doesn't matter.
Also is it the right engagement. You could add Tetris to your product. You could add Tetris to your exception tracker or to your SDK. The question would be is that the right type of engagement. Is that actually what you want to do? Just because people are going to use it, is that any use?
Or you'll hear the argument that it's a really small feature. What I despise most about the really small feature isn't the obvious part, which is that it's not so small, but it's the idea that the size of the workload has anything to do with whether or not you should do it.
You don't decide a product based on whether or not something is quick to do.
I could walk out the door pretty quickly, that's not a smart thing to do here â€” when you're giving a talk anyway. Or, maybe it is, I guess.
There's the other side which is the piece that everyone intuitively gets, which is this idea of the actual feature that you think is small is now a part of your API, and now has to be reflected in your iPhone app, and you have to update your documentation, and you have to update it in your Android app. Then you have to maintain it in all future things going forward. Bet you didn't think of that one as a five-minute code addition, did you?
Another classic one for early-stage startups is this one, which is you get this feature of blackmail. "This customer is going to quit! We have to add it or we're going to lose this customer." That is exactly how you will end up with consulting-ware, by adding features one-by-one just this once for just this dude.
Or, "We'll make it optional. We'll add it as a preference, make it a setting. Not everyone wants it but we know that so it's okay, we'll just hide it behind settings." Boom. You have seven pages of settings. The danger of this, and everyone intuitively gets that this is settings hell, is it's pretty confusing or complex in terms of UX. The harder part that people don't get is to market a product that's so complex and messy is really, really hard. You're talking about 30 pages of marketing materials to try and communicate all the different things you do. It gets really, really difficult.
Another classic is, "We have nothing else to do so therefore we may as well build it." This is the idea that you've got two developers, anyone who's in a product manager or CEO type of position will always find this. They're like, "Oh my God, John's doing nothing. I need to come up with something for John to do. I don't know, do you want to go and do multilingual stuff?" They're like, "Oh, okay." You give the quickest thing off your head that you know will keep him busy, or her busy. That's rarely going to lead to a great feature.
An alternative is the old principle you learn if you've ever worked in a kitchen, which is, "If you've got time to lean you've got time to clean." If you ever watch Gordon Ramsey's program that's what he always reminds people.
If you're standing around in the kitchen there's always work to be done, it's just not making new food because no one's ordered it yet.
Another classic is you'll look at your competitors and think, "We need to copy all these features because they've got reports projections, distribution metrics and alerts." Whereas they're looking at the same product going, "Christ, we never should have built that one, this thing's broken. That one never made sense. We only did that one because we had nothing else to do."
What you realize quickly is the road to delivering broken technology, or yesterday's broken technology, is to copy what your competitors are doing. They're in the process of getting rid of it, you're in the process of building it.
Before you let any feature creep into your MVP you should go through these questions. Does it actually fit the vision of what you actually set out? Is it a forward step? In Intercom we could argue we should integrate with fax machines because that's a way to communicate with users, but it's not a forward step. Does it belong in the workflow for the majority of users? Is it necessary to achieve PMF? Will all the customers use it in roughly the same way?
The last piece I want to talk about or actually the second to last piece is "how many people use each feature" is a great question to ask. This is Analytics 101, this will take you like five seconds of SQL. Plot out all your features against all of the people versus all of the time and you'll quickly see these trends.
The goods of your product will be buried in the higher right, that's what people are actually using your product for. Oh and by the way, cut out all your administrative features like reset password and stuff, that doesn't belong here.
If you've got stuff in the top left it's trouble. It's either trouble or your enterprise plan features, in which case you've thought about this and it's okay. But then you should actually question are all of your enterprise customers using it. Another simpler way to think about it is this, what percentage of people have adopted each feature?
This is the dream app, this is the one we all think we're designing. Everyone is using everything. In reality it will look like this. You built a product that had messages, uploads and a document editor and everyone loves it. Then you've added on a chat room and that didn't go so well, then you added the calendar and that didn't go so well. Now you've got this time tracking features that's kind of getting there. If you're looking at this sort of shape you're probably going to get disrupted by somebody who just does that one thing. That is when you're vulnerable to disruption.
When you're in this situation you have three choices with each of these features, well four. You should kill them, increase the adoption, increase the frequency or just make them quantifiably better.
This is the two options of frequency. You can get more people using or get people using it more. That's how you should prioritize any work on existing stuff.
To get more people using it, rank and resolve the issues that are stopping them from using it. This is actually genuinely where the five whys technique is useful. You might have a situation like users aren't using our reports feature. Why? They don't see the value. Why? They can't show it to their boss. Why? They can't get to a good format. Eventually you'll work it out, and you'll get to the root cause.
But don't just talk to one customer because occasionally it can be a little bit more complicated. You'll find these over and over again. You can then resolve the key issues, the fundamental things that are actually blocking people from using all of your product. This is what we call fish or cut bait.
Get rid of it or get more people using it. If you can't do either, get rid of it.
Frequency improvements are subtly different. Basically, what are the smallest changes we can make that will get people using something more? LinkedIn endorsements are a great example of this. Ever since LinkedIn added in these one-click multi-directional endorsements where accidentally you can endorse sixteen of your friends for WordPress, which we've all done accidentally once. Ever since they did that, what happens is people are logging into WordPress more. It's actually a frequency improvement.
What they're following is this principle: Have a trigger, some reason you're going to get there. Have an action you're going to take. Now, they shouldn't be deceiving you into the action but the action will happen. The action should itself get a reward. The reward will give you future investments such as, "Why don't you connect with John's friend," and you're like, "Okay." Now because you're connected with John's friend he's going to endorse you for WordPress, too, which means you're coming back here tomorrow.
Because I was talking to a guy earlier about pricing, I wanted to include a few bullet points on pricing. One of them that I see people frequently get wrong is they go into the graveyard, the bottom right. You've got high cost, low cost, self serve and high touch.
Enterprise is the top right. Enterprise is you make a lot of money, but it takes a lot of time. You invest a lot in your sales process.
Self-serve, this is where things like Basecamp are project management tools. This is anyone can sign up, they don't need to talk to you whatsoever and they can start paying you money, but it just won't be a lot of money.
Then transactional is stuff like your S3 bill. You don't talk to them but by natural usage you're going to end up paying them a lot of money.
Another one is charge earlier than you think you should. Free users will want more features, paying users will want better features. That's an important principle to get feedback. If you're listening to your free users too much they always want more stuff, they don't necessarily want better stuff. They'll guide you the wrong way.
Charge more than you think you should. If you're actually comfortable with how much you're charging it's not enough chances are. I say this from both experience of making these mistakes and talking to people who made it.
Here's a four man company, and here's what a 20 dollar bill amounts to. You can't see that line. It's so insignificant to every other expense that a four man company has. You could easily up that to like 49.99. The only point at which it's fair game to actually keep it that low is if that's the market rate by a competitor who is already dominating the market, in which case you'd have to question why you're coming in.
If you can't run a business off your lowest plan kill it.
You should always get a sort of Markov chain view of what's the chances of migration within plans? I guarantee what you'll find, if you're anything like the plenty of businesses I've spoken to, most people don't leave your lowest plan and most people don't leave the plan that they commit on. This is why meter billing is brilliant by the way.
These are the churners and low earners. They're small businesses that aren't going to ever get beyond the nine dollar price point. They're going to quit. There's more likelihood of them quitting than there is of them paying you more money. If you're not happy that you can be profitable at that nine dollar profit point if all of your customers are on it, then it's not a good price point.
Lastly, just plan to update your pricing. Most people have this perception that pricing has to stick around. Some of the bigger companies are good at hiding this, but every significant software company adds a lot of value to their product year on year, and that value will not be captured if you keep the same price. That's what this graph shows you.
That was everything I wanted to talk about. Thank you so much for listening.
Q: How specific and granular should you be when deciding what "job" or niche your product fulfills?
A: I would say pretty granular. The more you understand about the job the better you can always design the product. That pizza example from the slides is a simple enough one for me in that if you're designing for an exact situation that you think is common for developers, the company that has the best solution will be the person that maps onto the largest number of people with the most frequently occurring job.
I think you should basically invest in understanding it until you're finding out stuff that you can't act on. Such as "Turns out a lot of these guys are left handed," or whatever. Even that you could possibly act on. I'd say keep learning about the job itself until you can't think of anything else you could do to support it better. Or what you might find is that it starts to fork out. Like it turns out there's 95 different habits for copying and pasting or something like that, and there's nothing useful you can do about it and turns out it's not a pain point.
Aside from that I would say keep learning it. If you think about many of the big companies who have left us or disappeared in terms of status, I think it's because they've forgotten what the job is, or they've stopped investing in understanding it.
Q: If you're changing your prices, what's the best way to convey that to customers?
A: The question is if you're changing your prices, or as I'd say, when you're changing your prices, how do you communicate that to your customers and what's the rollout strategy? I think if you're happy that your current pricing was fair at the point you introduced it and you haven't heavily discounted or anything like that, I think you can argue that you should probably grandfather your customers for a chunk of time, if not forever, depending on the point.
In terms of introducing it, if you are grandfathering or awarding a significant discount to your current user base, they're not really likely to be casualties of it. It's actually new users you're talking about, right?
From a new user's point of view it doesn't matter that you were at $25 yesterday because they weren't here yesterday. Much like somebody who comes in tomorrow has no right to expect a Des Traynor talk.
I think the communication strategy is, if you're changing things for your current customers be careful, be sympathetic, acknowledge it, offer discounts if you are transitioning to new prices. For new customers, I wouldn't make a fuss about it. I see people occasionally do like, "We've launched some new pricing!" I'm like, "Right, and you want people to know about that?"
Launch a new product and roll out new pricing, but I don't think there's a need to actually make a big fuss about it for people who didn't know about yesterday's pricing. That would be my attitude there.
Q: If you've got a very loyal, early adopter, how do you refuse their feature request?
A: There's a few variations of that question. The question is if you have an early evangelist, a customer who is still with you from the very early days and invested in you from the very early days, invested their monthly fee or whatever in you, they believed in you when other people wouldn't, basically, how do you say "no" to their feature requests?
Much like pricing, the one point you have to bear in mind is as much as people want these new things, they probably want your company to survive more than they want that. If the alternative is going bust then they don't get any features. My attitude on this is similar to my attitude towards free users.
Free users are great but they have to respect the fact that for you to be free for them, you have to look after the business first, because if you look after them before you look after your business, you'll have no business and they'll have nothing. Right now they have something.
That would be how I communicate that. I'd say basically, "If we invest a lot of time building this feature for you, that's time that we will not have to invest in building features that are necessary for us to achieve product market fit, or for us to move up market or for us to be able to increase our prices. If we fail to do that, it doesn't matter what we did or didn't do for you because the server's going to go offline when the bill doesn't get paid. Then you'll have nothing left."
That's the one thing that everyone understands. If your company is going to disappear due to bad choices they won't force you to make them.
Q: How do you choose when to focus on marketing versus focusing on product?
A: One thing you should look at when you're considering your brand versus your product, the differences, is your brand actually has an architecture of sorts. At the base level of the architecture you've got your company values. For Apple this is "Think Different", or their stance is around creativity. It's like the whole iPad ad, "What is your verse?" That's the fundamental brand of the company. Then brands sit on top of that for different jobs.
The MacBook Pro has a brand that we understand and it's different to the brand of the iPhone 5c.
They target different products against different jobs, and they have a fundamental underlying brand. For startups typically the brand is the product is the company is the people. It's too early, you haven't split up.
But as a company grows, in my opinion, that the brand becomes progressively more relevant. Even a company like MailChimp, its brand is literally inseparable from its product. If you look at something like Mandrill which they rolled out. Mandrill doesn't carry as much MailChimp but again, they have specifically not called it MailChimp Mandrill, or MailChimp API, or whatever they wanted to call it.
A good example for this, I think, in the real world of how you separate brand and product is the Marriott Hotel chain. Marriott have the Residence Inn and they've got the business brand hotel and they've got the airport hotel. They're all different brands that all sit under this idea of Marriott. Marriott is supposed to be synonymous with quality, and Marriott Residence is actually synonymous with family. And Marriott, I can't remember what the other one is, is synonymous with work.
Honestly, I think startups who obsess over their brand beyond the basics like get your logo right, get your slogan right, get your marketing right, always make sure you present yourself in a good way and all that â€” going beyond that and trying to separate, like 37signals are a great example of this. They actually had a great brand and a great product, but they threw away the brand because it turns out it doesn't actually gel that well with the product.
I think in general I'd focus more on establishing a brand around a specific job.
When you want to drill a hole in the wall you think Black & Decker. When you move into a new empty apartment here in San Francisco you think IKEA. If you keep it restricted in that regard you'll always be well positioned, I would guess.
Q: How do you determine the price when there's nothing similar to your product in the market?
A: If you're launching and there's nothing similar in the market and you want to charge some money but you don't know how much is the right point â€” if you literally don't know how to charge, but you know you want to charge, I think it's totally acceptable to come in low with a caveat. Come in at like 40 bucks a month or something like that.
The reason it's still important to come in at all is it will actually tell you a lot about your actual customers versus the people who think they're going to be your customers but actually don't pay money for software because they don't believe that's right.
The first thing is pick a price. Once you pick a price, make it clear that this is your beta price, this is the price you're going to charge for the duration of blah. Honestly, you'll catch a lot of shit for even that, for actually just even asking for money. But you have to, it's just the nature of the beast. At that point you can decide whether or not to keep the free plan if you wish. It's kind of your call at that point.
From that point onwards, I would start studying usage and try and differentiate what a big customer looks like from what a small customer looks like. For some people a big customer has a lot of team members. For some people a big customer sends a lot of emails or uses up a lot of gigabytes on a server. Once you cut out all the free usage, you'll start to see what the axes of value is. Hopefully they'll map to people and to sizes of companies.
The reason most people go for company size as a basic axiom is because it's a good indication of payroll, which is a good indication of turnover, which is a good indication of propensity to pay money. But that's not always the case. If you can go transactional pricing, whether it's number of publications or number of hosted websites, that will work too.
I think the first thing is cut out the free because it's only noise. Then you will know what people are actually willing to pay. That's why I say come in low. Come in low enough that no one could feasibly not pay.
Your initial price should be probably basically where you think your smallest price plan will be. Then plan a refresh over six to twelve months to try and work out what the next logical steps are. You'll have actual data then from people who can pay money, which is what you need to guide or inform the decision.
Q: Do you believe products have personality and if so, where does personality fit in?
A: I believe that products can definitely have personalities, yes. It's closer to a brand value that your product should embody if it is really a brand value. It can definitely work. The tricky part is picking a brand value that won't turn off a large chunk of customers. You can actually be super successful and super neutral. You don't have to do this. If you do this it should bring something to the table for you, but it will come at the cost of costing you other customers.
It turns out there are companies serious enough such that a monkey on their desktop is not how they want to send email. Those guys use Eloqua or ExactTarget or Campaign Monitor, something else. However, for MailChimp's sweet spot it's the perfect brand because they're literally reaching out to every creative freelancer, every small to medium, certainly a lot of large businesses too, who are actually happy to adopt, "Yes, we use a playful company."
You don't have to do it, and if you're going to do it, it should be really well conceived. I'd make sure that it's natural or innate within the founders itself because you can't half do it, or dip your toe, or hire a designer to build it.
MailChimp have two full-time guys whose job is to draw monkeys. I think this is so cool. But it is true it has to be kind of innate because otherwise it's going to be something that you carry around with you. You can't switch it on and off, basically, so if you're going to do it, I would definitely say work out the pros and cons and then do it to the max.
Q: How do you balance a long-term strategy with a short-term ability to get stuff done?
A: I think you can have a vision and still be practical in the short term. The vision for me, as I said, it's specifically not about being number one or anything like that, but it is being aware of changes that are happening, fundamental changes if you like.
An example would be if you're building a product today that assumes that people don't manage projects on their phone, and you're building a project management app, I would say that you're correct today, but all signs point to you being incorrect in five years time. You should be thinking about five years, in that regard. It's almost like the tectonic shift is what you should watch out for in your vision, but yeah you should be practical today.
One thing to bear in mind is people confuse this idea with MVP. Your customer doesn't give a shit about what an MVP is or how many development errors you had or didn't have. They just want to use a product that does the job for them. People give you figures like 12 weeks or like 30 users or 50 this, or whatever, as some sort of pseudo-metric to gauge what you should or shouldn't do. I don't think that's a useful thing to do.
I think ultimately you focus on the job someone's trying to do and build against that. The reason I talk about strategy and thinking longer term is more to make sure that there's no fundamental shift affecting the job. Like don't be starting a newspaper in 2014 and assuming people read on a subway.
The mission is honestly a personal thing. I really don't believe people should work on things they're not passionate about, because you're going to be in it up your fucking neck for the majority of the best years of your life.
This is the scary bit, this is what they don't tell you when you're enrolling. But that is true. When I talk about the mission it has to really matter to you to do what it is that your company is aiming to do. Just because you can write a Rails app that can send invoices pretty quickly, if you're not really passionate about enabling small businesses to get paid quicker, you're not going to be the right guy to do it because you're going to run out of steam in 12 or 14 months.
When I talk about the long term, I'm thinking about the personality of the founders, I'm thinking about the fundamental shifts of the industry. In the short term, focus on building the smallest complete thing that your customer would value, not the MVP that you think you can ship .
Q: How do you feel about introducing features to test if there's a job they could fulfill, or even just to maintain good product momentum?
A: That's a good question. As I said, there are lots of valid reasons to add features. What you want to do when you're adding a new feature to your product is it's either a defensive move, i.e. "We are definitely losing customers because we don't have this and we are losing lots of them. Like, a chunk of our user base is leaving us." In which case you're backed into a corner, unless you think you know something that most of the world doesn't, or unless you've got something coming out that solves the same job but not through the exact same feature. Then, yeah, have to go and add that. That's one case, that's the defensive move.
The two other moves that we talked about, one is we want to capture more value so we can charge more money. That's a super valid thing to do. Related to that is, as you said, "We're going to build this feature to explore and see if we can capture behavior with it." That's absolutely fine. That makes perfect sense for as long as you're looking to expand your product.
When you're pre-product market fit that's the sort of things you should be doing. It will click at some point and people will start signing up heavily and using all corners of your product. The danger for me is when let's say you're a photo management tool and you're ignoring that your photo uploader is shit, but you're busy chasing filters because Instagram has them.
Remember that chart we had which is like all of the people, all of the time, if there was improvement to be had up there you have to focus on that first. It would be like having a bad sign-in form, whatever that looks like. If people use it every single day and it's crap, that's a really, really bad thing to do.
You shouldn't be exploring new features for as long as the fundamentals of your product can be improved.
But you will hit plateaus where you're like, "We've caught up with everything. Our docs editor works, our time tracker works. All the stuff works on mobile. We've covered off that, it's all well docked. We're stable. Let's playing V3 or V4 or whatever." Then yes, if you want to tackle exploratory features. This is honestly founder instinct, but it will be like, "I think we could do a plugin for a text editor that would actually send us back the test results before they even have to go to Circle or whatever." You're like, "Oh, okay. That's a really exciting idea, let's talk about that." Then yes, you can start building that.
Treat that as an MVP, that if it fails to capture a good percentage of your userbase, and if you can't realize that capturing in terms of value, i.e. can you charge more money for this, then I would say you're probably on shaky ground.
For the most part, when you have a solid product that no one is complaining frequently about common features in then yes, it's time to go and look for new features to add that will capture more value and there's loads of techniques for doing that. Most people I talk to don't have that first piece, but they're still going and working on this new sexy shit because Backbone got released and it looks really cool for doing whatever.
I guess my answer is yes, definitely go and release exploratory features, but the chances are you're probably not in the right place to do it yet, that's my hunch.
Q: How do you judge a feature that a few people use all of the time, if those people are enterprise users?
A: Yes, sorry, I just realized I was preempting your question. What I really meant by that was if you have features that are only available on your higher price plans you will find naturally, of course, that not all of your userbase can adopt them. In those cases, what you should be doing is that feature matrix per price plan.
You want to look at of all the people who can use these super powerful features that are in the top left. Once you say of all the people who can use them, are they still in the top left or are they now in the top right, because it turns out everyone who can use it does use it.
I make that point only because it's always useful to not take your userbase as an average of anything, because it's just not.
It's like saying the average human has like 1.91 legs. Doesn't mean it's typical, right? I say it only because people will talk, "On average our customers don't do blah," and I'm like, "Screw the average." Let's talk about all the people who can, let's break them into categories. Do they not do it or is it like half people do it all the time the other have never do it? The average will always hide all of that.
By the way, average conversion rate, just as a sidenote, is the classic one for this. People say, "On average our home page traffic converts at two percent." If you actually break it down by referring URL or by media campaign or whatever, it's never two percent. Two percent is like the wooliest thing possible there.
What you'll find is a great blog post that describes your really killer feature converts at like 15 percent, and those AdWords convert at like .01 percent, and you dilute the whole thing down. In general don't look at averages, but in that case I was talking about price plans.