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