Product Enablement Principles

John Cutler at UXDX Community: [In-Person] Product Enablement Principles in partnership with Product Tank. Video: https://www.youtube.com/watch?v=9qOP7xWneq4&t=2s

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Eight weeks into a product enablement role

[00:00:00] Thank you so much for being here. This is my second time in Dublin. The first time was 2019, at a conference, and now it's the first time I'm coming to my office, so that's exciting. Anyone from Toast? We'll chat tomorrow, it'll be fun to meet you, those who I haven't met on Zoom already. And those who are visiting us from other companies, thank you so much.

[00:00:23] Let's jump in and leave as much time for questions as possible, if this interests you. First, before I jump in, who has someone at their company who has the role product ops? One, two, three. Wow. Product enablement? All right, so we'll do this one. This will be fun. You're basically seeing someone eight weeks into their role, embracing this new role, so that's what we're going to dig into today. Hopefully it'll be interesting. We'll get into a little bit about what product enablement is and product operations, or at least our interpretation of it at Toast, and it might be different. Yeah, there's a seat there for you. Let's get started.

[00:01:12] What I wanted to do before we jump in at all is literally show you a snapshot of my last 48 hours before I left. You could think of Monday and then Friday: what someone with the product enablement title was doing at a company like Toast. I wonder, do you think I can use the laser pointer? Hold on a second. No. No. Okay, good. I know that feature is not available in the room.

[00:01:40] I'm just going to share a joke. My partner and I had a birthday for my son, and there's a text where she says, "I need you to deliver a clean cooler with cold beverages." And the product manager in me said, "Is the goal to have cold beverages?" I just think it's funny. So I just need to know what features are available.

Three circles of teams

[00:02:01] If you want to know what someone in product enablement was doing, this is an example of me both teaching people internally and circulating a model to help us have a good conversation, as we try to figure out how we're scaling as a company. What this basically shows is an idea of three circles of teams, and then I'll explain what my job was in this. You can see in the middle, you can imagine that this is your product team: engineers, hopefully a designer in there, but they might not even be in that first circle team. And then as we go out, you get this second circle team and third circle team.

[00:02:41] So what was my role in all this? Well, in product enablement, it's not just product managers who are my customers. I also have to think about helping them collaborate with other people across Toast. Why was I doing this? I was having a conversation about what the right model for engagement is, given different types of work. For example, who loves the folks doing documentation at your company? Everyone loves the documentation. Oh, yeah, yeah, yeah. Okay, we've got a documentation person.

[00:03:14] You can imagine that often things like documentation and technical enablement, teaching our own customer success folks how to support the features we have, or teaching sales how to sell the features we have, that's not what a lot of product managers think about every day. They're focused with their team: we're going to deliver this thing, we're going to measure the impact of doing this thing. Yet you have these concentric circles of teams that surround you, who are there with the express intent to help you do that thing.

[00:03:52] So what was someone in product enablement doing? I was literally going to people and saying, "Crystal, who works on my team, your team is currently operating in a transactional model. You're pretty short-staffed at the moment. Is that the right model for how you want to collaborate with product?" "No." "Where do you think you need to be?" "I think I need to collaborate." "Do you have enough people on your team to be able to collaborate right now?" "No." "Okay, so let's do that." That's one example of what I'm doing: thinking about how product managers can more effectively collaborate with people across our company.

[00:04:28] There's probably a number of product managers here. We also have that problem, like any company, where product managers find themselves copying and pasting the same information into a thousand different tools to let people know what's going on. So this was part of an effort to say, "Could I support you with better platforms," which would be a little bit more of a product ops type thing, "to make that easier?"

Writing the product operating system

[00:04:49] All right, let's jump into some other things: two days in the life of product enablement. I like writing. This is the table of contents of what I've written so far at Toast in our product operating system. That's about 30 to 40,000 words. I went a little crazy with this, but I'm basically documenting ways of working, comparing them to other ways of working in the industry, and making sure that I have this ready as we start to evolve what we're doing.

[00:05:19] I don't know the scale of y'all's companies, but once you start to get to 500,000 [?] people, there's no one way in your company. There are literally layers of ways to do things. And with more and more people being async, more and more people working remote, it becomes increasingly important to at least have a shared language. You can notice right there, there are six core things: teams, capabilities, models, goals, bets, and measures. Can we just start using the same words for things? So when this team is saying, "We use OKRs," and the other team says, "We use the big hairy audacious goals," what are those? BHAGs. Yeah, that's one of the ones I don't like saying five times. What are they all? They're goals at the end of the day, so we should call them goals. A lot of what product enablement does is basically information architecture. It's just thinking about whether we can use the same language at the scale we're working at.

[00:06:13] Another thing, depending on the size of your company: what I'm also doing as we go through this is making decisions about what must be consistent across the organization. Toast is scaling fast. We'll get into this in the principles: we want to challenge all efforts for consistency, because consistency will always cost you. Now, it may accelerate what you're doing, but when someone says, "We need to have one template for a PRD," the reason they hired me is to say, "Why? Why do you need one template for a PRD?" "Well, that way everyone can read the things." "But what if the product manager has a better template?" So, those types of discussions.

[00:06:50] You can see here the 14 things that every team needs: a mission, a vision, a team scope, a charter, working agreements, strategy, business plan models, a roadmap, bet artifacts, goals, release planning, measurement and metrics, and a model for continuous improvement. But in those sections I don't actually tell them how to do it. I say, "A 12-month roadmap of bets will meet these six or seven criteria. It will show me your thinking, it will communicate what your strategy is, it will show sequence, and ideally someone from another part of the organization can understand your thought process." If I go any deeper, it's probably going to be too specific. So this is the kind of thing that someone in product enablement is doing. If you were worried that I wasn't going to keep writing now that I'm not working at Amplitude, that is not going to happen. I get to write even more.

Internal platform principles

[00:07:42] I do these things. What's the next thing? Oh yeah, what did I do this morning? I worked with our internal product teams. We have these internal platform teams, and they said, "John, come and talk to us about product thinking as it relates to internal products." We did an activity to talk about how you would apply product principles if you were an internal platform to move data around, or maybe security or identity resolution, or any number of those things.

