Intercom on Product: The principles behind how we build

You can listen to our full conversation above, or read a transcript of our conversation below.

If you enjoy the conversation and don’t want to miss the rest of the series, you can subscribe on iTunes or Google Podcasts, stream on Spotify or Stitcher, or you can grab the RSS feed in your player of choice.

Laying the right foundations

Des: Let’s start at the top. What the hell do we mean when we say principle?

Paul: So a principle is a fundamental truth or proposition that serves as the foundation for behavior that gets you the results you want. What that means is it’s about predictable behavior in the future. We’re big into principles, as you know, and the reason we got big into principles is because they are a way of encoding your mistakes and successes. So any business anywhere, obviously, wants to repeat their successes and avoid repeating their mistakes. Which is easy to say and hard to do, but hard to do institutionally and organizationally for sure. And so principles is the best way we’ve found in which to codify all the mistakes.

Des: Codifying mistakes sounds like we’re going to guarantee that we lock them in – can you expand on that a bit? Let’s say we found, “Hey, three projects all went off course.” Is there a principle to be found in that? Or is it like, “Hey, if this is a consistent pattern then we need to make sure no one ever repeats, we’ll have a principle about the positive behavior that we want.” Is that what you mean?

Paul: Basically, yeah. Maybe it’s useful to actually to share some examples instead of talking about this in the abstract, but it’s basically about us having a predictable system. Obviously our goal, like any product and engineering team, is to ship great software that customers, love, value use, etc. Don’t ship things that they don’t need, or don’t take too long doing it or don’t go off track. And there’s a whole load of anti-patterns probably in how you would want to run a project – projects being canceled or a big epic re-steer in the middle. Over the years, we reflect a lot, as I’m sure many teams do, doing a kind of retrospective as common practice.

Des: Like, “What was good about this? What was bad about that?”

Paul: Exactly. Write it all down at the end of any project – “these are things that worked well, and this didn’t.” Over the course of years of doing this, patterns repeated, repeated, repeated and we said, “Okay, let’s not do this again. And then have a retro to learn the same thing we’ve already learned five times. Let’s actually try and write it down.” And then we kind of stumbled upon the principles I think as the best way to do that.

High-level principles

Des: Let’s talk through a couple of principles and then we’ll go back to the what, why, how, etc. What are our principles for how we build product?

Paul: Yes so we have three top level product principles. We actually have a bit of a system. We’ve three top level product principles. They’re the things that we care about the most, I think. Then we have a five design principles that are specific to the design team and the discipline of design. And then we five engineering principles, again, specific to the discipline of engineering.

Des: So we have 13 in effect but in practice, any individual only has to observe eight, right? Everyone inherits the top three, and then if you’re an engineer, you’ve got five engineering principles on top.

Paul: Yeah, that’s true and 13 does sound like a lot, but you’d hope that any team in the company is familiar with all the principles. I mean, you don’t have to remember and recite 13 principles. But in practice, this is about predictable behavior. In practice, you should see people enacting these principles. So for example, one of our product principles is start with the problem. This is, again, a principle that came from us realizing that we oftentimes weren’t starting with a problem. Instead we were starting with some cool idea we had or some kind of fictionalized hypothetical customer. The reason this principle exists is because we believe that any solution that we ship is only ever as good as the problem understanding. So the better you understand the problem, the better thing you’ll design.

“We believe that any solution that we ship is only ever as good as the problem understanding. So the better you understand the problem, the better thing you’ll design”

Des: It’s that line – “a problem well stated is a problem half solved.”

Paul: Exactly, so we spend a ton and ton of time on problem definition. Problem prioritization, first of all, “Is this an important problem? Do we understand this problem? Okay now we understand this problem a bit better. Let’s restack it against the other problems that we’ve a good an understanding of.”

Des: To be clear, a shit version of this would be, “The problem is we need ticketing.” A much better definition might be, “We need a way to have a consistent record, blah blah blah…”

