Hi and welcome to Intercom on Product, which is a new podcast series with myself, Dez Trainer, co-founder of Intercom. I'm Paul Adams, who's our Senior Vice President of Product.
Over the time we've worked together, Paul and I have had countless conversations about things like head-or-runer product work at scale, head-or-balance customer feedback on your product roadmap, head-or-spread a product first mentality throughout a company, head-or-maintain design excellence in a fast-growing ORAD team, and so much more.
In this series we're going to begin sharing some of these discussions where you want to write your bases covering everything from industry trends, what's hot right now, all the way through to things like how are we embracing the rise of automation. So if you're a designer, product manager, engineer, researcher, or anything in between,
we can go find these conversations really valuable. You can subscribe to Intercom on product, on iTunes, in stream and on Spotify, or even just grab the RSS feed in your player of choice. Thanks for listening. Welcome to Intercom on product. This is our sixth episode, and once again I'm joined by Mr. Paul Adam's Hey, Paul. Yep, that is.
Today we're going to talk about outcomes over outputs. The product management world has recently been torn a sunder over its latest topic, and for once it's not the brand of post-its or sharpies, it's not persona's versus jobs to be done, it's not even things like what should be a roadmap and what shouldn't be. It's about this idea that there's a core difference between the output of a product team and the business outcome generated. Paul, you spoke about
this topic recently at a conference. Could you talk to our listeners about what's going on here, what's the general narrative in the industry, and we'll take from there? Yeah, sure. Yeah, so I guess before we get into the debate of which one of these things is more important, the way that I describe these things is that the output, people talk about outcomes, being more important than output. There's a lot of energy, like you said, in the industry.
So for example, Josh Siden is written a great book called Outcomes Over Output. The theme of Marty Kagan's most recent version of Inspired is kind of classic product management book, which is also a great read, is Outcomes Over Output. And output, in my opinion, is shipping, shipping product, shipping things at the door, and Outcomes is the impact of that. We can get into the specifics of what does impact mean, is it a business result, or whatever. That's kind of
the distinction between the two. So it's like what you shipped first is what happened because of the tiniest shipped. Yeah, exactly. There's a turn you got on it. Yeah. And there's been so much energy over the years, and you can kind of blame or credit, whoever you want, lean startup, lean UX, all these movements, all about shipping, and startups die unless they ship.
The startups that ship more often, more frequently faster are the ones who learn faster, they're the ones who then iterate, and it's fair to say we believe all that, because we're riddled with those sort of messages, like shipping as a hard drive, et cetera. Yeah, absolutely. One of our three principles is ship to learn. Not only does think big start small, start small,
start small, you'll do sooner. So we absolutely do believe in those things. Yeah. But the kind of correction, or like the movement around trying to correct this is that there's so much emphasis on output that people have stopped thinking or thinking enough about the impact of that output. Yeah. That's a gist of it. Yeah. So if this is kind of a almost like a pendulum, sitting back towards an idea of, hey, it's not about putting code live on a server,
so that people can execute it, it's actually about generating a business return. What hell's wrong with that? That sounds perfectly correct. Yeah. Well, the kind of argument that I was making, or the case I was making in the talk that I gave, and I only gave it a couple of days ago, it says quite recent, recent thinking, and I think all listeners will realize that our thinking is evolving on this topic too. Outcomes are certainly something that we are just going to
sing a lot internally to come these days, and more so than we've done in the past. The case I was making in the talk was that it's less about outcomes over output. And you know, like you said, when I read Josh's book, I was like, this all makes sense to me, you know, equally like I read our principles about shipping and our obsession with shipping, and you know, Dara who runs the engineering team has a blog post about shipping as her heartbeat, shipping as a company's heartbeat,
and I believe all that too. And so the case I was making simply at the conference was, hey, it's not about outcomes, it's about the system, it's about outcomes and outputs and their relationship, but a third thing which is inputs. So the full system that I think every single software team has, no matter who you are, how you work, whether you're a waterfall or agile, whatever, you have inputs, why you what projects do you do, or what are they, the inputs or like
the inputs tell you what projects, right? So the inputs could be, you know, a vision or a feature request or customer complaint or whatever. So you've all these inputs, and then those inputs, you know, determine what projects you do, and inputs to what inputs to the product team.
Yeah, inputs to the product engineering team. So I actually had a diagram which is kind of hard to describe obviously on the podcast, but the diagram basically, the first thing going through on the diagram was you have a product engineering team at the top, and then they do projects, which is the next level down. The projects change the product, that's a whole point of doing a project in the software team, the product should change, and then that change in the product should
result in a change in customer behavior. Hey, we added a feature, we expect customers to use it, or we changed how this feature works, we therefore expect customers and users to change how they
use it. Yeah. So it was projects that change the product, the change behavior. A separate thing I talked about was, I didn't get into much in the talk was monetization of that, which is a whole other thing like, but you would assume if you're running a good business, the changes you make and the product and those consequent changes in user behavior, result in rather, yeah,
either more customers or less churn or more people buying more or whatever. Exactly, I had like, I had like existing users broadening or deepening their usage, or new customers signing up, you know, buying something for the first time, etc. So you're arguing it sounds like that, like inputs, outputs and outcomes are all like very important. Yeah, I said they're equally important. Yeah, I said it's the system that matters, equally important, and we shouldn't be debating one
is more important than the other. Yeah. We should be saying they're all important, and that's to understand the relationship between them and how to get good at all three. Yeah. And so the inputs, I got to say, there's the projects that you do inputs get into the specifics of each one. The inputs, you know, it's basically a roadmap, I think the most concrete artifact of taking those
inputs. Yeah, inputs get digested down into a roadmap, right? Yeah. So if we start, like maybe we'll just talk with inputs for a little bit, Jeff Bezos has that famous quote, like if you can, you know, the technique you can control most that makes your business most successful is actually your inputs. I mean, like what is it you actually follow? Yeah. So what would example inputs be for a product team? Obviously, there's a process by which they spit at a roadmap and the kind of
statement of what we actually want to do. Yeah. What do we listen to, for example? Yeah. What are the inputs? Yeah, it's interesting to kind of look at the history of Intercom over the last few years because we've obsessed about this, obsessed with inputs. And if outcomes do us as a more recent conversation, inputs isn't it's a longstanding obsession. And so we now have a pretty advanced system of sub-system within the kind of broader system of inputs outputs and outcomes.
We have a little system around inputs. So what we do, and again, this is not for everyone, different companies, we live different things. Our inputs are, we, you know, typically we have like five, one is our vision, our mission of the company, our vision for the future. Another one then is around our business goals. Another one is around prospective customers feedback. So your sales team talk to customers like all the time every day of the week, they're learning a lot
of things about Intercom. There are things we can build and change in the product that would help those customers sign up for Intercom. So prospective customers existing customers is a fourth. Exactly. As the prospective customers, if they're talking to the sales team,
our existing customers are typically talking to our support team. Yeah. Now we have a little process in both of those orgs and both of those functions, the sales team and the support team, where we've a collaboration with the product team to get all the feedback and aggregate it and come up with like a somewhat scientific way of organizing it and prioritizing it.
The fifth one is actually business strategy, which I should have said second. So vision and mission, then the business strategy, which is, you know, maybe a year or multi-year, to execute that vision. Next down is your business goals. Hey, do we have like revenue targets this quarter, we do engagement targets this quarter, things like that, and then prospective customers feedback,
existing customers feedback. Right. So they're all inputting. You know, they're all inputting. And and then we work out ways to balance them, you know, is like this next roadmap more about prospective customers or existing. Is it more about this business goal versus that? Do we feel like we're a little bit behind on our mission and vision? One investment more that in that this time. So they're all the inputs. And when you think about the quality of an input,
what what are you looking for? Like, is it it should be like in variant, it should be generic, it should represent all users. Like, what are the sort of things you think about? Like, or if I transplanted you into a different company, how would you go about checking if the inputs are any good? The first thing I do if I'm transposited into new companies, understand their system. Yeah. But the way that I think about inputs, so the artifact might be roadmaps, but the way that I think
about them is that they're customer problems. Ultimately. So, you know, one thing I'd look for straight away is when you look at, so that's one thing is like the qualities and puts are they good inputs. And then a second thing is how are they communicated? As a customer problem. Yeah. Like, IE, there's value to be had there for customers and for the company versus a business problem.
I can give you an example of where we got that wrong in a second. On the inputs themselves, the things I'd look for are the process around which some of these things are generated. Right. Here's a really simple example. After I spoke, give that talk afterwards. I'll be able to come up to ask you a couple of questions. One of those common questions I got was, hey, how do you persuade your sales to your, how does it work? And I was like, what are sales team
I don't call? They're chatting to a prospective customer or an existing customer, but a new product we've launched, a new feature. And they record all that in Salesforce. And then we pull all that data. I had a Salesforce into our own system and run analysis on and aggregate it and cut it by different dimensions. And they were like, wow, how do you get their sales team to input into, do all the nine to work? Like, our sales team are just closing deals. That's all they think about. They don't
think about their product. And I kind of said, the answer is twofold. One, your sales team we hire are very producty. Like we actually hire people with a passion for product. And it's kind of one of the values in the sales team is to be passionate about our product. That's one thing. So they're motivated to do it because there's an interest there. The second reason way more important is that
we ship a lot, which is getting into the outputs actually. But we ship so much. And so the sales team can actually see in a very short space of time, the direct line between the manual data entry into Salesforce and the thing that their prospective customer is looking for. Yeah. The feedback loop to sales has to be strong to maintain that. Like they have to believe that if I make enough noise about this gap, I will get that gap closed and I'll close that deal and I'll make more money.
Yeah. And that's why I think one of the imperatives for anyone who's trying to adopt some sort of feedback loop with sales has to be like, you have to share back what you what you're doing on why and why their input mattered. Otherwise, you feel like if you're on sales side, you feel like you're sharing into a vacuum. Yeah, exactly. And to kind of answer your original question, like that just put rubbish into Salesforce. Yeah, I tell you. And or not bother. Yeah. And yeah, you're
wonderful. Good view. Put the other piece I find them. Something I look for is like, I don't like inputs that are like super dynamic. If you know what I mean, like they change quarter to quarter, we, you know, it can't be like, hey, the number one feature we need is a, you know, Zora integration. Next month, it's a Microsoft dynamics integration. Next month, it's like tagging. You're like, well, hang on, like, you know, Ardiz, like, like, generally speaking customer needs,
Chent and I change that often. So I feel like there's a massive free-sense bias whenever I see these things change. Like, it's good to look at like both the rate of change within the top 10 or whatever, but also like the, that's one thing that just helps you suddenly check the input. Also like the recidivism, like so if we get something off the list and it comes back again, that means we're not properly understanding the features. Like, hey, you asked for permissions.
Appuires permissions back again for the third quarter, even though we've said all three times, we got it done. Well, it's clear that we're like, we're doing an MVP on this, just like that. And we're not getting away with it, you know. Yeah, yeah, we sculpted too small. Yeah, yeah, yeah, yeah. Yeah. All right. So that's inputs, outputs. How do you think about outputs? Is it like, how much features are launched to the public? Yeah, I think that I think at the highest level,
it's it's shipped product changes. So go back to that thing of like, you know, the prognonduring team do these projects, they're like customer problems based on these great inputs, you'd hope. And then that changes the product. And sometimes these things are in the background, obviously, security improvements, whatever. So I was visible, but they're changes to the product. Yeah. And so it is things you ship. And of course, and any any of these dimensions,
you can they can be good or bad. You can have bad inputs or good inputs. You can have a bad output. Good. Yeah. And that's just a function of the team, right? Or like the prescoping or priority or the design or whatever, but like, like it was a bad output. You don't get to blame. It can't be we were asked to do the wrong thing and we did the wrong. It's someone else's for bullshit. So we've made it did some bullshit, right? Or it can be like our team really funded in.
And we produced half of the thing we said we'd do right. Yeah. Exactly. Exactly. So all three of these are like levers. Yeah. And what outputs, I outputs to me is actually very simple. I think inputs is, you know, if one of these three is more important than the other, I think that argue inputs is because you know, I had a slide in the conference of AC said like shit and equals shit. Yeah. Totally. Yeah. It's like inputs, you know, starts to start to end with the inputs in a way.
What outputs and it's pretty simple, which is the obsession with shipping that we've had over the past years is a good thing. And like we said earlier, we do obsess about it and we continue to obsess about it. And one of the conversations we come back to a lot it's recurring is in intercom is as we grow and scale and get more product teams and more engineers and our co-base gets more complicated or bigger, can we still ship as fast as we used to? And we have been doing. And that's
testament, I think, to our obsession with shipping. Having said that within that, you then have like, you know, the variables below that like scoping. Hey, do we scope the problem down to just the right amount? So we do solve the problem. What I do in extra work, speed, you know, how fast for we have we compromised the quality, right? So that kind of classic like speed versus quality thing. But at the end of the day, I think it's pretty simple. Yes. Shipped product changes.
Join us in London on October 10th for an AI customer service summit where we'll be hosting visionary customer service leaders to explore the impact and opportunity of AI and announcing our next generation AI innovation, connect, learn and inspire the future of the industry in an AI first world register for the live stream at enter.com forward slash pioneer podcast. That's enter.com
forward slash pioneer podcast. Inputs and outputs are pretty clean outcomes like one thing that occurs to me is like I often grimace when I see any any team outside of enter.com I hear it more like kind of celebrate an outcome that they can't actually articulate why it happened. Right. So like, you know, we hear this example, you know, a large customer could sign up for enter.com tomorrow, very large customer say seven figure deal, right? And they could buy one of
our products. Let's say a product that might have had like a certain million dollar gold for the quarter. And does result that product team can blow treat or target or like the outcome from that team would look phenomenal for that quarter. Yeah, but ultimately they had nothing to do with that like, you know, obviously they built the product, but I mean in this period of analysis, the outcome happened. The business outcome arrived independent of what we were doing in that
exact quarter, right? And the reason I care about those things is because I think you're at your best when you're celebrating repeatable victories. Yeah. I mean like teams where you're like, hey, I know exactly why we laid this out. The strategy worked and we got we got exactly what we planned to get. And that's awesome. Yeah. But there are loads of things to produce at times, right? Yeah. Is it we could ever read a successful marketing campaign and see sign ups across the board.
Doesn't mean our friends product got better, right? Right. Right. Right. And so talk to me about how do you chase the sort of the path from an output? Yeah. You think we launched to the outcome. Without getting blinded by other like rising tides that might have helped us along the way. Yeah. Yeah. I think it's really important to teasing apart, like cause and effect.
Yes. What caused what? Yeah. Before we get into that actually, what was you were speaking there at Jaguar Memory on something you said to me last week about feature factories? Yeah. Because you were saying there, but like how do we have a like repeatable consistent high quality output? Yeah. And you remember you saying to me like factories are a brilliant way to have consistent high quality. Yeah. And the feature factory thing was given
given it a hard time. So I hate this phrase. This is one of these things where like if there wasn't a liberation in this, no one will be talking about it. But never ever. It's a bit like a feature factory. I've heard it from even PMs in the income law. This is going to turn into a bit of a feature factory. Yeah. And I don't know why that's necessarily a bad thing. Like you realize money is made in a mint where they have a repeatable process for making money, right? You know,
same with cars. You know, like you know, like same with iPhones. We're all occurring around iPhone X Pros or whatever. They came out of a factory that needed to produce a lot of them. I think the implication of feature factory is we're spitting out random shit left right and center. And
does nothing really cohesive to holds it all together. Or it might be like biting your dip on the fact that like, Hey, we made five decisions of once and we have to get all five live and now we just need to go into factory mode versus shipping one, seeing what happens, shipping a second, seeing what happened and sort of charting your course that way. But I think factories are awesome
things to be able to create. Yeah. A lot of incumbents in the world would wish to God they have a factory when actually what they have is like, you know, an artisanal, like, you know, mill for producing one thing every now and then or whatever. Yeah. But like the idea to be able to produce at some degree of scale lots of lots of stuff, like lots of what are its improvements or closing bugs or speed enhancements
or like new functionality is like powerful. And I think it sounds negative. But like if you believed that the features you're shipping produce say value as in your system outlined earlier, then you could rename a feature factory as a value factory and all of a sudden I'm buying 10 of them. You know, so like I do think that it's a very easy like maybe it's a feature factory when you're doing random shit, you don't know why you're doing it. Does noting holistic that kind
of groups it all together and makes it like there's no strategy to kind of binds it all. Yeah. And like in true factory sense, it kind of goes out the door and like the mechanical door shoots behind it and you've no clue what happened afterwards. Right. And your job is just to get that stuff out the door and see what I'm like, you know, later on someone will come down from high and tell you sales or whatever. Yeah. Like if you don't have the loops and all that like the proper feedback loops,
yes, then maybe that's a shit experience. But I think like, you know, factory isn't the bad word here in my opinion. Yeah. Depending on how you believe it. So I do like, I mean, I do think, you know, any good software company needs to be able to get a lot of work done in an insurance base of time.
Yeah. That's how you do it. Yeah. Absolutely. It reminds me a couple of things. One is that when I was doing this talk, one of the things I kept emphasizing for people was that the rapid pace of technology means that you're, you know, no matter where you are, whether you're like in a kind of like blue ocean type environment, you won't be for long because people see your success and emulate you, copy you and try to emulate you. Or you're in like a red ocean type situation
because the competition's fierce. Yeah. And in any of those situations, the competition's so fierce that you need to obsess about this system. And you need to try and build a factory like the other thing that comes to mind is the word machine, which is another word that's like factory. It's like kind of dehumanizing about me. I don't want to be a machine in a factory. Yeah. And what you just a whole lot of conversation like if people love their job, they love their job. And
but like, yeah, we would say things like trying, we're trying to build them as you scale. I hope any company who is scaling is trying to say we're trying to build a machine. And this kind of gets in it may be starting to answer your other question. Like, you know, if you're a well-run business, you want to build a sales machine. Yes. You want to build a marketing machine. Yeah. Like a product shipping machine. Yeah. And these are good things, really good things. And so kind of trying to
come back to the trying to actually answer your question. Yeah. The outputs and outcomes, the outputs are the changes in the product. Yeah. And the outcomes are business. Like I said, they're business results. Yeah. And when I think about the relationship between those two things, and the relationship between the customer problem, so to kind of go back fully customer problem, which is the input, yeah, changes in the product, which is the output. And then the business
result being the outcome, you need all three. Yeah. And your customer problem, your input, and then when you start changing the product, you should have an intended business outcome. Yes. And again, that's how you know you can take credit for it if it happens basically. Yeah. And that should be a machine. Yeah. You know, this should be like a repeatable like factory. It should be like a repeatable motion. You can put things into the system and get very predictable
results. Yeah. Yeah. That makes sense. Let's just run through a couple of examples here. We have seen the damage of having an outcome only approach to things where like and for our listeners, this might be like, you were told that we need to improve, let's say, onboarding or activation, or like you're a project management tool and hey, no one's using our files feature. Get everyone using our files feature. Yeah. And like the way it might be stated is our files usage is at 1%
and we need to get it to 10%. Right. And you take that as like as the goal of the project. We've seen that go, I guess, a skew or like be really problematic to work with. Yeah. Talk is true. Some examples here. Yeah. I got one great example for from a few months ago here. First thing like just a realization I've had or are like a journey I'm on maybe. I think a lot of us are on and a lot of lessons are on us. You know, we like I said, obsessed with the inputs,
and obsessed with outputs. And historically, we've made many mistakes and had our ups and downs, but been relatively very successful at shipping good product that the customers value and buy. But I remember a few years ago I was at a on a panel at a conference and somebody was telling me from another like really respectable good tech company, we're saying that their projects are metrics like drive. They're all the projects that like drive up metric X drive Dan metric Y.
At the time I was like, oh my god, they sent a terrible project. And then you know, with this outcomes over output thing, I had like a many identity crisis. I'm like, oh, maybe I don't get it. Maybe like we need those types of projects too. And maybe actually like many things in life to all you get you realize the less you know. And so everyone actually is everyone's right. Everyone has a point, you know, and there's a validity to all these things. But I'm not sure if
I'd say I'm full circle back to metric metric project bad. But when we've tried them, we've struggled. And so here's one example. One way we charge for intercom is by inbox seats. Yeah, in other words, if you're a customer support team and user inbox, each support agent buys a seat. Yes. So if you want to add a new customer support person, you need an extra seat. So that's how our business works in some ways. And more seats. The price is so simple. It is.
Oh, here. You need a new podcast for that. Intercom and pricing. So it's pretty simple, you know, like obviously more seats more revenue for intercom. And we had a kind of a theory, a loose theory that like, Hey, we don't think that like all the people who will be using seats are using seats. And actually they should add lots of their colleagues and they'd see value in intercom too. And I kind of a loose you go see theory. So we went off on this endeavor and the
project was called increase inbox seats. Yeah. How do we increase inbox seats? That likes to the input was business, business focused, non-costner focused. It was like a business problem. Hey, we could like, you know, increase our revenue in this corner by increasing inbox seats. And the project went into circles. We never got past the like project brief stage. Because
the PM team, Tudor Credit, we're like, what's the customer problem we're solving? Like, like I can't design this thing until you tell me or until we realize what customer problem we're solving, what value that customer will get. And therefore like now I can start designing like the changes in the product. Oh, we're going to change the how it works this way, which equals
this customer value, which then results in an inbox seat. Right. So her play that back to you like, I think the team like if they didn't ask that question, the obvious thing that I'd say most people's mind would go to be like pop a load of models saying please add some more seats. Right. Yeah. Like this real like, um, reductive sort of we just need to tell people that seats don't next problem. Yeah. Or like everyone is like, it reaches under paywall. Yeah. Oh, like,
people got to paywall. Yeah. Exactly. Yeah. And I guess like you could also, um, and be a small degree sharper might be like to like look at the difficulty of the of how it is to add somebody to the inbox and maybe make it easier to add or something like that, right? Or or maybe at various inferences like that. But I guess like where it stands at the end of the book was like, how do we make it more valuable for more people to have an inbox seat? It's actually
the question because if it is valuable, people will do it. Yeah. So there is some assumption there. Which is like if we make the product more valuable to use, engagement and the product should increase. Right. And I think if you only think in the world of like trigger load of pop up some paywalls, you're kind of hacking the engagement function independent of the value function. Yeah. Sometimes that's not a bad idea. Sometimes it's like, Hey, people just didn't know that we had
this feature. You know, so we need to tell them. And like in that world, engagement is your problem, not the product. But I think what you're saying is like oftentimes when you're trying to look for something as deep rooted as like an actual revenue boosting feature, you need to actually first look at value. If you increase value and your monetization function isn't broken, you'll increase revenue. Right. And so that's how you play it back. Yeah. But there's a bigger piece there that you said,
which is like your roadmap should be full of customer problems, not business problems. And every business problem, unless it's like fixed this book that's like stopping us from charging or whatever, every business problem should be frameable as a customer problem. Yeah. So it's not make people add more seats. It's like demonstrate the value or increase the value of having a more more of your team collaborate in the inbox. Yeah. And if you do that, then maybe you start seeing the
right types of features or right types of improvements coming out. Right. Exactly. That's the test. Yeah. And that's like an exercise. I think anyone listening could try, which is, hey, look at your project, your current one or next one. Look at how it's framed. And if it is framed as a business problem, can you easily translate that into a customer problem? Yeah. And it should be like
relatively one to one. Like it shouldn't require a great degree of imagination or like a logical gymnastics to sort of say, I don't know if we think if this happens and that happens, blah, blah. Yeah. Okay. We're hitting up on time. I want to ask you one more thing. Within the PM community, which is like within the recent PM community, that's the last seven years or so. Yeah. We've seen all these like pendulum swings, you know, where once there was personas,
there are now jobs that needed to be do it. Right. It seems like we've also moved from like ship, ship, ship, ship, ship, ship to Elkum, Elkum, Elkum, Elkum, Elkum. Yeah. And there's probably been four or five others that I've forgotten about. What are its like sprints and squads or agile and pound-bound or you name it, right? All sorts of stuff like that. What in your opinion should the PM community be thinking about and talking about to avoid these sort of frequent undulations of
its ex? No, it's why actually the truth is somewhere in between or it turns out to be important. Yeah. There's a couple of things. One is, back to what I said earlier and you just said it there, like, oh, it turns out all these things are important. And the less religious you are about things, the more open-minded you can be. It's a question, like, oh, why do people have metrics projects? I mean, understand that first. So the first thing is that all these things matter to some degree,
the inputs and the outputs and the outcomes. Yeah. And it's a system. And I don't think enough people in general building software but PM is particularly to think about systems. I think engineers might think about it a bit more because it's an happening that remains right. But even then they may not think about the system as a kind of a business system. Yeah, people, businesses, decided things. Right. Yeah, it's very, very people oriented system. Yeah. Think about it.
It's like all the inputs are people talking to people. And so the first thing and most important thing by far is to think about this system as a whole. And anything, you know, my kind of spidey senses kind of go anytime I see someone advocating for one part of the system being more important than the other part. Yeah. And that's that's where I think you see these pendulum swings. Yeah. You know, the people are like, oh, it's not about the outputs. It's about the outcomes.
And lo and behold, two years later, it's like, oh, we all forgot to ship. Yeah. So that's kind of the first thing is it's the system. And all three inputs, outputs, outcomes. And the second thing that is still quite surprising to me honestly is there's very little talk about inputs like reality speaking, very little talk about inputs. If you look at all the energy that's put into output, think of like the million ways you can do Scrum. Yeah.
Like the bajillion conferences on like agile, like outputs, like, oh, you know, this is you're inundated. Now it's our about outcomes. Yeah. And actually, like, I'm still waiting for the books about inputs. Yeah. You know, and the energy about inputs. Like how to actually get the right source of information to make the decisions that are best for your company. Yeah. And it's back to like, you know, you know, the shit and shit out there. The apologies, you know,
but like, that's what it's about. Ultimately, like if if the inputs aren't great, you can have the all these three, all three variables are independent. Like, you can have amazing outputs and amazing, you know, like intended outcomes. Yeah. But if the inputs are bad, it doesn't matter. You've got the wrong kind of outcomes. Yeah. You know, like the niche party or business or the niche party or product is amazing. And all the core is terrible. Yeah.
So like a more way to test out just to cause out, be like, if you, you know, for our listeners, who probably are like working in product or works, can they draw like a diagram, a system diagram of like what comes into them? Yeah. What's their decision making logic or calculus or pick your fancy word? And then what's the actual, you know, how did the outputs happen? And then head, we actually chase the output through to the outcome. Yeah. So that we can actually, you know,
so we know who we know who and how we listen to things. We know what we do. And we also know for actually moderate and end to end. And the degree to which you can do that is I think is the degree to which you're in control of your work and just probably your company in a sense. Yeah. Yeah. Yeah. Yeah. And one thing we didn't, we didn't fully mention, but maybe we'll put this system diagram on the blog post for podcast is that there's an arrow coming out of business results back into inputs.
Yeah. Which is kind of more or less where you're, where you're just like self affecting system. For sure. Exactly. Exactly. And that's really important too. Yeah. Yeah. When I think that comes to mind, it's an anecdote for people listening, it might be helpful as on the inputs and the important to the inputs. And another common question I get and thing, something that people are really surprised by. And again, like asked Monday, I gave us talk, same questions, which was what's my role?
And what's your role? You know, like, Oh, and then there's two co-founders. What, you know, what do they do? Paul, you run the product? And what do you do? And I just didn't explain to people and they're kind of amazed by this is that our job is designing the system. And you know, what, here's what's not an input. That's his idea. Yeah. Totally. Paul's idea. Yeah. Like that is not how we run the company at all. Yeah. Yeah. And I know that some people do struggle with, with those dynamics.
And so back to the idea of like, it's the system that matters. And if you're going to rectify one system at the start, get to the inputs. Absolutely. So, and like if I want to get my idea under our map, what I look at is the inputs. And I think why is, why am I having this idea now and else is what, what, what, maybe our system is broken or maybe actually it's been traded off against
something that's way more important that I don't know about. Yeah. But like it's kind of, you have to kind of, you share all the context and you believe everyone's saying and looking at the same data and they came to a totally different conclusion. It's probably that I'm more at it. Right. And with that somber note, I'm not that at it. With that somber note, we will and intercom our product episode six. Paul, thank you so much for your time. My question is, you know, pleasure.
Thanks for listening to the intercom on product podcast. For more content, go to our blog at intercom.com slash blog or subscribe to the podcast on iTunes, Spotify, SoundCloud or Stitcher. This is intercom on product.