[00:08:08] You can imagine this is me acting as a subject matter expert internally, but with a very light touch. I don't want to tell the teams do X, do Y, because they need to evolve their own principles. I worked with Nick, who's based here in our Dublin office, and we worked out the rough scope of some of these internal principles for running internal products, and we codified them. And then today I did an activity with the leadership team in that particular area, circulating these, triggering discussions, challenging these particular things. So that's another role that product enablement might play.

[00:08:43] Well, let me ask you this question. Who at your company writes out these principles in general? Is it the CPO or something? If you have someone who writes them out and clarifies what you are and what you aren't, then you might want to consider some product enablement to do these things. You'll notice with each of these things we're trying to say what we're not. "Instead of thinking in terms of projects or features, a capability-aligned team thinks long-term about improving the ability to do something, deliver something, or support something." We're trying to get these opinionated principles to help that particular group. It tends to help to have a subject matter expert, so my years at Amplitude paid off in this.

[00:09:24] What else am I doing? I did a workshop for that team. Here's the five principles, and we went through and did a nice workshop. This was today. Today's been a long day already. This was very exciting, talking to them about what it means to run products. And they were very grateful. I want to say one cool thing about doing product enablement or product operations is you get to help people all day. And generally, if you don't screw up too badly, they're pretty grateful that anyone is trying to help them. So this was a good moment.

My OKRs as a product

[00:09:56] Finally, do you want to know what my goals are? If you're ever curious about what someone from product enablement does, this is a set of my OKRs related to this enablement problem. I talked about how we get partners and product teams to collaborate together effectively. It's literally my OKR stack: "A high quality and high confidence release enablement process that drives customer trust and fosters strong partnerships between partner teams and R&D teams." Notice how I framed that, too. I could have framed it as efficiency or effectiveness. The key part of that is the partnership, as we're working with the teams.

[00:10:35] And then you can see that in a sense, in product enablement you have a product. Just like a product manager, I have my goals. I want to improve our playbooks. I want to improve visibility into the roadmaps. I want to improve release confidence that we're doing the right thing. And then build a continuous improvement muscle, so that we can improve what we're doing all the time. It's very similar to product. In fact, if you're a product manager and you find yourself intrigued by ways of working and systems thinking and other things, this is a viable career option. You get to be a professional product nerd all day, which is really, really fun.

[00:11:10] So that's another example. Here's the writing. Yeah, that's long. Oh, it's duplicated: you see the second and third ones are the same image. But it is legitimately that long. So with that, any questions before we jump into things? I could give you a more formal definition of product ops and product enablement before we get going, or does anyone have any questions about the two days in the life?

Q&A: principles, writing and where to start

[00:11:41] Audience: What happens when the CPO doesn't agree...

[00:11:46] John: Yeah. We'll do lots of questions later. It'll be fun, and then you have your drinks and stuff.

[00:11:54] Audience: What happens when the CPO doesn't agree with some of the enablement principles you might have, or some of the writing that you have? Like, "I don't agree with that value," but you've released it out to the entire team.

[00:12:05] John: Well, I show it to them. I mean, if they don't believe in it, it's lights out. Steve Fredette is the founder; I had to show him these principles and ask, "What do you think of that?" And the CTO, Deborah [?]: "What do you think of that?" It's a big shift in my role from Amplitude, where I was helping other companies a lot with this. You really do have to work these things through the process and be open to people having opinions and perspectives on those particular things.

[00:12:34] I tend to think with principles, they're either the most generic things that you have in your whole company, or they actually mean something. And I think when they mean something, they tell you what you aren't. We have layers and layers of principles. The people who've been here longer at Toast know we have the Toast company principles, and that was just a little snippet of principles for a particular team. I think that if you do principles right, it starts a conversation, versus if you look at them and everyone's like, "Yeah, who wouldn't want happy customers? Customer-centric." The key with principles is actually making people think.

[00:13:07] And I'd make the same point about strategy. A friend of mine was at Netflix for a long time, and they had this one-line strategy that was beautiful. It's BHBO: become HBO before HBO becomes Netflix [?]. It really makes you think, versus these pretty bland ones like "be the best in SMS." That doesn't tell you very much. I don't know if that answers your question.

[00:13:38] One other thing to realize about principles, for any of you who are that kind of person: some people don't give a damn about principles, and you have to not be down on those people. Some people just think it's extraneous. "I'll know it when I see it." Pretty skeptical. "I'm just going to see what the leaders do. Principles don't mean anything." And I think that if you're passionate about principles, you also need to agree that they're not for everyone.

[00:14:03] Oh, more questions. Yeah, let's just jump into questions. I just showed you a little bit of stuff; we can go on that.

[00:14:07] Audience: Back to this slide. John, as you said, this is a lot of writing. How do you make sure that this written-down stuff works? That people read it, it's actionable, and they refer to it?

[00:14:21] John: Oh, I'm never going to show that to them. No, I've come to the conclusion... I worked for this CEO, his name was Scott Kurnit, at a pretty audacious startup, and he was the kind of person who said if you can't say it in a tweet, don't say it at all. My personal style is to start big and then whittle it down to pictures and things like that. Some people, though, hate that. Some people, if they can't say it in a sentence, don't bother doing it in 30,000 words.

[00:14:51] I tend to write this, and then maybe a couple of the nerds... most of the people at Toast don't know that I've written this, but I look at the view history and I'm like, "Oh, I've found a fellow nerd here." Someone wrote me the other day over Slack, "I read the document." I was like, "Okay." You can't expect people to read that. I think the same thing: you need to be comfortable with the idea that you're going to need to communicate it 15 different ways as well. And some people are just super skeptical. I find writing helps me think straight, so I've practiced writing today. Cool.

[00:15:34] All right, anyone? Oh yeah, go ahead. It's funny, we could just do this today. We don't even get to the principles.

[00:15:45] Audience: It's more around where you start. You've described the two days that you just did. But when you come into this new role, I think you said you've been here eight weeks...

[00:15:55] John: Yeah.

[00:15:55] Audience: Where did you begin? This seems like the product of a lot of analysis.

[00:16:00] John: Oh, it was. Yeah.

[00:16:01] Audience: Where do you start?

[00:16:03] John: Well, I think in this role you can do a certain amount of organizational anthropology. The things that I look for specifically are where power lies, how power is exchanged between people, and where there's incoherence between words and action. I used to be a not very good change agent in a number of companies, where I always wanted to change it up and do these particular things. But I've become a lot more circumspect about what's possible in a particular organization. And we'll get to that in some of the principles: it's not about you. Everyone has their own agenda for being in a particular company.