Paul: Yeah, “Our customers are trying to do x or y.” So the way this would’ve worked in the past, years ago, where we didn’t have these principles, there might be a design review or product review in a project and we start asking questions like, “Have we shown us to customers? What did they say? Did they react well to it? And can they articulate what problem this is solving for them? Is it solving a real problem? Or is it hypothesized?.” Or “Give us really specific examples of how this would actually change how they work,” etc.

Oftentimes what you find is the understanding of the customer problem we’re trying to solve is really ambiguous and vague and loose. And as a result then the project is ambiguous and vague and loose and it gets pulled in all different directions. What you end up with is just people disagreeing with each other, very opinion-driven rather than evidence driven. This is as opposed to a project where we spent a ton of time up front understanding the problem. And then downstream from that, when you come into a design review or product review, instead of asking these types of questions, you just get way richer, better answers because we actually spent the time to understand a problem upfront.

Avoid truisms

Des: Our other two high-level principles are, “Think big, start small” and “Ship to learn.” Rather than walk through both of those, I think one important point we should stop and reflect on here is something I’ve really believed is that most of the time when I see companies decide that they want to build out some principles, they ended up basically saying stuff that is just generally true like…

Paul: “Ship good software.”

Des: “Ship good software,” or “Design matters,” or you know, “Focus on the user” or whatever. And what they don’t really do in my opinion is come up with a principle that’s pointy enough such that there is as an equal and opposite counter-principle in a sense. I think that’s an acid test that we’ve always had for our principles. So if we take, say, well you can pick “Think big, start small” or “Ship to learn,” what’s the opposite principle? And when would that be good?

Paul: This is actually a really important point because like you said, I’ve often talked to people about principles in other companies and their principles, and values too by extension, tend to be truisms. You’d never disagree with that. So “Think big, start small” is a great example where the basics of this principle is kind of self explanatory And these principles are in order, so it’s “Start with the problem,” then “Think big, start small,” then “Ship to learn.”

So you started with the problem, you have a deep understanding of the problem and then the next stage is, “Okay, think big. What’s that big dream? The vision? What’s the concept design for this? Solving this problem.” So think big and don’t be limited by any kind of constraints. And then start small and take the big idea, take that bigger vision, this longer term plan or dream and then start small, break it down into the smallest, smallest pieces. And keep scoping back, back, back, back, back, until you have the smallest coherent solution. That’s how we want people to work and the biggest piece of feedback we get within this principle is “How small is small?,” and we pushed for very, very small.

So the opposite of this principle is also valid, which will be “Think small, start big.” That is a valid principle too.

Des: What would that look like?

Paul: For “Think small, start big,” I imagine any company that is working on infrastructure, for example. Imagine an electricity company or renewable energy company. There is definitely innovation in that space, Tesla comes to mind, for example. But if you are taking on something that has significant infrastructural costs, you obviously need to start big. There’s no version of a road infrastructure that doesn’t mean building loads of roads. If you’re Apple, who apparently are building a car, designing and building a car…

Des: They can’t ship half a car.

Paul: Exactly yeah, it can’t start with a wheel, you know? So there is “Start big,” and then depending on how much innovation matters, you can think small.

Des: With the latter, it’s like “Think big and then start small,” that small is proportionate to that big. So it might be feasible to say, “Think small, start big,” which is actually saying is, “Find a small next step. Ship all of it and you’re done.” What we’re saying is, “Envision the whole system, find the first viable piece to ship that, but you definitely have one eye on the rest.”

Paul: Yeah, it’s the smallest coherent solution. And actually they way we do this in practice is. We build a little table,, and the table has in it all the kind of components of in a solution and then it has, effectively two columns, sorry, three columns: essentials, then differentiators, and then not now. And this idea of “not now” is really powerful, because saying no is really critical to any kind of product strategy and product execution. And so if you have a column that says “no,” that’s pretty hard for people to actually be comfortable with. Whereas “not now,” “Oh yeah, not now. Okay. Later maybe,” and the thing I cared about most is on the “Not now” list, it’s not on the “no” list. You don’t have a no list.

