I'm speaking about product strategy for startups. 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.
Product Strategy for Startups
I'm talking about product strategy today and the reason I thinkthis is really important is I love this quote by Sun Tzu inThe Art of War where he says:
"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 180startups all trying to do the exact same thing.This thing is some version of social media analytics.What separates the winners from the losershere 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 whichgives you a mission, you have a mission which tells youthe 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 itlean so it does not become a bloated solution,which is unfortunately where most of them end up.
Another quote I love is fromAlice in Wonderland which I'm sure you've all read andread frequently; she has a blog these days.
She gets to a scene with the Cheshire Cat and she asks theCheshire 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 everydecision sounds like the right decision.You'll hit this frequently in product design.
If you don't literally have a picture of the future ofwhat you're building for or what the product you want torealize 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 meanis 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'reignoring the fact that remote working has basically becomealmost dominant in the workplace over the last five yearsthen you're not building something for the future.If you're building a music app thinking that peoplestill 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 changingin that area itself, independently?The second side is what's changing intechnology that enables you to get there?
The obvious shifts that we see frequently are somethinglike the phone being the primary device that people use.It is true to say, if you look, 70 odd percent of emailsare now read on mobile phones or mobile devices.
Most people from Outlook all the way up don't really acknowledgethat trend despite the fact that it is the dominant trend.I guarantee you a load of you guys are sendingemails from your tools, whether it's a buildmanagement system or a hosting platform, or whatever.
I guarantee you, if you're anywhere nearmy age when you go to design those emails, youdraw this square which is like the beginnings ofa wireframe and you start to lay out your email.You don't realize what we should be drawingis 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'relike 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 mostpeople 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'rewearing sort of thing. But it will get there.
Other trends, social networks.The idea that basically all of your customers areconnected through principles of sociology calledhomophily 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 softwarestarts 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 exceptiontracker because everyone has the frustrationof "all the tools are crap, mine won't be."Then they build it, then they getusers 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 basicallymost software I use these days seems to have them.
When we talk about the vision for a product what I reallymean is what does the domain you're tackling look like in Xyears 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 thatyou 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 developerswill definitely need, so we go ahead and build it.Right now, honestly, there's probably an opportunity todisrupt Xcode because there's this meme going around that itdoesn'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 visionfor that, it's probably actually a short enough term thing.
When I talk about the vision for your product you shouldbe 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 youwon't last too long either.
Realizing Your Company Mission
Missions to me have nothing to do with goals or targets andthey'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 actuallydifferent because of the fundamental shift in howdevelopers work that they enabled; it's literally different.The company could go bust today, butthe world is still different.
When I see a GitHub ad, their actual mission statement straightfrom the website is: "To help individuals and companies,public and private, write better code, faster."When I see initiatives like the GitHub Educationthey launched yesterday, you realize that maybe this company could never IPO,they could get hacked by 'anonymous' tomorrowand disappear off the world. But the wholeworld is still different because they existed.
Jobs to Be Done
What pops out of this is the jobs that you want to build for.There's a line of thinking that I encourage people tofollow, 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 thecompany 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 thatyou 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 doingthis thing that you intend to builda product for? Does it actually exist?To see that, you need to see some evidence thatthey'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 youactually get anyone to hear about it, can you actuallyaddress this market in any way, shape or form?
What Jobs To Be Done tells us is that customers don'tactually buy product categories, and they don'tpurchase your product because of their demographic.I'm a 32-year-old male who earns a certain amount of moneyand 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 mydemographics 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 lifeand then you say, "I need to solve this problem.What can I do to solve it?"
The classic problem that Basecamp andproject management tools in general solve is this one,which is you get pulled onto a project and eventuallyJohnny 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 therelevant emails and forward them." Whereas if you havean existing project management tool it's justa 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 finalversion 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 productthat makes it easier for me to collaborate witha client and agree on what the final thing is.Similarly at some point your build processbreaks 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 orcategories or any of that sort of stuff.Sure, some of those things correlate withwhat one of your customers might look like.For example, if you're selling to developers you might finda lot of them have a certain gender, live in a certain city,are within a certain age bracket and havea certain background. But that's actually notwhat 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 followwhen they assume that demographics drive purchasing behavior.
To test if a product is actually needed you have tounderstand the job that your product will do and that job has a few different components.There's a problem, the situation that causesthe problem and the condition under whichsomebody will pick the winning product.First piece is the problem itselfwhich is what is the problem that the user experiences? What is the negative impact?You get to this by understanding exactly whydoes 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 isthe 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 machinesas opposed to doing things like improving the business.
You will find this problem, but the evidenceof a real problem looks like a checkbook stub.It looks like a swiped credit cardor 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 allmy social media files in one place?"
You can always tell when peopleare pitching something without a job because they'llbegin 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 lotof money to solve this? Yes, that's a problem.
Situational context.When does this problem occur? What are the eventsthat trigger it and what are the invariants?
It's really important you have to understandany job occurs under certain circumstances.The classic one here is pizza.This example is from a guy calledAllen Clement, who is really clever.If you have a real fuzzy definition ofa 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 ina 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 wantsomething to eat in one hand while I'm on the go becauseI'm not sure when I'll next be able to eat.You start to get a more precise pictureof 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 andMcDonalds are in competition because they both dothe job of something to eat, but down here we realizethat McDonalds isn't actually in play here becauseit doesn't solve the one-handed criteria.Neither is a bowl of soup in play herebecause it doesn't solve the mobility criteria.
The more tightly you can define your criteriathe more tightly you define your problem,and therefore what the solution looks like.
On the right here we have demographics which willtell you basically what a customer would look like,which isn't necessarily useful because it's whatthe problem looks like that helps you build.The demographics again correlate withthe situation, but they don't cause it.This dude eats pizza.I have nothing in common with him, butI 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 isexactly how HelloSign pitched their product. It's brilliant, because we've all had that problem, right?For some reason in 2014 we stillthink 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 itout, signing it, taking a photo with your phone then get that photo somehow back into the PDF totry 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 wantto show impressive progress otherwise I get fired."It's funny, every time I've talked to anyone who works onreporting tools, if they dig deep enough, theyall 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 andgroup by day, group by month.They'll do that literally until the cows come home,until they get the graph that looks goodbecause that's what their job is.
When we talk about situational context what you wantto look for is what's the chain of events that causesthe problem that causes the desire for the solution.When you understand that you'll understand whereto market and how to market it as well.
You'll understand things like, if you're marketing a toolagainst a certain library you might realize this libraryalways spits out errors that look like this and the verysecond someone has that error I can help them. So, maybe it would make sense for you if you're a Railsfreelancer to pitch against errors that occur inrails libraries, and maybe look at search termsfor that and advertise against those search terms.You start to realize that there's actuallya 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 elsehas already worked out the first two as welland they've probably built a product for it.The success criteria is the filter most people willapply to try and work out what the winner looks like.This is actually kind of where it's useful to knowa 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 projectmanagement app who literally loses customershand over fist and can't work out why.The answer is in the bottom right-hand corner.He never for a second thought about printpreview 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 filteringcriteria, 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 becausemost of you guys sell to developers, but it is also true thatyou 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 typographerthat really doesn't matter that much.
One way to understand the consideration set of yourcustomers is, if you can imagine a line-up of products canyou guess what somebody would pick, from you and yourcompetitors, can you guess what they'll pick and why?If someone's sitting down and they'rethinking Engine Yard versus Heroku versus Amazon.Can you guess why certain people will pick each one beyond marketing, because marketing obviouslycan overcome some strengths as well.That's just a summary of how I considera 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 productall 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 yourfriends over to your house or going over there witha box of photos and that sort of stuff.Then, of course, another one came along which is just the samejob 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 notaps 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'rein the newspaper industry, and they're blaming alltheir problems on the newspaper industry.They're looking to their left and to their rightand 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 allthis 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 toproviding 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 themap 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 ifwe 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 customerdoesn't buy what the company thinks it sells.People are using this to impress people sowhat 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 changethe 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 strugglingto identify a job, just be careful, becausetechnology that doesn't find a job, fails.
Segway, for example, was something that everyonethought this is a technological advancementtherefore it has to be a great idea.It turns out it's not actually that useful totravel slightly faster than walking, but slightlyslower than running at a height about oneand 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 youcan see over groups of people or whatever.
You look at what sort of jobs would you have wherenot getting tired because you're on your feet fora 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 seeeverything, 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 whichis what Segway thought it was targeting.
Google Glass is still working out what its actual job is.There is undeniably amazing breakthrough technologythere but it's yet to hit on its killer use case.You can evidence that by every time somebody showsme 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 forcollaboration and all that, but they never actually pitchedit against what the actual job it should be used for is.It was kind of group collaboration but it was alsoplaying 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 andthey'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 issometimes the technology can proceed the job.Breakthrough is up here in the top left where you've mademassive technological achievement, but you've yet toactually get much impact in the market becausepeople 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 newweather things, they're interesting because theydon't actually have massive changes in tech.Usually what they just have is a muchbetter definition of what the job is.Then you've got game changers which are, this iswhere you actually unleash new technology andpresent it along with things it can clearly do.
It's worth considering, when the iPhone was demo'dit specifically showed you all the things youcould 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 guysget the arrows the second guys get the land."
The point being, if you're out there firstwhat you might do is show everyone your potential,but you won't actually capture it yourself.
The Product You Build
When you think about the product you're going to build yourproduct is going to tackle a lot of different jobs.A project manager has jobs of updating clients, reviewingprogress 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'retalking 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 onyou'll end up with a bloated piece of workthat only suits the workflow of a small subset of people.
When people talk about MVP, what it's reallythe smallest amount of productyou can build to complete a feedback loop.To get the feedback loop you have to actually havesomebody 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 conciergeversion which is actually a lot of people Googling.People come to one site and thenyou 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 smallestsubset of a workflow that you can actually capture.A lot of this has got to deal with whereyou 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 worldis 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'sgoing 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 thatI have a lot of Post-its and whiteboardingto do before I come here and speak.Keynote says to me, "Des, when you've got your presentationand 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 SpeakerDeckand 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 itdoesn't try and get me friends.Last time I launched Skype it actually askedme 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 workflowwhere you can add some value â€” so it's the first area where you think your product can actuallyimprove 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 thefirst line of an exception to a Google search because wefound that that's what everyone was doing, basically.If you always look at the steps on either side of theflow 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 flightwith 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 flowthat's done in lots of different ways.You probably don't want to take on Expedia or anyof those websites if your goal is travel plans.
What I love about something like TripIt is their jobstarts 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 yourcalendar and all that sort of stuff for you, butthey 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 waysand 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 handleddifferently by most countries around the world.Even those in the EU have differentopinions 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'tdeliver any value, leave it be as well.
If the next step is ring the client, I wouldn't go and adda Twilio integration. You're not going to add any value.
In an MVP, you should stop where you've solveda cohesive problem, there's a natural stopping point.The reason MVPs are useful â€” a way to think about this isGall'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 smallersubset 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 becauseit doesn't map on to any one person's workflow.If you're product's too small you'llbe labeled as a feature, not a product.If you're product's just right that'swhen people actually adopt it.
The way you actually keep it just right isto get good at saying no to things thatare 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 thingand look at the engagement it gets."
One classic problem or fallacy with the engagement thing is thatactually new engagement? If you study the engagement ofsomething 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 theengagement 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 theobvious part, which is that it's not so small,but it's the idea that the size of the workload hasanything to do with whether or not you should do it.
You don't decide a product based onwhether 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 everyoneintuitively gets, which is this idea of the actual featurethat 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 youhave to maintain it in all future things going forward.Bet you didn't think of that one asa five-minute code addition, did you?
Another classic one for early-stage startups is thisone, which is you get this feature of blackmail."This customer is going to quit! We have toadd 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 settingshell, is it's pretty confusing or complex in terms of UX.The harder part that people don't get is to market a productthat's so complex and messy is really, really hard.You're talking about 30 pages of marketing materials totry and communicate all the different things you do.It gets really, really difficult.
Another classic is, "We have nothingelse 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 orCEO 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 thatyou 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 ifyou'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'sprogram that's what he always reminds people.
If you're standing around in the kitchen there'salways work to be done, it's just not makingnew food because no one's ordered it yet.
Another classic is you'll look at your competitorsand think, "We need to copy all thesefeatures 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 brokentechnology, 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 yourMVP 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 integratewith fax machines because that's a way tocommunicate 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.
Measure and Improve
This is Analytics 101, this will takeyou like five seconds of SQL.Plot out all your features against all of the peopleversus 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 featureslike 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 areall 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 theone 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 trackingfeatures that's kind of getting there.If you're looking at this sort of shapeyou're probably going to get disruptedby somebody who just does that one thing.That is when you're vulnerable to disruption.
When you're in this situation you have threechoices 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 resolvethe issues that are stopping them from using it.This is actually genuinely wherethe five whys technique is useful.You might have a situation like usersaren'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 occasionallyit 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 thatare 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 canmake that will get people using something more?LinkedIn endorsements are a great example of this.Ever since LinkedIn added in these one-clickmulti-directional endorsements where accidentally youcan endorse sixteen of your friends for WordPress,which we've all done accidentally once.Ever since they did that, what happensis 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 intothe action but the action will happen.The action should itself get a reward.The reward will give you future investmentssuch as, "Why don't you connect with John's friend,"and you're like, "Okay."Now because you're connected with John's friendhe's going to endorse you for WordPress, too,which means you're coming back here tomorrow.
Pricing and Product Strategy for Startups
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 wrongis 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 likeBasecamp are project management tools.This is anyone can sign up, they don't need to talk toyou 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'regoing 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 alwayswant 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'recharging it's not enough chances are.I say this from both experience of makingthese 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 otherexpense 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 keepit that low is if that's the market rate by a competitorwho 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 chainview of what's the chances of migration within plans?I guarantee what you'll find, if you're anythinglike the plenty of businesses I've spoken to,most people don't leave your lowest plan and mostpeople 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 toever get beyond the nine dollar price point.They're going to quit.There's more likelihood of them quittingthan there is of them paying you more money.If you're not happy that you can be profitable at that ninedollar 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 perceptionthat pricing has to stick around.Some of the bigger companies are good at hiding this, but every significant software companyadds a lot of value to their product year on year, and thatvalue 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&A with Des Traynor
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 thebetter you can always design the product.That pizza example from the slidesis a simple enough one for me in that if you're designing for an exact situation that you thinkis common for developers, the company that has the bestsolution will be the person that maps onto the largestnumber of people with the most frequently occurring job.
I think you should basically invest in understanding ituntil 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'tthink 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 differenthabits 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 leftus or disappeared in terms of status, I think it'sbecause 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'dsay, when you're changing your prices, how do you communicatethat to your customers and what's the rollout strategy?I think if you're happy that your current pricing was fairat the point you introduced it and you haven't heavilydiscounted or anything like that, I think you can argue thatyou should probably grandfather your customers fora chunk of time, if not forever, depending on the point.
In terms of introducing it, if you are grandfathering orawarding 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 wereat $25 yesterday because they weren't here yesterday.Much like somebody who comes in tomorrowhas no right to expect a Des Traynor talk.
I think the communication strategy is,if you're changing things for your current customersbe 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'tthink there's a need to actually make a big fuss about itfor 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 earlydays 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 isas much as people want these new things, they probablywant your company to survive more than they want that.If the alternative is going bustthen they don't get any features.My attitude on this is similar tomy attitude towards free users.
Free users are great but they have to respect thefact that for you to be free for them, you have tolook after the business first, because if you lookafter 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 thisfeature for you, that's time that we will not have to invest in building features that are necessary for us toachieve product market fit, or for us to move upmarket or for us to be able to increase our prices.If we fail to do that, it doesn't matter what wedid or didn't do for you because the server's goingto 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 tobad 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 consideringyour brand versus your product, the differences, is your brand actually has an architecture of sorts.At the base level of the architectureyou'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 andit's different to the brand of the iPhone 5c.
They target different products against differentjobs, and they have a fundamental underlying brand.For startups typically the brand is theproduct is the company is the people.It's too early, you haven't split up.
But as a company grows, in my opinion, thatthe 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 MailChimpMandrill, or MailChimp API, or whatever they wanted to call it.
A good example for this, I think, in the real world of how you separatebrand and product is the Marriott Hotel chain.Marriott have the Residence Inn and they've got thebusiness brand hotel and they've got the airport hotel.They're all different brands that allsit 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 otherone is, is synonymous with work.
Honestly, I think startups who obsess over their brand beyondthe basics like get your logo right, get your slogan right,get your marketing right, always make sure youpresent 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 outit doesn't actually gel that well with the product.
I think in general I'd focus more onestablishing a brand around a specific job.
When you want to drill a hole inthe wall you think Black & Decker.When you move into a new empty apartmenthere in San Francisco you think IKEA.If you keep it restricted in that regard you'llalways 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 inthe market and you want to charge some moneybut you don't know how much is the right point â€” if you literally don't know how to charge, butyou know you want to charge, I think it'stotally 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 isit will actually tell you a lot about your actualcustomers versus the people who think they're goingto be your customers but actually don't pay money forsoftware because they don't believe that's right.
The first thing is pick a price.Once you pick a price, make it clear that thisis your beta price, this is the price you'regoing 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 ornot to keep the free plan if you wish.It's kind of your call at that point.
From that point onwards, I would start studyingusage and try and differentiate what a big customerlooks 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 ofemails or uses up a lot of gigabytes on a server.Once you cut out all the free usage, you'llstart 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 basicaxiom 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 numberof hosted websites, that will work too.
I think the first thing is cut outthe 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 whereyou think your smallest price plan will be.Then plan a refresh over six to twelve months totry 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 productshould embody if it is really a brand value.It can definitely work.The tricky part is picking a brand value thatwon'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 somethingto the table for you, but it will come atthe cost of costing you other customers.
It turns out there are companies serious enough such that amonkey on their desktop is not how they want to send email.Those guys use Eloqua or ExactTargetor Campaign Monitor, something else.However, for MailChimp's sweet spot it's the perfect brandbecause they're literally reaching out to every creativefreelancer, every small to medium, certainly a lot oflarge 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 withinthe founders itself because you can't half doit, or dip your toe, or hire a designer to build it.
MailChimp have two full-time guyswhose 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 goingto 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 saywork 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 andstill be practical in the short term. The vision for me, as I said, it's specifically not about beingnumber one or anything like that, but it is being aware ofchanges that are happening, fundamental changes if you like.
An example would be if you're building a product today thatassumes 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 signspoint 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 watchout for in your vision, but yeah you should be practical today.
One thing to bear in mind is peopleconfuse this idea with MVP.Your customer doesn't give a shit about what an MVP is orhow 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 like30 users or 50 this, or whatever, as some sort ofpseudo-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 jobsomeone's trying to do and build against that.The reason I talk about strategy and thinking longer termis more to make sure that there's no fundamental shiftaffecting the job. Like don't be starting a newspaper in2014 and assuming people read on a subway.
The mission is honestly a personal thing.I really don't believe people should workon things they're not passionate about,because you're going to be in it up your fuckingneck for the majority of the best years of your life.
This is the scary bit, this is whatthey don't tell you when you're enrolling.But that is true.When I talk about the mission it has to really matter toyou to do what it is that your company is aiming to do.Just because you can write a Rails app that can sendinvoices pretty quickly, if you're not reallypassionate about enabling small businesses to getpaid quicker, you're not going to bethe right guy to do it because you're going torun 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 smallestcomplete 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 featureto your product is it's either a defensive move,i.e. "We are definitely losing customers because we don'thave 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 thinkyou know something that most of the world doesn't,or unless you've got something coming out that solvesthe 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 wewant 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 exploreand see if we can capture behavior with it."That's absolutely fine.That makes perfect sense for as long asyou're looking to expand your product.
When you're pre-product market fit that'sthe sort of things you should be doing.It will click at some point and people will start signingup heavily and using all corners of your product.The danger for me is when let's say you're a photo management tool andyou're ignoring that your photo uploader is shit,but you're busy chasing filters because Instagram has them.
Remember that chart we had whichis like all of the people, all of the time, if there was improvement to be had upthere 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 asthe 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 editorthat would actually send us back the test resultsbefore 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 youruserbase, and if you can't realize that capturing in termsof 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 productthat no one is complaining frequently about commonfeatures in then yes, it's time to go and look fornew 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 thisnew sexy shit because Backbone got releasedand it looks really cool for doing whatever.
I guess my answer is yes, definitely go and releaseexploratory features, but the chances are you're probablynot 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 featuresthat are only available on your higher priceplans you will find naturally, of course,that not all of your userbase can adopt them.In those cases, what you should be doingis that feature matrix per price plan.
You want to look at of all the people who can use thesesuper powerful features that are in the top left.Once you say of all the people who can use them, are theystill 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 alwaysuseful to not take your userbase as anaverage 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 ourcustomers 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 doit 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 orby 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 yourreally 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.