[00:16:44] So, observing, doing a lot of reading, seeing how people communicate. And I make a point of asking how change actually happens. I'll ask each person, "What is the last thing that you actually saw happen here?" And sometimes they'll say, "Oh, the only way we can make something happen is that 55,000 people agree with it, and then we do an eight-month project, and only then do we get it done." You're not going to come in with quick change at that particular point. So that's what I look for: power, relationships between people.

[00:17:17] Another big one is just how teams are really incentivized. A classic one: in the Bay Area there are a lot of incentives to basically farm out individual projects to engineers. They give every engineer their own project, they load them up. If you get the project done, you get your promotion. Finish a number of projects, you move ahead. Outside the Bay Area, there are sometimes more communitarian countries and companies, where there's more of a team identity and the team is thinking about moving the thing forward.

[00:17:50] That is an extremely important one, just an example of incentives that can have a massive impact across an organization. Because if you're optimizing to give every engineer a project, you're literally going to have five times the work in progress that you want, because everyone needs their own special thing to get done. It's called promotion-driven development. PDD. So that's another one. Hopefully that helps.

[00:18:16] Audience: So you have three times the quality...

[00:18:20] John: Yeah. I'm not a professional anthropologist. I just play one on TV [?].

[00:18:27] Audience: I mean, during these weeks you've done all of this writing, and you've met a lot of people to understand the organization. How many meetings are you taking a day? Is this virtual? Is this in person?

[00:18:38] John: I'm doing them virtually. I think I'm pretty normal. I was doing a bunch, like six-hour blocks of 30-minute meetings at a time, for a bunch of days, talking to people across the organization. Actually, what I'm doing is the easy part, for any of you in your roles. It's the problem of what happens after the first 90 days, where people go back three years later and say, "Oh, in that first 90 days I met everyone across the company, and then I built up my big bold plan and never talked to anyone again." The proof will be in the pudding, to see if I keep connecting with those people. Especially in this async remote way, it's pretty difficult.

[00:19:19] Audience: Follow-up question: how do you plan to keep in touch with those people?

[00:19:23] John: How do I plan? Well, I just try to put the meetings in. I figure we are how we spend our time. All these companies are like, "Oh, we care about reflection," or whatever, and you're like, "Show me your calendar." "Oh yeah, every five weeks we have a 20-minute retro." I'm like, "Well, apparently I understand your priorities." Back to your question: I scrape [?] everyone's calendars, and then I look at what they prioritize based on how their calendars are set up. That's really the reality at the end of the day, how they spend their time.

[00:19:53] Oh yeah, cool. And then, I promise, let's jump into some enablement principles.

[00:20:00] Audience: You came in to do an analysis of what they currently have and try to make it better. Did you encounter opposition to change? People that didn't want to change, people that were seeing you as a counter to their work, or someone that's coming in and changing things?

[00:20:16] John: I probably haven't heard from those folks. Right now everyone at Toast is really nice. But I think that the important thing, if you join in this type of role, is that if you even go to bed at night thinking, "My job is to change this place," you're probably not going to be able to change the place. We'll get into those in some of the principles and the ways to think about it, but I think it's dangerous to think that one person will ever change something.

[00:20:46] If any of you are UX researchers... I sat sometimes as a UX researcher. If you're in that glue type of role that spans teams, you can often internalize a lot of energy to care for the org and care for the people. You become really sensitive to all the different energy, more so than any one particular team. So you have to practice a lot of self-care, which I didn't do in the past, about internalizing, "Oh my God, the early adopters came to me and they want to shake this up. It's my job to help shake it up." No, it's not. It's your job to create the environment where they can try to make the change that they want, not necessarily the John change.

[00:21:25] I'm a communist. If it were me, I would do mob programming every day. You would be at one huge monitor. There would be six researchers and seven designers on every team, and two developers. No, I'm just saying that we have to put aside our own preferences. I don't think I'm a communist; I'm more communitarian or something like that. I don't know if that helps.

Principle: happy teams, happy customers

[00:21:56] Cool. Hey, how's it going? Okay, so we jump into some of these principles. To give you some context, this is what I wrote to keep myself centered. These were not principles I shared with everyone, saying, "Oh, hey, I've got the new principles." I think I did drop something in the enablement chat and said, "Hey, if you all want to know what's on my mind as I start, these are some principles." But this was no effort to create principles for the rest of the team. I'm in this small little team at the moment. Hopefully this is helpful as you look through them. Let's go through some of them that I wanted to remind myself about every day.

[00:22:31] The first one is that I truly believe if teams are not happy, and the people working at your company are not happy, there's no way your customers can be happy. All this idea in startups of, "We're going to tough it out and run ourselves into the ground, and then somehow that will benefit our customers in the long run," just doesn't seem to work out that way in the long term. I think in the short term sometimes that works. But going in, I wanted to make sure that I never lost sight of this: if someone's passionate about coming to work, and loves what they're doing, and loves being around the people they're with, that's always going to matter.

[00:23:09] No matter what measure I have, or what I'm trying to do in the company, at the end of the day I could pin a lot of it on people being excited about coming to work, excited about being at the company, and being happy with what they're doing. And the reason why I put that first is that I think it's very easy to come in and say that, and then lose sight of it over time. You lose sight of whether people are really happy or not. Maybe you block it out a little bit. But that was the first thing I had to remind myself of when I came in.

Principle: the why before the way

[00:23:37] The second thing, which I believe extremely strongly, is this idea of the why over the way. If you are at Toast and you're growing as fast as we're growing, everything will break. In fact, the better we're doing, the faster everything will break. And once you understand this, you realize there's no fixing. There's basically controlled chaos with happy people. Now, if you get chaos with unhappy people, then you haven't really done your job. And once I internalized this... earlier in my career I would think, "Oh, I just need some calm in this particular thing." But Amplitude grew incredibly fast, this is growing fast, other companies I've been in too, and I've internalized that everything you do will break.

[00:24:26] This is why it's extremely important to explain, we could call them heuristics or principles, before you do things. As an example, let's talk about this collaboration between the R&D teams and the partner teams, like documentation. I make a point right at the beginning of every document to say, "We'll know things are working if we observe this stuff," or, "This is the why behind why we're doing these particular things." And I make a point of being as edgy as possible, just to make sure that people understand.