So the essentials is, you almost start by putting every single thing into “Not now,” and then painfully drag them over here. That’s another kind of key component of this principle “Think big, start small” is it should be excruciatingly painful to pull things into the “Essentials” or the “Differentiators,” which is then about the thing we go and build.

“They’re empowering as a way to not only have leadership and the broader product team act in consistent ways, but also for the teams to hold leaders accountable”

Des: And I think to tie this back to the where is it valuable. The biggest value you get as an organization, by having stated principles – and for us that means they’re printed on the walls, they’re referred to in every a document defining a product scope – is the predictability. It’s the predictability of the leadership team, it’s the predictability of you, of me. Great leadership hinges on some sense of predictability, which is if you’re consistent in how you apply your logic, it makes it so much easier to work alongside you because you know if you walk into a product critique, people can probably guess what the first words out of your mouth will be. And that actually really helps.

And that’s brilliant because the more that that’s true and the more you live and embody that, and then we encode it, the less necessary you are to be in everything, in a sense. And the more our leadership team and then the more our PMs and right way down until a fairly new PM can realize, actually here is the principle, it’s alive and breathing and it infuses everything that we do. So I think that’s one of the biggest sales pitches for me about principles is that it’s a way of finding the most specific, unique things to how you build software and making sure to everyone lives by them.

Paul: Yeah and it actually goes up and down too. So one of the greatest things about these principles, I think is, in the past before Intercom, I’ve worked in projects and teams where you’re effectively building the VIP’s idea, or the leader’s idea. And that’s an anti-pattern here, that’s not the kind of way we want to work. We want to a scale of the company and have all of our teams and people build and come up with great ideas and execute them themselves.

But obviously you and I are involved in different ways at times to check in and ensure we’re aligned on company strategy. But I’ve had people point to the posters on the wall too. It’s a way for them to call me out and say, “Hey,” they’re keeping me honest and holding me accountable to the principles and saying, “Well, Paul actually, the feedback you’re giving us is not consistent with our principles.” And that’s brilliant, because obviously-

Des: No one’s truly consistent, but the ink on the wall won’t change.

Paul: Yeah, exactly, exactly. And so, they’re empowering as a way to not only have leadership and the broader product team act in consistent ways, but also for the teams to hold leaders accountable.

Des: It’s a fair game.

Paul: Yes, exactly.

Engineering and design principles

Des: So we’ve talked through the product principles. Maybe let’s touch on a couple of maybe the design or engineering ones? I’ll go through one that I like. What I like about our engineering principles, is, at the top line they do sort of sound like truisms until you read the actual trade-offs. So if we say, “Keep it simple,” might be, well it is an engineering principle and for sure who’s going to say “Keep it complicated,” right? But actually when you get into the specifics of it, what it says is, “This means we will trade off performance, financial costs and perfect product abstractions to keep our solutions as simple as possible.”And when you actually realize that, you’re like, “Okay. Now that principle has teeth. Now it actually means that you can’t justify things against that because you’re still violating this core principle because we said we’d trade that off.”

What about design principles?

Paul: There’s some good ones in the design principles. One that I personally like a lot is the principle called “Follow fundamentals.” Again, at the surface, this may sound a little bit like “Follow fundamentals? Well that sounds like a good idea anyway.” But what this is really getting at is effectively UI design. And so Intercom, we believe our zoom level of innovation and newness and new things is at the kind of high product level. It’s not at the design level. And so, for example, if we’re designing our inbox, our inbox should work a lot like every other inbox, because then people can use it, and anyone can join a company and start using Intercom, the inbox and suddenly know what to do. “What do I do?,” “Oh, you type in the reply box,” “What do I do next?,” “Hit that button.” That looks like all the other buttons. And “Follow fundamentals” is the principle by which we design UI, effectively. And we’re not Snapchat, right? We’re not trying to design new types of UI.

