{"id":22447,"date":"2019-12-10T16:30:59","date_gmt":"2019-12-10T16:30:59","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=22447"},"modified":"2020-09-17T11:10:36","modified_gmt":"2020-09-17T10:10:36","slug":"outcomes-vs-features","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/","title":{"rendered":"Ship outcomes, not just features, with the Product Impact Framework"},"content":{"rendered":"

Our industry is in the midst of a big philosophical debate about the fundamental way of thinking about how we build our products, with the focus shifting from the outputs of what we build to the business outcomes generated by those outputs.<\/p>\n

We\u2019ve been thinking deeply about how to make this change in our own organization, with Des and Paul leading our discussions<\/a> about it. More broadly, industry thinkers such as John Cutler<\/a> and Josh Seiden<\/a> are writing extensively about how organizations can effect such change in their mindset.<\/p>\n

In some ways, this discussion is more relevant to product teams, and product-led companies, than for growth teams, who are by definition focused on outcomes. But the fact that it\u2019s a discussion at all highlights how little we actually know about the relationship between outputs and outcomes, how the causal relationship between product and profit, so to speak, can be so ambiguous.<\/p>\n

To fully understand what such a change in thinking requires, we\u2019ve realized that it\u2019s important to understand what we call the “product impact framework” \u2013 the steps of cause and effect that culminate in positive outcomes for the business.<\/p>\n

<\/p>\n

Essentially, any project you work on results in the shipping of a change to the product (usually but not necessarily a feature). This feature, if it solves a customer problem, results in measurable changes in how customers behave in your product, and ultimately this behavior change delivers an impact to your business.<\/p>\n

But knowing how these steps work is not the same as making it happen, and we think we know why.<\/p>\n

Context: where we\u2019ve come from in trying to move to outcomes<\/h2>\n

First some context. We\u2019ve anchored a major part of our R&D culture around the speed of shipping. Back in 2013, our head of engineering Darragh coined this mantra: Shipping is our heartbeat<\/a>.<\/p>\n

“When you\u2019re in the startup phase of a company, speed of shipping, and shipping uncomfortably early so you can learn what actually works, is essential for success”<\/p><\/blockquote>\n

Later that same year, our head of product Paul wrote a blog post<\/a> about shipping just being the start of a process, which we eventually refined into a core R&D principle<\/a> of \u201cShip to Learn.\u201d<\/p>\n

When you\u2019re in the startup phase of a company, speed of shipping, and shipping uncomfortably early so you can learn what actually works, is essential for success.<\/p>\n

It also allowed for us to begin with features, and then quickly see which ones had an impact and which ones didn\u2019t. That speed of iteration came naturally to us, and was very fruitful. The Product Impact Framework felt like a natural progression from features to outcome.<\/p>\n

But we didn\u2019t necessarily have full control of those outcomes, nor were we entirely able to predict them. As we scaled, that had to change.<\/p>\n

Getting our teams to think more commercially<\/h2>\n

In 2018, our co-founder Des adopted a new internal mantra: \u201cIt\u2019s all about market impact.\u201d<\/p>\n

“The gap from shipping an improvement to measuring its impact on your key business metrics is, for most product teams, as wide as an ocean”<\/p><\/blockquote>\n

We needed our R&D teams thinking much more commercially. It wasn\u2019t enough to efficiently solve customer problems; we needed to be thinking about how we were helping our business to be more successful.<\/p>\n

The core problem here is the gap from shipping an improvement to measuring its impact on your key business metrics is, for most product teams, as wide as an ocean. The relationship between steps in the Product Impact Framework might seem clear in theory, but they can be hard to decipher in practice.<\/p>\n

The Product Impact Framework at work<\/h2>\n

This conundrum is clear if we examine a recent example, and how it maps to the Product Impact Framework. Earlier this summer we released Inbox apps<\/a>, which allows Intercom customers to customize their Intercom Inbox by arranging their tools and the information they see about their customers.<\/p>\n

<\/p>\n

Here\u2019s how this feature fits into the framework:<\/p>\n

<\/p>\n

Simple enough, right? Perhaps so, but the relationship between those final two steps, from reduction in average reply time to higher support retention, is not trivial to demonstrate. How confidently can we predict the increase in retention, for instance?<\/p>\n

As we move to a world that is focused on outcomes, it can be very tempting to look at the framework and reverse it \u2013 that is, instead of beginning with features, as we traditionally did in our fast-shipping, fast-iterating world, we simply begin with the outcomes we want to see, and work backwards.<\/p>\n

<\/p>\n

The beauty in this framework is that it actually supports two fundamentally different approaches to building product: feature-driven projects and outcome-driven projects. But only after much effort and experimentation did we realize how fundamentally different the two approaches are \u2013 as we discovered, one is not simply the reverse of the other.<\/p>\n

Feature-driven projects<\/h2>\n

Feature-driven projects are the most common approach to building product. The features could come from from feature requests from your existing customers, or product gaps that your sales team are encountering as they try to close deals. Or the feature could be a new idea or big bet your team is really excited about.<\/p>\n

Whatever the source of the feature, the key point is one we\u2019ve banged on about numerous times in the past \u2013 it\u2019s absolutely critical to understand the actual customer problem to be solved. That\u2019s the first step working your way down the framework:<\/p>\n

<\/p>\n

Paul has written about how important it is to put far more time into problem definition<\/a>, and it\u2019s our first R&D principle<\/a>:<\/p>\n

<\/p>\n

Getting a team to rally behind a problem is incredibly empowering, because it unblocks much more creative approaches to a solution, and makes it much more likely those solutions will actually work.<\/p>\n

For us, the real challenge comes trying to move further down the framework, towards the outcome end of it.<\/p>\n

This is usually the case for feature-driven projects: it\u2019s easy to see if you\u2019re solving a problem through the directly related customer behavior, but very hard or even impossible to tie this to higher-level customer behaviors and business results. To cite the Inbox apps example again, we could see the effect of the new feature by looking at usage and adoption rates over time, but identifying the impact of this specific change on response times and thus retention was much harder.<\/p>\n

“By using measurable customer behaviors as a proxy for business results, you create a much faster feedback loop for your R&D teams”<\/p><\/blockquote>\n

Higher-level customer behavior metrics, such as average response time, and business results, such as retention, have many variables impacting on them. As a result, it\u2019s much more difficult to prove that a change in one of those variables resulted in changes to the business metric without a very lengthy A\/B test. In addition, business metrics tend to be lagging indicators, which means that the feedback loop from testing to learning is often too slow to be of practical use to a team.<\/p>\n

To get around this issue, you need to use what former Netflix head of product Gibson Biddle calls proxy metrics<\/a>, which are stand-in measures for your actual business metrics. By using measurable customer behaviors as a proxy for business results, you create a much faster feedback loop for your R&D teams.<\/p>\n

But still, the team really has no idea or even reasonable estimate of how Inbox apps impacted our business results. This project, like many feature-driven projects, is stuck further up the framework stack.<\/p>\n

The lesson is that it’s really hard to get a feature-driven project to extend all the way down the stack. Identifying proxy metrics helps to accelerate progress.<\/p>\n

Outcome-driven projects<\/h2>\n

The alternative approach is to start with a desired outcome. Indeed, this is a common situation for teams that are focused on growth, but as a traditionally product-led company, this approach wasn\u2019t the most natural fit for us.<\/p>\n

For instance, last year we asked a team to \u201cimprove Inbox seat expansion.\u201d Seats are one of the primary ways we charge our customers, so really this was the same thing as saying \u201cexpand our Inbox revenue for existing customers\u201d.<\/p>\n

“The starting point was so alien that the team basically had no idea how to even think about the project”<\/p><\/blockquote>\n

It sounds obvious, but no team had ever looked at this before, and since a large percentage of our revenue came from this source, it seemed like a big opportunity. And it was totally wide open \u2013 there were zero beliefs about how to do this, it was completely up to the team. So it seemed like an ideal project to learn how to become outcome-focused.<\/p>\n

But it was a flop. The project went nowhere \u2013 it didn\u2019t even get off the ground. The starting point was so alien that the team basically had no idea how to even think about the project. \ud83e\udd37\u200d\u2640\ufe0f<\/p>\n

And it took us a while to understand why. The problem was we had unintentionally tried to skip a step in the framework:<\/p>\n

<\/p>\n

We hadn\u2019t done the hard work to figure out what customer behavior actually mapped to Inbox seat expansion, or identified problems that were preventing customers taking these actions. And this project was for a team that was used to being grounded in customer problems, so this starting point basically put them in limbo.<\/p>\n

That measurable customer behavior is the same thing as proxy metrics, which are stand-in measures for your actual business metrics.<\/p>\n

Without clearly understanding what\u2019s preventing users from taking the actions you want them to take, a team ends up hypothesizing about what the problem could be and designing features to solve this hypothesized problem. This is a common process for teams new to working on outcome-based projects, and the risk is that without first validating the hypothesized problem, you\u2019re essentially gambling with your product development.<\/p>\n

Here\u2019s a real example of this that our Onboarding team recently worked through. They were focused on improving a key business metric: 12-month net revenue retention. They had to do some heavy analysis to keep mapping this up to a measurable customer behavior, and the result was kind of like a daisy-chain of links:<\/p>\n

<\/p>\n

Now the key here is you need strong evidence that the designated customer behavior actually maps to business results. I mean, just imagine asking a team to get customers to log in twice in their first week. Who\u2019s going to believe that this is the secret key to long-term retention? But once you\u2019ve established a strong link with proper analytics, then your team can focus solely on that metric without worrying about whether they\u2019re wasting their time.<\/p>\n

So here\u2019s one hidden secret about moving to outcomes: finding your proxy metrics can be really hard<\/strong>. As Gibson says: \u201cIsolating the right proxy metric sometimes took six months. It took time to capture the data, to discover if we could move the metric, and to see if there was causation between the proxy and retention. Given a trade-off of speed, and finding the right metric, we focused on the latter. It\u2019s costly to have a team focused on the wrong metric.\u201d<\/p>\n

Even worse, that metric is often useful for only one team. So you have to repeat that process again for different areas of your product.<\/p>\n

Okay, so now we have our proxy metric \u2013 getting brand new customers to log in twice in their first week. We\u2019re still not ready to dive into design and build. We have to resist the temptation to skip a step:<\/p>\n

<\/p>\n

You need to do research to understand what problems prevent customers from doing what you hope they do. For outcome-driven projects, it\u2019s actually a huge temptation to skip this step and jump straight to hypotheses. Don\u2019t do it \u2013 you\u2019ve got to talk to customers.<\/p>\n

Only once you\u2019re clear on the customer problems can you go into experimentation mode \u2013 generating hypotheses and doing fast experiments to see if they impact customer behavior.<\/p>\n

So the key takeaway here is in order to actually run genuinely outcome-driven projects you need to do the deceptively hard work of finding valid proxy metrics that your team can actually change, and only then can you work your way up the framework.<\/p>\n

Acknowledge your project\u2019s center of gravity<\/h2>\n

A way to think about this is a project\u2019s center of gravity. For feature-driven projects, it\u2019s at the top of the stack; for outcome-driven projects, it\u2019s at the bottom.<\/p>\n

<\/p>\n

For outcome-driven projects, you will be clear about the results that you want, but it always requires an uncertain leap of faith that you’ve identified the right problem to solve in order to drive that result. For feature-driven projects the issue is reversed: you can be confident that you’ve identified a real problem, but it’s harder to determine whether this problem is significant enough to drive the behaviors that impact business results.<\/p>\n

“We could have put in a lot more analytics effort to try to correlate successful searches with business results, but there are a lot of daisy chain steps along that path”<\/p><\/blockquote>\n

Let\u2019s take another simple example to illustrate this point. A separate Inbox feature we released this summer was improvements to search<\/a>. This was an archetypal feature-driven project: the frequency of customers both using search and reporting frustrations made us confident that this was a problem worth solving, and we were confident we knew what improvements to make. So we did.<\/p>\n

We could have put in a lot more analytics effort to try to correlate successful searches with business results, but there are a lot of daisy chain steps along that path. Instead we followed our usual path, beta tested it, iterated based on quantitative and qualitative results, and shipped it. We\u2019re confident we\u2019ll see dramatically fewer requests to fix Inbox search, but we have to acknowledge that we have no idea what business impact this project will have.<\/p>\n

And for a project like this, that\u2019s okay.<\/p>\n

There\u2019s another route that might have pointed us to improve Inbox search. Suppose we found that Inbox efficiency reliably mapped to customer retention. And through research we might have found that search was one of the hurdles for some customers. We would have tried a fast experiment to see if search improvements actually made teammates measurably more efficient. We might have subjectively thought search was better, but if it didn\u2019t speed up teammates\u2019 work then it wasn\u2019t worth pursuing, so we\u2019d opt for some other focus area. That\u2019s the outcome-based approach.<\/p>\n

Feature-driven vs outcome-driven projects<\/h2>\n

So where does all this leave us? There are some useful rules of thumb when it comes to thinking about the two different approaches, some broad characteristics that mark out the distinctions between them.<\/p>\n

<\/p>\n

Bear in mind these are just generalizations, and you can find plenty of exceptions to each of these. But it\u2019s also important to realize these two approaches can and should co-exist.<\/p>\n

When we started to try to evolve R&D to become truly outcome-focused, we thought we had to change the way we worked for every project \u2013 that every project had to become outcome driven.<\/p>\n

“We are trying to get a better balance of projects, so we\u2019re spending a lot of time and energy figuring out the right proxy metrics”<\/p><\/blockquote>\n

But what we\u2019ve learned is that it\u2019s far harder to do this than we anticipated. Equally, we\u2019ve learned that our feature-driven approach is still valid, particularly when anchored on customer problems.<\/p>\n

Ultimately, we are trying to get a better balance of projects, so we\u2019re spending a lot of time and energy figuring out the right proxy metrics, which is crucial for really understanding the relationship between the different steps in the framework.<\/p>\n

Both ways of working are important. Both ways fit inside the same framework. But don\u2019t think you can casually jump from one to the other. Respect the center of gravity of each project type, and be sure to adapt how you approach each type of project to its inherent risks.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

How can you determine whether the features you release are leading to positive outcomes for your business? We use the Product Impact Framework to clarify how one leads to the other. <\/p>\n","protected":false},"author":128,"featured_media":22601,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"category":[5],"tags":[20198,269],"coauthors":[432,12705],"class_list":["post-22447","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-and-design","tag-outcomes","tag-product-features"],"yoast_head":"\nShip outcomes, not just features, with the Product Impact Framework - The Intercom Blog<\/title>\n<meta name=\"description\" content=\"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other\" \/>\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\/outcomes-vs-features\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Ship outcomes, not just features, with the Product Impact Framework\" \/>\n<meta property=\"og:description\" content=\"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/\" \/>\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:published_time\" content=\"2019-12-10T16:30:59+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-09-17T10:10:36+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"2560\" \/>\n\t<meta property=\"og:image:height\" content=\"1212\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Brian Donohue, Robbie Allan\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@brian_donohue\" \/>\n<meta name=\"twitter:site\" content=\"@intercom\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Brian Donohue, Robbie Allan\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/\"},\"author\":{\"name\":\"Brian Donohue\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/person\\\/e5c80d2b7f38ee19419b225376b0ad74\"},\"headline\":\"Ship outcomes, not just features, with the Product Impact Framework\",\"datePublished\":\"2019-12-10T16:30:59+00:00\",\"dateModified\":\"2020-09-17T10:10:36+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/\"},\"wordCount\":2733,\"publisher\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/12\\\/hero2-1-scaled.jpg\",\"keywords\":[\"outcomes\",\"product features\"],\"articleSection\":[\"Product & Design\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/\",\"name\":\"Ship outcomes, not just features, with the Product Impact Framework - The Intercom Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/12\\\/hero2-1-scaled.jpg\",\"datePublished\":\"2019-12-10T16:30:59+00:00\",\"dateModified\":\"2020-09-17T10:10:36+00:00\",\"description\":\"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/outcomes-vs-features\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/12\\\/hero2-1-scaled.jpg\",\"contentUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/12\\\/hero2-1-scaled.jpg\",\"width\":2560,\"height\":1212},{\"@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\\\/e5c80d2b7f38ee19419b225376b0ad74\",\"name\":\"Brian Donohue\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pgc1588f5f029173cd7fcbd9962f2a9aca\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pg\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pg\",\"caption\":\"Brian Donohue\"},\"description\":\"Brian is a VP of Product at Intercom. He's well-versed in leading teams in the product and design world \u2013 previously, he was a Director of Design at Houghton Mifflin Harcourt and Director of Consulting at Each&Other.\",\"sameAs\":[\"http:\\\/\\\/www.intercom.io\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/brian-donohue-2450192\\\/\",\"https:\\\/\\\/x.com\\\/brian_donohue\"],\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/author\\\/brian_donohue\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Ship outcomes, not just features, with the Product Impact Framework - The Intercom Blog","description":"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other","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\/outcomes-vs-features\/","og_locale":"en_US","og_type":"article","og_title":"Ship outcomes, not just features, with the Product Impact Framework","og_description":"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other","og_url":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/","og_site_name":"The Intercom Blog","article_publisher":"https:\/\/www.facebook.com\/intercominc","article_published_time":"2019-12-10T16:30:59+00:00","article_modified_time":"2020-09-17T10:10:36+00:00","og_image":[{"width":2560,"height":1212,"url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","type":"image\/jpeg"}],"author":"Brian Donohue, Robbie Allan","twitter_card":"summary_large_image","twitter_creator":"@brian_donohue","twitter_site":"@intercom","twitter_misc":{"Written by":"Brian Donohue, Robbie Allan","Est. reading time":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/#article","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/"},"author":{"name":"Brian Donohue","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/person\/e5c80d2b7f38ee19419b225376b0ad74"},"headline":"Ship outcomes, not just features, with the Product Impact Framework","datePublished":"2019-12-10T16:30:59+00:00","dateModified":"2020-09-17T10:10:36+00:00","mainEntityOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/"},"wordCount":2733,"publisher":{"@id":"https:\/\/www.intercom.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","keywords":["outcomes","product features"],"articleSection":["Product & Design"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/","url":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/","name":"Ship outcomes, not just features, with the Product Impact Framework - The Intercom Blog","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/#primaryimage"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","datePublished":"2019-12-10T16:30:59+00:00","dateModified":"2020-09-17T10:10:36+00:00","description":"How do you know if the features you release are leading to positive business outcomes? We use the Product Impact Framework to see how one leads to the other","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.intercom.com\/blog\/outcomes-vs-features\/#primaryimage","url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","contentUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","width":2560,"height":1212},{"@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\/e5c80d2b7f38ee19419b225376b0ad74","name":"Brian Donohue","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pgc1588f5f029173cd7fcbd9962f2a9aca","url":"https:\/\/secure.gravatar.com\/avatar\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pg","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/e934595dabf8323f38bd151d4ab898afa497041d72ea6940e4d4d4a053a03450?s=96&d=mm&r=pg","caption":"Brian Donohue"},"description":"Brian is a VP of Product at Intercom. He's well-versed in leading teams in the product and design world \u2013 previously, he was a Director of Design at Houghton Mifflin Harcourt and Director of Consulting at Each&Other.","sameAs":["http:\/\/www.intercom.io","https:\/\/www.linkedin.com\/in\/brian-donohue-2450192\/","https:\/\/x.com\/brian_donohue"],"url":"https:\/\/www.intercom.com\/blog\/author\/brian_donohue\/"}]}},"jetpack_featured_media_url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/12\/hero2-1-scaled.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/22447","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\/128"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/comments?post=22447"}],"version-history":[{"count":0,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/22447\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media\/22601"}],"wp:attachment":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media?parent=22447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/category?post=22447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/tags?post=22447"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/coauthors?post=22447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}