[00:25:01] An example of a principle there is: we're better together, but that doesn't mean we need to talk 24/7. Or I'll mention things like: leveling cognitive load is important for all of us to be happier. There's no ultimate balance in that. With each of these particular things, it's very important to lay out your principles before you start saying, "We're going to get new PRDs," or, "We're going to do this particular thing." Because then you want people to hold you to it. You want people, if in six months it's not working like the principles, to come back to you and say, "I call you on that." So this is very, very important.

Principle: self-awareness is not other-awareness

[00:25:45] The next thing, and I had to remind myself about this, was, if you've read my writing in the last six months, a huge aha moment for me. It's that we all progress up this pyramid, and we fall down in many cases. If you imagine the person who's completely clueless, who has no idea of themselves and completely lacks any self-awareness, they're down below the bottom here. So let's just assume that you're aware of your own default explanation for why things are happening. "Well, those developers are just lazy." Or, "Well, we know what happens when you join a company late and how you think about equity." They're aware of their own default explanation for the world.

[00:26:33] And then as you go up, you realize, "Well, people can take true ownership, or the true leaders do. I understand there are people who think differently. I feel sorry for them, because we know that this is the one right way." Then you get to the next level and you're like, "Well, I believe this. I believe in meritocracy and high individualism or whatever, and there are these other people who don't think the same way. I'll give them that." You still think that you're the best in the world. And then you get up to the top and you realize that there are other valuable explanations for things that are going on, and it's not about your worldview.

[00:27:11] The thing boils down to this: you can be highly self-aware but completely lack other-awareness. I'm sure you know some of these people. They're like, "I'm so fit, I've gotten in touch with myself, I go to therapy, I do this thing," and then they have no clue or awareness about what anyone else in the room is doing. You're like, you've got high agency. So why was I thinking about this? To remind myself over and over again, in this type of role, that there are other completely valid explanations for what's going on. To remind myself about, you know, the communist seven designers thing. I literally wrote this down. I have it by my desk to remind myself.

[00:28:00] Anyone have any questions on this pyramid, or have a funny story? Does anyone have one of those friends who's the most self-aware person in the world but completely lacks any awareness of other people around them? Are you married to them? Yeah, hopefully I'm not that person. So this was important as we're doing things. Thanks.

Principle: limit change in progress

[00:28:23] This is absolutely critical, and I'll be honest, it's something we're struggling with at Toast. The more well-meaning people you have, the more change you're going to spin up. And the more people with jobs to create change, the more change you're going to spin up. At the end of the day, if your job is facilitating change, you forget what it's like to be a poor product manager or a poor designer, with these people writing emails like, "Did you check out the new trampoline on floor three? It's great." Or, "Come to our new training for this." You forget how much change is leveled on the people in the organization.

[00:29:05] And I'd say for managers, or any of these roles, trying to think about how to limit that change in progress is a very, very important thing. What happens too is that when an organization has a lot of well-meaning people, this has the opportunity to spin up at an even higher rate. Everyone is trying to put change in progress and change things. You need to be very aware of that. So this was another thing that I reminded myself about.

Principle: between the eternal experiment and the big bang

[00:29:34] This is a huge issue if you're in an operational role, and something that I always forget too, but it should be design and product 101. In traditional change management, you spin up this big change project, you spend six months getting everyone aligned, and then you roll out the change and expect everyone will adopt the thing. We know from product that it doesn't work that way.

[00:30:03] The flip side of this, as Jenny will claim, is that everyone's like, "Let's just run an experiment. Let's just run an experiment with this thing." And it's the perpetual experiment. Nothing ever gets scaled. Nothing ever gets operationalized. So this is a reminder to myself to say: yes, start small, start with experiments. "Hey, do you want to try this new writing workshop that we're going to do? Do you want to try to write six-pagers?" But be ready, if things are moving, to operationalize them, to work with my different partners across the organization to make sure that happens.

[00:30:43] Does anyone have the eternal experiment problem at their company? Yeah, there you go. I love the confident hand raisers. Does anyone have the eternal big bang change management project? There we go. So reality is somewhere between those particular things, and it's important to keep that in mind.

Principle: consistency costs

[00:31:06] This is a big one, and we're going to get back to questions in a second. Hopefully this is interesting to you. There's a quote from Arlo Belshee, and he has one of the most amazing quotes. He said, "Scaling is fundamentally a question of what must remain the same, and what you're willing to spend and lose to keep it the same." Which is basically: consistency costs.

[00:31:26] Now, if you're graceful with consistency: cultural values are the cheapest consistency, but the hardest to get right in the beginning. If everyone in your company respects the customer without having to say "respect the customer," and without a million different process hoops to respect the customer, you have consistency at a really low cost. However, how many things in people's companies have consistency, but at a really terrible cost? "You must go through the PMO," sorry to my program management friends, "you shall go through the PMO, and you will use the system, and you'll update the thing." You could do that heavyweight consistency, and it could potentially slow things down.

[00:32:09] So this is a reminder to myself that whenever someone says, "Wouldn't it be just great if it was all the same?", I really have to question that as an instinct. Because if you don't, and you're growing as fast as we're growing, you run particular risks. But here's the flip side of that. Who's our UX researcher or design researcher? Do we have any design folks? Okay. Any glue role hates this. Anyone who has to move between different teams finds this incredibly difficult, because they're going to go to each team, and the teams are going to work in a bunch of different ways. So you have to be nice to them. You basically have to buy them pizza.

Principle: graceful simplicity

[00:32:53] This is something that I realized just in the last year. I was the type of person that, when people would say, "We just need to keep it simple," oh my God, I hated that. There was something in my mind that was just like, it doesn't seem like we need to keep it simple. But then I started to form my ideas in this particular area, and I think it makes some sense. There are some oversimplified solutions in your company that sap the creativity and the complexity out of the room. It's simple at the expense of emergence. It's simple at the expense of creative complexity.

[00:33:30] There's this guy Ashby, and Ashby's law basically says you need to match the complexity of the system that addresses the problem to the complexity of the problem. That's why a really small creative product team can do amazingly interesting things. Even though it's small and simple, a small team is capable of a lot of complex behavior, and matches those things.