Des: Also our UI isn’t inherently a part of brand, in some sense. As in, we don’t want to be known as the people who have reinvented UI components and have a new take on a radial menu or a fancy version of a dropdown or whatever. Some of this is kind of inherent in our product domain. Intercom by default is a complex enough piece of work such that to add on an extra layer of, “Please now learn our UI,” is just messy. So wherever there are standard patterns, we should embrace and we should just, as you said, “Follow fundamentals.”

Paul: Another one I like a lot in the design principles is, “What you ship is what matters.” And so this again touches on something that I know you and I both care a lot about and our design leaders and design team do. Which is, there’s been an amazing progression in design craft tools. So Figma and Sketch and all these different things and so you can kind of fall in love with your tool, and fall in love with your craft and fall in love with your Figma files.

And actually your Figma files don’t matter any, unless customers experience the thing you designed. And so we have in our design team, a principle that says, “What you ship is what matters.” So in other words, when it comes to your performance or the impact you’ve had on the company, we look at what you’ve shipped. Not the 10 bajillion Figma files that were created. It’s like “What actually went out the door?.”

Des: And where’s the trading line there? So if you’re a designer, obviously you’re not going to go and write the code, but is it, you know, what’s the opposite of this? What’s the behavior we don’t want? We don’t want people taking a lot of pride in a design that never went out the door?

Paul: Yeah, setting a lot of pride in designs that didn’t go out the door. And then the inherent behaviors that you get from that, so maybe complaining little bit, feeling a bit aggrieved.

Des: “My genius work didn’t get it because it wasn’t worth building basically.”

Paul: Or this beautifully crafted user experience I designed, that is, by the way, technically impossible to build, didn’t get at the door.

Des: Or ludicrously expensive such that we’d never justify it, right?

Paul: Right. Or won’t scale. And so what this is actually touching at and a lot of these principles on the design engineering side touch on collaboration because we work and promote a very, very collaborative culture within teams and PM and design and research and engineering and so on. And so what this is actually getting at is, the designers should be deeply collaborative with the engineering team. And actually some of the engineering principles kind of speak to reverse.

Des: Absolutely.

Paul: They have a principle called “Shape the solution,” which is “Don’t just take, shape the solution.”

Des: Yeah, get into those meetings and make sure they’re not shopping without price tags. That makes sense. I suspect a lot of the folks listening will have already a set of company values and they’re probably eyeing up that set of posters on the wall and thinking, “What would I write that’s different to them?.”

Des: How do you think about values a company might hold versus their product principles? What’s the difference? Where’s the trading line?

Paul: Yeah, yeah. So the kind of distinction that I make, and there’s definitely a bit of overlap between what a value and what’s a principle. The distinction I make is values are, like you said already, principles are about predictable behavior. Values for me are more about how we think and how we feel.

“Principles are about predictable behavior. Values for me are more about how we think and how we feel”

For example, we’ve a set of values as well. We have 11 values. We have put them in a little book and when you’re joining on your first day you get the little Intercom Book of Values and there’s 11 of them. There’s a value around being optimistic and positive. The idea there is that Intercom was this fast-growing company, changing all the time, in an increasingly competitive environment. We’re kind of shooting for the stars and in order for people to kind of take that journey with us – because it’s a hard journey, this is a challenging thing to do, there’s easier more chilled out places you can work – so we need people to stay positive and stay confident and optimistic about the future. And so that’s a value and it’s more like thinking and feeling. Whereas our principles are about doing, behavior. So “Start with the problem” isn’t really about how you feel. It’s, “No, just start with the problem.”

Des: It’s more like when you actually go to work, this is the repeated way we believe success will happen for us.

Paul: Right, exactly.