[00:33:54] The thing that I learned when I did this is that you have to seek graceful consistency. Do you notice the similarity with the comment about consistency? You have to seek graceful simplicity, which is similar to graceful centralization. An example of that might be, "Hey, there are only five things in the world: work, goals, measures, or whatever." That's very simple, but every team can adapt it in interesting, creative ways to achieve what they want. This is a more advanced thing. Does anyone have any questions about what this means? Which is: don't oversimplify problems for the sake of simplicity. Consider these graceful simple solutions that might allow people to still be creative in their work.

Leveling cognitive load

[00:34:46] Host: There's a question online from Jade. She's asked, "Can you explain leveling cognitive load a bit more?"

[00:34:54] John: Oh, absolutely. We obviously experience this at Toast too. On the cognitive load thing, there are two people, Matthew Skelton and Manuel Pais, who wrote this book called Team Topologies. It's an incredible book. Their theory is that the rate limiter for any organizational design question is cognitive load: people can only process so much stuff happening before they break down. If you ever notice, when you're in an organization and people say, "We want transparency," and then you get transparency, and it's like, "Shit, I don't want transparency anymore. Make that go away." What that is, is that you've hit that point of cognitive load.

[00:35:32] The way you know your cognitive load is too high is you feel like you're playing three-dimensional chess at work, with problems that you just can't figure out. You're having a lot of repetitive conversations over and over again. You leave meetings and everyone's just too drained to come up with action items. A very good symptom is you find yourself taking long sets of notes for every meeting, with action items that all just go away. You can't figure it out. It's similar maybe to when you're in a difficult or challenging or dysfunctional relationship: you just feel like you're at the max limit all the time. And their theory is that's a signal that your org design is off, that something is not working appropriately.

[00:36:14] What I have noticed, though, is what happens in a lot of companies: they say, "We want independent, empowered teams." Great. But then there's this whole group of designers and other people, and they're like, "But you work with eight teams at once. Well, you're going to take all the overhead of the cognitive load, so that these teams can be rockstar teams." So that's the idea of cognitive load.

[00:36:37] The signal that I would give to people is: when you feel that three-dimensional chess, where you just can't figure it out, for more than a week or two or three, it's usually a good signal that something has to change. The problem is that when you're in high cognitive load situations, you make worse decisions. And then you make worse decisions about the cognitive load, which makes the cognitive load worse. And then you start dealing with the cognitive load by going home and having a couple of beers, or by saying, "I just want everyone to shut up. Just give me a project. I'm going to do it." So we have coping mechanisms for high cognitive load that often don't even land us in a good spot. That's the whole thing about cognitive load. We need to tame cognitive load in our environments, otherwise we can't think straight.

Principle: trust is an output, not an input

[00:37:25] These are very good things. Let's jump through. Trust is a huge force multiplier, but you can't tell teams to trust each other. I made a t-shirt of this. Does anyone have the red t-shirt? Someone? GitPrime made a thousand of those t-shirts and gave them out for me one time, which was funny. Good marketing for them.

[00:37:53] You think about trust, and it's like, just do it. But what I've come to understand about trust is that you obviously can't tell teams to trust each other. Trust is an output, not an input. The inputs into trust are things like promises regularly kept: keeping cognitive load to the point where you can follow up on the things that you said you're going to do. Has anyone worked in an environment, at some point in their career, where 70% of the things that people say they're going to do, they just don't get around to? But everyone's so maxed out in the company anyway that you give people permission to drop every ball, because you drop every ball. What does that do to the trust level? You don't blame people. Oh, am I on Roto-Rooter? You don't blame them, because you're overloaded too.

[00:38:36] That's an example of where reliability drops to the point where it's very difficult to get trust going. The reason why I mention this, and why I kept it as a principle for what I'm doing, is that you could think of product enablement as creating environments where trust can emerge, and then joy can emerge, and happy teams can emerge, and different things can emerge from that. So it's a very interesting idea.

[00:39:00] This trust formula is so interesting. If you're a PM, here's where PMs go wrong: self-orientation. Man, there's something about PMs sometimes where you're just in it for you. I don't think design... yeah, we all have our issues in the trust formula. But it's a very helpful thing when diagnosing what's going on in your team. Is self-orientation too high? Or do we have so much work in progress that we can't actually deliver anything, so no one thinks anything's going to happen? That's reliability being low. Are we newly remote and async, trying to email each other at all hours of the night because we're in seven different countries and can't meet? That's intimacy.

[00:39:42] "The new management team, ah, they're a bunch of top-notch consultant types who don't care about our business." That's credibility. You can just keep going through this. "Oh, systems keep breaking, quality's really low." Reliability. "I said something was wrong but no one got back to me." Intimacy. "That team's just in it for themselves." Self-orientation.

[00:40:03] A real-world example with my particular role, and this is hard to unpack: our PMs are so busy sometimes. They want to do well, but they just don't get back to someone in time, which becomes a little bit of a reliability thing. So I have to help: "How can I improve tooling so that you're not so overloaded, so you can get back to people and rebuild trust?"

Principle: think big, work small

[00:40:28] And the last one before we do questions. This one is so important no matter what role you have, but especially in the particular role that I have at the moment: the think big, work small idea. There are lots of teams that work small. "Ah, we're agile." But they're just going in circles. It's just dumb. And then think big: "This is the big new plan." Eight months later, we're still working on it. That's think big without the work small.

[00:41:01] Even in these product enablement roles, it's this idea that strategy is thinking across multiple horizons. My role is to create an environment where teams can build trust by working small and moving things forward. But also, when we are going to enter our annual planning cycle in a couple of months, I need to make sure I leave room for those teams to think big. Not just in terms of the efforts or projects or features they want to do, but so they can really think big: three-year plans, three-year strategies. So hopefully this was interesting, hearing a couple of principles from someone who comes into a role like this. I'd be happy to answer any other questions that folks have.

Q&A: team principles and templates

[00:41:43] Audience: I really appreciate you coming out. In the beginning you mentioned things that you think every team should have, like a team charter and so on.

[00:42:03] John: Yeah.

[00:42:04] Audience: I feel like the team charter is a good place for a team to say, "Hey, these are our principles." What that leads to is: if I'm a PM starting a new initiative, or I just joined the team, how do I come up with these principles?

[00:42:19] John: Yeah, that's a great question. Well, what do we know will not work? The classic PM move of, "I had a meeting with my boss and they asked me to write a couple of principles, so I just whipped them up. What do you guys think? I've already shown the CPO." That does not work.

[00:42:38] A really good activity is not overloading the situation. This is a really simple technique, but you can do it: two columns. "We prefer this over this." Very basic. It forces you to think about a good dichotomy. It'd be one thing if you just said "we prefer," because then they'll say, "We prefer everything." But just adding that other column that says "over"... whatever the strategy of the team is. I think that's a good method. You might just want to do an activity with the team to get that language going. I think it'd be a good start.

[00:43:18] Audience: Quick follow-up, then I'll give up the mic. Do you have any templates?

[00:43:23] John: No, I don't do templates. Except internally. I'm just kidding. No, I mean, yeah, you can contact me and I'll give you some. I've been feeling really worried about frameworks and stuff lately, because I think there's a whole generation of PMs who think their job is to actually complete these fill-in-the-blank diagrams that have been created by people like me. And the net effect of that is... these diagrams were meant more as teaching tools: "Hey, if you're in this situation, maybe consider filling in these blanks." And then there's a whole generation of people doing product now who are like, "Did you see that new eight-box strategy canvas?" And the first box is, "Our strategy is to win." It's like, let's start here. So I've been a little bit worried about templates and frameworks recently, but I have some up my sleeve for rare situations, in case you need them.

Q&A: graceful consistency

[00:44:19] Audience: Hey John. Thanks for the talk, first of all, very insightful. You made an interesting point around graceful standardization, I believe you called it. I was wondering if you can expand a little bit on that. How do you find the right balance between standardization and decentralization, or proliferation of services? What signals do you look out for when you've gone too far in one direction versus another?

[00:44:44] John: Oh yeah, to challenge the consistency thing. This is more of a heuristic to challenge it. Let me expand on this a little bit. It's to push the idea of graceful consistency. Here's the most amazing example I've heard of it. Remember when Google did the flat redesign? Remember Google products, where all the apps had different buttons? Literally, you'd go into Docs, Sheets or whatever, and you could see different design systems.

[00:45:14] The way they solved that problem was so unique. First of all, I think it was Sundar, whoever was the CEO, who said, "I don't like that. That's got to change." So that's the top-level CEO saying, "I want it to change. It's going to change." And the second thing is, instead of, frankly, what we did at Zendesk, which was, "Put on the brakes, global redesign, everyone," they said, "Well, let's just hire two researchers, and they're going to form a research library. You can submit your design research, or you can take research out." And over two years they got complete consistency between all the Google Suite products, with two researchers, in a basically decentralized way. Consistency at a much lower cost, in a much more graceful way.

[00:45:59] Another example: "Everyone in the company is going to use this PRD, because everyone's going to have to." The junior people are just going to fill it out. The experienced people are going to fill it out and then just have another one anyway. It's not going to lead to altogether great things. But how could you get graceful consistency? One thing we're considering at Toast is to have almost an approved template library, where I will do training, or Jenny will do training, or Jonathan, who is here, will do training: "Look, if you're new and you want to get really well enabled on a set of writing, with a bunch of examples and a whole directory across the org of using these particular frameworks, use it. But if you want to freestyle, here are the things it must do. It must satisfy these 10 requirements." My guess is a lot of people just go to the template library. So again, it's graceful consistency. And for anyone dealing with annual planning, all that kind of stuff: a lot of those things just smack of not-so-graceful consistency.

Q&A: keeping product managers happy

[00:47:03] Audience: Hey. Oh, sorry. What would be your experience, going back to point one about happy teams making happier customers: what would your experience be of building a community of practice to keep the product managers happy at a company?

[00:47:25] John: Oh yeah. One thing that I would do with happiness... I would say it ranges from purely transactional stuff, like just reducing the amount of duplicate stuff. I would literally go to PMs, and it's kind of what I'm doing right now: "When have you had to say the same thing more than once this week, and it was not valuable to you?" That's good. Let's start there. That's not going to make you very happy. Another thing is, where do you wish you had better contact with customers, but it's too difficult, too hard to arrange? Product managers thrive on connecting with customers, so that's going to make them happy.

[00:48:02] The next thing would be something like... we have some programs at Toast that are really cool. We actually have a nonprofit foundation within Toast where people can cycle in and do work. I haven't seen people so happy as when I was on this call, and they're trying to solve the food waste problem, because we have such a network around the world to do this. I'm on that call doing a North Star workshop with them, and they're just so grateful. Our North Star is going to be megatons of food waste solved. So having opportunities for people to cycle into those within your company, either nonprofit opportunities or other things. I think we have Impact Week coming up in a couple of weeks, where people can pick one of four different areas to have impact. Those are just some examples. But you have to do UX research. You have to do the anthropology to figure out why they might not be happy. Sometimes it's money.

Q&A: when simplicity is the right medicine

[00:49:06] Audience: I can go now. Hey. When you spoke about cognitive load, you essentially had a rubric for when it's getting too high.

[00:49:20] John: Yeah.

[00:49:21] Audience: I'm more interested in what you had to say about simplicity, and how it's perhaps used and abused. Is there a similar framework in your mind for when simplicity is the right medicine versus when complexity is the right answer?

[00:49:39] John: Yeah, so let me give you an example of this. A team decides to create an enabling constraint to ship something in six weeks. They don't do that because the customer is saying so or whatever. They just say, "We're going to create this enabling constraint to ship something in six weeks." It's actually a ridiculously simple thing to do. But we can tell that the simplicity is an enabling constraint in a complex system, to get amazing creativity to happen.

[00:50:13] The difference, though: on a team, let's say someone says, "Your deadline's in six weeks." You notice that the team isn't creative, they don't really enjoy it. But let's say the team opts into that time box and says, "We're going to create an enabling constraint here." You'll notice more creativity. You'll be in meetings where someone will say, "Yeah, but six weeks... Ah, I've got it. I found the wedge in this problem. We're going to do this." You'll start to notice the problem cracking open.

[00:50:41] So I think this complexity-simplicity thing gets a little bit confusing, where you can have something that appears very simple on the outside, like an enabling constraint, and it promotes that level of complexity. My classic example of oversimplification is this. The CEO says, "There are four pillars we're going to pursue this year." "Just four?" "I didn't include the business as usual." So there are really 12. And then someone will say, "And that one pillar has 72 top-priority P0s, right?" And they're like, "Yes, that one too. But we have to keep it simple, because we're doing the kickoff and the sales team needs to be excited about what we're doing."