Why principles are unique to a company

Des: To what degree are principles connected with sort of… What I want to say is competitive edge or a company’s position in the market in some sense. What I’m wondering is, Apple’s principles probably wouldn’t work here right? And why would they not work? Well maybe it would mean that we’d go dark for 18 months and come out with something no one’s ever seen before. But with the rapid nature and evolving nature of SaaS might mean that we are shipping it to an audience that no longer exists or something like that.

But maybe a different way to ask this is, if Intercom parted ways with Paul tomorrow and you took the Head of Product role at Joe Soap Product Management App or to-do the app or email client. How do you go about bringing the principles in? Assuming they’re open to it, assuming they’re, “Hey Paul, give us some of that principle goodness.” What do you do? And how much of it is internal versus how much of it is, “Well actually we’re in a pretty competitive space where everyone’s shipping features, blah, blah blah”?

Paul: Yeah, it’s a great question.

Des: Nice little five part question for you there.

Paul: Oh, I love it, I’m going to add a sixth which is, for people who are listening in, they’ve heard, “Start with the problem,” “Think big, start small,” “Ship to learn,” should they think, “Hey we don’t have principles. They sound like three good ones. Let’s get them on the wall.” It’s an interesting question. I don’t think that they’re universal. I don’t think these principles apply to every company. These are our principles that we learned or we codified over the years based on what we were learning, what we believe and things like that.

Having said that, one thing I would say is, when you look back over our years and our successes and failings and so on, the success that we have had in terms of our business growing and customers growing and so on, I think a lot of it’s down to these principles. So I think there’s a direct causal relationship between projects where you follow the principles and the projects that were successful. There’s a direct line there. I think these principles do cause success in many cases.

Des: For us in the years of circa 2011 through 2019 or whatever, right?

Paul: Yeah, exactly, exactly. And so a couple of things though, these principles don’t necessarily apply to other companies. And so if I was to leave and into this new fictional parallel universe to this sort of company, I would try and understand what the company looks like and works like first, because these principles may not be good principles for them.

Des: And that might mean going through the postmortems of all their successes, all their failures, working out what’s consistent and what’s in both in a sense and all that sort of stuff?

Paul: Yeah the principled in some way are almost a research exercise, the creation of them as some kind of deeply internal kind of reflection, being very honest and direct about what you have and have not done well over the years in the past.

Des: What’s the definition of success for these things out of curiosity? So if I said, “Hey Paul, there’s this new team I’m off to find again. We need to find their principles.” When you go through these projects, is it commercial success? Is it just, did everyone feel like we did a good job? Is it, are we proud of the output or outcome? Any of that sort of stuff?

Paul: Yeah, it’s definitely a bit fuzzy, for sure. There’s definitely some judgment in terms of, “Did we apply the principles well? And then what does success look like?

Des: You just want to avoid the circular logic where this was good because we applied our principles versus this was good, and as it happens, our principles were at the forefront, right?

Paul: Right, exactly. And the principles have evolved. This is another thing to mention, we have three high level principles today, we used to have five and then we merged three of them into one. And actually at the moment we’re having a discussion about merging “Think big, start small” and “Ship to learn.” We’re talking about merging them, because they’re basically sister principles. When you start small, you are actually starting small so you can ship earlier. And the reason you ship earlier is to learn.

We are talking about merging them and we’re talking about maybe introducing a third principle, maybe, around being outcome, first output focused. Which is kind of funnily enough what you’re asking about there as well. What’s the outcome of these principles versus the output of them. So they do evolve and change. It is really commercial success, product success, customer success, some version. When we set up projects, we have success criteria, whether that’s qualitative criteria, quantitative criteria, and so the projects are already judged against that. And then we…

Des: Work from there.

Paul: Work from there, yeah.

Principles are not transferable

Des: I think what’s interesting to me as I was just playing out my head, if we, and I know we don’t often speak to our competitors, but let’s say Zendesk right? Clear, strong market dominant leader for their help desk ticketing type use case.