[00:51:23] No one's ever been in that position before. Usually, if you're in product, you're like, "Yeah, yeah, yeah, I just have to go back to... oh my God, these theatrics." You just find a way. What do we notice about that? Creativity's going down. There's no coherence with reality, with what's happening. It feels like simplicity theater. They're totally disregarding the business-as-usual stuff. They're even calling it business as usual, which is so demeaning in some sense. That whole thing, "run the business," RTB. What? It's as if running the business is a second-class citizen. "You will grow the business. You will run the business. You will be CAPEX. You will be OPEX." Those are examples of very simple: "It's either CAPEX or OPEX. Just count your hours." And you can just feel it taking the life out of the room as you're doing it. So that's how you know, generally.

Q&A: measuring principles

[00:52:22] Audience: Hi, thanks for sharing your work. It's really interesting. Once you have these new principles in place, how do you measure their effectiveness?

[00:52:32] John: Sorry?

[00:52:32] Audience: How do you measure their effectiveness?

[00:52:35] John: Well, that's going to be boiled into different goals like this. We were actually chatting before about measurement related to some of these things. I think there's this quantification fetish that I don't think is helping everything that we do. One example of this is when there are 75 different NPS surveys for every internal service there is. First of all, NPS is a flawed metric. So why are you sending it to 75 people in your company? It has three times the margin of error, and it hasn't been proven to produce revenue in three out of five of the industries where they use it. So there's something wrong with NPS. But that aside, it's okay for some things to just be okay and good.

[00:53:21] So I think these are goals. And the cool thing about this is I have to come up with a release confidence score. That's going to be great. Measurement itself is an experiment. A lot of people miss that. They'll argue for six months: "I don't think we can measure that." If you've read the book How to Measure Anything: Finding the Value of Intangibles in Business, you can always measure it. But there are formative and summative measurements, or evaluative measurements. You're not always going to find the perfect evaluative measurement, but in terms of decision support, usually you can measure something at just the right level that will help you redirect.

[00:53:59] So I think one of the important things is that the principles will manifest in these activities. These will be measured, and you're going to be held accountable to these particular goals. And then I think it's also asking people for harsh feedback: "Am I living up to these principles that I have?" Find a good friend to do that one. Obviously you don't want to ask your manager for that all the time.

Q&A: product-led with a growing PMO

[00:54:24] Host: We have another online question, from Margaret: "I'm working in a paradox where a company wants to be more product-led but has a growing PMO function that's enforcing consistency. How would you help the company and the product manager navigate through that?"

[00:54:43] John: Well, PMO function. Is that program or project management? You can check with her. It's all the same anyway. Portfolio. I have a great friend, Evan, who was at Pivotal Cloud Foundry before the acquisition by VMware. Man, Evan really stepped up the program management function at PCF, to think about it as the lightest-touch force multiplier. He said, "We're successful when people don't know we're there. We're holding the thinnest amount of consistency between these efforts to enable aligned autonomy. We're not getting our job done when we're acting as the human load balancer." Back to the earlier question: when program managers are acting as the human load balancer between all these dependencies, it's incredibly difficult on the PMO.

[00:55:45] First of all, they're doing an incredible job. Any of these organizations that say, "We're just going to be product-led," when meanwhile they have all these dependencies they're asking the PMO to manage: it's so unfair to the PMO to say we're going to get rid of program managers. But I think any person from a program management function I talk to aspires to that strategic version. They just haven't had the opportunity to do it. So I'd say it's about creating an environment where program management can do that.

[00:56:11] Another thing that I think about a lot at Toast, and I didn't include this particular principle here, is that you will occasionally have big cross-cutting projects across your company, and you'll be so grateful that you've got a PMO and other people to do them. That's when their magic can shine. So another part of it is allowing those folks to work on the most strategic cross-cutting efforts, where you need every i dotted and every t crossed, where all of those incredible skills that they have can shine. Versus, "Well, you say story points are this..." Oh my God, it's going to eat their soul.

[00:56:51] So that's what I would say: it's about enabling the PMO to take on this more strategic function, and then, like Evan, the light touch. It's almost, in a sense, like my role. You could imagine a really evolved PMO, allowed to do all these kinds of efforts, starting to border on product ops and product enablement. However, you also see situations where they've created a product ops function that's basically the ex-PMO, and it's all fallen back in on itself. So that's what I would say.

Q&A: think big, work small, and budgets

[00:57:23] Audience: Hi, John.

[00:57:24] John: Hey.

[00:57:24] Audience: I want to go back to the think big and...

[00:57:28] John: Oh, think big, work small. Yeah. It's pithy. It's one of those thought leader things. Okay.

[00:57:34] Audience: This is a good one, because what I've seen happening time and time again is that at the start of the year, everyone is quite energetic. They want to put money on the problem. One million dollars, two million dollars, ask and you have it.

[00:57:48] John: The meetings cost two million dollars for us. Yeah.

[00:57:49] Audience: So after two quarters, the budget is cut in half. How do you manage that constant prioritization?

[00:57:56] John: It's like think big, work small, pay smaller. Budget small. Well, I think my first answer would be that it's a show-not-tell thing. A company can use these words, but until you've had a team that you've created the runway for... oh, okay, I have the way to answer this. If product does not come up with a governance model for how it works, someone else will come up with the governance model for how it works. Meaning that if you're going to take a big swing, and you can't tell me how you will pivot or proceed, and keep really strong purse strings on the budget that you have, you're just outsourcing to finance to come up with some crazy-ass budgeting for it.

[00:58:39] This gets to the role of budgeting and annual budgeting. It's the power vacuum. It's, "Get your projects up here, the money's on the table, line them up." It's November, and by the time December hits, everyone's soul is so broken that it's just, "Just ship it." Then everyone finally gets working by March, but by July everyone's tired and the priorities have changed. But they're like, "Well, we'd better not change it, because annual planning is starting." We all know that's messed up.

[00:59:07] So I think the idea here is that it's the role of a product leader or product manager to come up with a sound budgeting and financial picture. If you want to be funded like a startup, you need to offer that model to the organization. If you want to be funded in rounds, you need to say, "We're going to achieve these goals, and we're going to get our next round." Craig Daniel, who's my boss, has been very good at that at Toast. We've killed a lot of bets in his particular area, because he holds himself to the budgeting model. When you do that, I think you get rid of that "money is imaginary; of course we'll bet on it for a quarter," and then everyone runs out of conviction.