I think your principles might be different in a world where you believe you’re dominating the market. Let’s say Salesforce are dominating CRM. As a result maybe things like starting small isn’t actually as doable for them because they need something to launch at Dreamforce. And similarly, maybe the idea of “shipping to learn” doesn’t make sense, when they actually feel that they’re kind of dominating the market and as a result there is not a lot of uncertainty there. Whereas we’re still growing up as a company. So we’re just the learning is still this new ocean that we’ve sailed ourselves into and we’re still trying to work at the boundaries in a sense.

“I think your principles might be different in a world where you believe you’re dominating the market”

And so I do wonder as well, is it the company’s position in the market? So I mentioned project management earlier, that’s a kind of near on perfect competition type world where there’s probably a dozen project management e-type apps, all doing 50 million plus in annual revenue. All with their own unique take and as a result, I bet you to principles you’d have to apply it to enter that market, and then sustain yourself in that market, versus dominate that market are all quite different in a sense. So it is, I’m really just putting this out in my head, but I suspect that part of the maturing of the principles and the reason we evolved in this cause our own position evolves as well. It’s a different game when no one’s ever heard of you, versus when everyone has high expectations of you.

Paul: Right, right. Yeah, totally, totally. A good example of this, I think is the kind of business strategy of Fast Following, which is you see competitor launch something, and then you quickly copy it and fast follow and sometimes it makes it-

Des: I’m familiar. I’ve heard of a couple.

Paul: Yeah, me too. Microsoft is a good example – they’re the company who made this strategy famous.

Des: Not who I was thinking of, but carry on.

Paul: Yes that’s a chat for another day, perhaps. So, “Starting with the problem,” is that really the right principle for a fast follow business strategy? Probably not.

Des: Absolutely not. It’s like, “Start with their problem.”

Paul: Almost like start with their solution. Now, there’s risk to that too obviously, whereby you can copy all the mistakes they made. But it might actually just be faster if hundred percent of what you see, of the hundred percent what you see, 60% is success and 40% failings. It might actually be faster to just copy the whole thing, 40% mistakes and all, to catch up.

Des: Versus doing the homework to find out which 60 matters, it might be just easier.

Paul: Meanwhile they’ve a million more customers in the time you were-

Des: Yeah I was going to say, that whole business strategy is based on the idea that, “Well, we already have a quicker route to market,” or you have somewhat a competitive edge at the top level principle, which are kind of saying, “We don’t compete on product. We compete in the fact that we already have customers” or something like that.

Okay. Let’s bring this home for would be listeners. They’re out there. They’re startups, size 10 through a thousand. They don’t have product principles. Why should they think about adding them? If they should at all.

Paul: It depends what they value. I guess. If they value creating a repeatable, predictable product and engineering culture, they should create them. There might be people out there going “I actually don’t want that.”

Des: Yeah, we like dynamic sort of…

Paul: Yeah, there’s some nature of being able to change on a dime that matters, or maybe they’re in some crazy competitive environment, like VR or something, where it’s just the wild west and no one knows what’s going on. But if you want to create this predictable, repeatable culture, I think principles are brilliant way to do that.

Des: Yeah. And then what’s the best way to start thinking about it?

Paul: Oh, reflection, retrospectives or flagship projects.

Des: What projects let to our best commercial success?

Paul: Yeah, it’s a really a research endeavor – “Let’s look at the success, the failings,” get everyone involved. It’s a real collaborative, pull everyone in. Everyone has different insights and you’ve got to then summarize and synthesize all that, all that learning.

Des: And I guess you’re looking for variants there, so you’re looking for, I can imagine, if we pulled it all of our projects of all time ever and divided roughly into goods and bads or wins and losses or whatever. We’re looking for to things that are uniquely, consistently true to goods versus bads, give or take, right? Of course you could have we might’ve followed one but not three of the principles, whatever.