[00:59:51] You have to come up with a sound economic model, and you can't outsource it to finance, and you can't outsource it to other people. And then you have to do it in conjunction with your engineering counterpart. If you can do that, and then consistently make progress, pivot out, make progress and have wins, then the organization in total starts to trust that model more and more.

Q&A: failures and getting buy-in on the ground

[01:00:18] Audience: Hey, John. Back to measuring the success of a process: was there anything recently that didn't work well for you, from a growth perspective, or something that failed? And how did you bounce back from it, from any product enablement process at Toast or somewhere else?

[01:00:34] John: Oh, well, obviously there's confidentiality. Let me try to talk about it in the abstract. Actually, let's skip that, just because we're a public company now, so I won't. Maybe I'll write a post and you can decode it. Even worse.

[01:00:52] Audience: No worries.

[01:00:53] John: Do you have another question, though? I'm sorry to softball that.

[01:00:55] Audience: Yeah, I also had one more. You spoke about convincing the CTO or CPO about the enablement process, but also getting the buy-in from people who are on the ground level. It's not very easy. When you try to enable a process, how do you tackle that, and those pushbacks?

[01:01:11] John: Yeah, actually, I have some co-workers that I've already started to bug for this enablement thing. What I've been reminding people is that it needs to be win-win. Let me give you the exact example with this, and then maybe we'll talk about it. If you say to all the product managers, "Hey, we're going to slow you down. We're going to force you to work with a bunch of people you haven't worked with before, and you're not going to see any of the benefits, and we're going to push back all your deadlines, and it's going to be great," that's not going to go over so well.

[01:01:40] But if you say, "Hey, I realize that past efforts to rein this in have just made more work for you. We haven't followed up on our commitment to you to reduce the amount of duplicate stuff. I have a metric; I'd love to make that one of my goals." If you think about this, back to the goals: do you see how it's all crafted to be win-win? The improved visibility and situational awareness is for the partners, because they're not seeing the roadmaps carefully at the moment. Improve release confidence and release satisfaction: generally, everyone will be happy. What PM doesn't want to be highly confident that their feature has the right documentation, that sales is going to sell it appropriately? That's win-win. That's going to be great. And then build a continuous improvement muscle is there to give everyone, the PMs too, the sense that we're going to hold ourselves accountable to always be moving the needle and improving. So you just have to create win-win situations, I think.

[01:02:49] Audience: Amazing. Thank you.

Q&A: the messy middle between big and small

[01:02:51] John: Yeah, keep them coming.

[01:02:54] Audience: Thanks, John, for your talk. I'm coming from the think big, work small principle. Sometimes it's not very easy to quantify tasks and put estimates on them, because we all drive for happy customers. In order to make the customers happy, we should follow the landscape of the market, and it changes very rapidly. So sometimes what we think is a solution from a short-term perspective doesn't work for a long time. What would the pivot model be in that scenario?

[01:03:24] John: Yeah, I think what that's getting at, too, is this idea that product success is always a layer cake of decisions. I think it was Jeff Bezos or someone who said your success now is the sum total of all the decisions you've made in the last three years leading up to where you are today. And I think the answer to that, and I can even go to the slide, is trees. You have to build awareness in your company that there are inputs and leading indicators that you believe have a causal relationship to long-term, sustainable, differentiated growth.

[01:03:56] The stuff I did at Amplitude around the North Star framework: you should read that book that I wrote when I was there, because the magic of the North Star framework was that it solved the messy middle problem. There are different problems. In think big, you only know long-term success and nothing else. In work small, you only have inputs. So everyone's like, "We're autonomous. We don't know how it's contributing to the big picture, but we're autonomous." And then you get the messy middle problem when you have those teams saying, "We're autonomous," and you have the big picture, but nothing connects them. It's this line of inputs right there.

[01:04:33] I'll give you a practical example. We are implementing something called HEART, and HEART is a Google framework for UX. You have happiness, and you can go down these things; retention is one of them. The conversation I had with that team recently is that we've got to be careful to mention what our actionable inputs are and what our long-term drivers are. Otherwise, we get caught in this really flat problem, where UX folks don't feel they can impact the inputs, and then we're not selling enough why HEART is driving long-term retention and business results. What we're basically saying is we need a little bit more of a graph and a model, versus just a flat metrics framework.

Q&A: change management for acquisitions

[01:05:16] Host: Okay, last question.

[01:05:17] John: Jeez, we could spend all night. This is fun. I have to go to this dinner in two... Oh, no, I'm good. I have a lot of time.

[01:05:26] Audience: Hi, sorry, I didn't think I was going to get this. Thanks for the talk, John; excellent so far. Do you have any experience of, or advice in relation to, change management for acquisitions?

[01:05:40] John: Oh. Ouch. Ooh. Ah. Let's get at this a couple of different ways. Does everyone know about the Expedia problem? Expedia bought all these companies and said, "It's going to be great. We're going to have one platform and it's all going to be good." And they found out that doesn't work, and they ended up splitting all the companies back up. So first off, and this is not so much advice as commentary: people have wildly unreasonable expectations around acquisitions all the time, where they imagine there will be all these economies of scale and synergies. And then three years later, it's just economies of crap. So you have to be careful.

[01:06:26] But assuming that you've made the decisions not to make that happen, one bit of advice is that it can take years to assimilate these teams, and I think that's completely fine. In fact, things need to work themselves out. Sometimes people in the acquired company actually like the company, and want to become more, let's say, Toast-like. Sometimes you find the people in the acquired company who were never going to stay anyway, and one year later they're out. They never wanted to be in another company. They wanted the money, or whatever they were going to get. And then you get other things where people from Toast, for instance, really love that other culture. You get all these interesting things happening.

[01:07:17] So I'd say the number one factor, driven by the economies of crap problem, is that if there's a lot hinging on the deal in terms of cost savings or all these particular things, it causes a premature convergence of those companies coming together. Someone says, "We might as well rip the band-aid off and expect everyone to get along." And the net effect of that damage is that people say, "Yeah, it's okay, we've got it," but for the next two years everyone resents it. That's my experience. So yeah, M&A and all that stuff is tough. We could talk all night about these things.