And then specifically would end anti-patterns, you might see the things that have always been, “Oh, we rushed a deadline,” or “We didn’t have a senior technical person on it,” or whatever the hell the thing might be. I noticed all our principles are framed into positive. What we don’t have here as well is, “Don’t, never, blah blah blah,” or any of that kind of stuff. What’s the thinking there? Is that just basically being constructive and positive in our language or?

Paul: That’s a good question, I haven’t really thought about it much to be honest. When we, when we kinda teach these principles to new folks who join, we do have, we have a little training deck around them. We do have a slide that says “anti-patterns.” So we do have actually a lot of negatives, “Don’t do this, don’t do that.” For example, “Think big, start small” one of the anti-patterns is do not ship janky shit.

Des: That’s a misinterpretation of it right?

Paul: Yeah, exactly. Starting small doesn’t mean shipping janky things we’re not proud of. We’re starting small and then still being proud in terms of the design execution, the engineering.

Des: This principle doesn’t excuse low quality.

Guides, not rules

Paul: Yeah, exactly. So we do have kind of anti anti-patterns there. Two other quick things to mention that we haven’t covered today is, one, these are guides, they’re not rules. We don’t stand over teams and say, “You must follow these principles!.” So they’re guides and sometimes people make exceptions and don’t follow them and it’s actually valid reasons to do that at times. And then we learn from that and try and re-codify that back in or change a principle, evolve it. And the other one is they’re really for decision making, or ultimately they’re qualities that actually helping you do on the ground. And it’s just faster decision making, rather than have a big giant epic debate, one or the other, you cannot just point to a principle often and say…

Des: And it means you don’t need to escalate as well. If you need to tiebreak between design and engineering, that’s what the principles are there for. And if we can’t then we can escalate it in a sense.

“If you need to tiebreak between design and engineering, that’s what the principles are there for”

Okay, so going back to this mythical team that all of our listeners are on, so they have decided they want this repeatable, scalable, predictable process that will get them a consistent level of quality. They’ve looked at all the successful projects, all their unsuccessfuls. They’ve found the invariance in both and they’ve come up with maybe a set of, maybe they broke them into design and engineering, maybe they didn’t, but they haven’t set a set of things. How do you get them out there? How do you just bring it home? Do you call an all hands? You sort of tell everyone, “Here’s what we’re doing.” There are posters, booklets, training, webinars, onboarding. How do you think about all that?

Paul: Yeah, I mean for us, it was a process and all these things came later. We have beautiful posters now, they came later, earlier versions were just text on a doc.

Des: Like Microsoft Word, Arial, 64 point font.

Paul: Yeah. So that stuff evolved as we, as they really stabilized. And as I said earlier, they’re years old now at this point and they evolve very slowly. But what we did do with that was pressure test them. So even when we’ve got a new principle, if we do have this new principle around an outcome focus for example, versus output focus. We’re going to have to test that, try it out, test it. Is it helping us make decisions faster. Are we wrapping ourselves up in the philosophy of the principle as opposed to just actually doing, getting work done?

Paul: And if it doesn’t prove to be very pragmatic, we just bin it.

Des: If it doesn’t allows, it’s not useful.

Paul: So I think it’s people just need to try, “Okay, let’s try this principle in a project,” live it day by day and see if it helps us.

Des: And then ultimately they’ll start to calcify and solidify and you can then start to put them on walls, make them a part of your onboarding, share whatever information.

Paul: We did it very organically, and then we might’ve brought out new wording or evolved the principles. “Hey, everyone we’ve merged these three into one.” But I don’t think it would work if it felt 12 commandments style, coming down from the mountains with the principles, you know?

Des: New plan, we’re now going to “Thing big and ship small,” or something like that.

Well that’s pretty much everything I think we know about principles. We find them super valuable. Hope you all do too. This has been Intercom on Product. Thank you very much.