Product Enablement Principles

Thank you so much for being here. Second time in Dublin. First time was 2019 at a conference, and now the first time I'm coming to my office, so that's exciting.
Anyone from Toast, we'll chat tomorrow. Be fun to meet you. Those who I haven't met on Zoom already, so that's good.
And those who are visiting us from other companies, thank you so much. Let's jump in. 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? Product Enablement.
All right, so we'll do. 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.
There's a seat there for you. Let's get started. So what I wanted to do before we jump in at all is just literally show you the snapshot of my last 48 hours before I left.
So you could think Monday and then Friday, what someone with the Product enablement title was doing at a company like Toast. So I wonder if I can do you think I can laser pointer? Hold on 1 second. No? Okay, good.
I know that that feature is not available. I'm just going to share a joke. My partner and I, we 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. So 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.
And also 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 kind of what my job was in this. So you can see in the middle, you can imagine that this is your product team engineer, 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.
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. So why was I doing this? I was having a conversation about what is the right model for engagement, given different types of work.
So, for example, who loves the folks doing documentation at your everyone loves the documentation. No, we don't have like, oh, yeah, okay, we got a documentation person doing things. So you can imagine that often things like documentation and technical enablement, or teaching our own customer success folks how to be able to support the features we have, or teaching sales how to be able 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 be able to help you do that thing.
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.
So this is one example of what I'm doing. So basically thinking about how product managers can more effectively collaborate with people across our company. I don't know.
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 like a thousand different tools to let people know what's going on. So this was part of an effort to say, well, could I support you with better platforms? That would be a little bit more of a product ops type thing to make that easier.
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. So it's about 30,000 to 40,000 words of I kind of went a little crazy with this, but I'm basically documenting ways of working and then comparing it to maybe other ways of working in the industry and then making sure that I have this ready as we start to evolve what we're doing. So at the scale, I don't know the scale of your all's company, but once you start to get to 500,000 people, there's no one way in your company.
There's literally layers of ways to do that. And with more and more people being async more and more people working remote, it becomes increasingly important to at least have any shared language. So you can notice right there, there are six core things teams, capabilities, models, goals, bets and measures.
Like, 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 audacious goals, what are those back? Yeah, that's one of the ones I don't like saying like five times. What are they all? They're goals at the end of the day, so we should call them goals. So a lot of what Product enablement done is basically information architecture.
It's just thinking about can we use the same language at the scale we're working at? 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, scaling as fast as toast we want to and 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 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 so you can see here I hear the 14 things that every team needs a mission, a vision, a team scope, a charter working agreement, 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 twelve 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 to do these things. 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 more, even more. What's the next thing? Oh yeah, what did I do this morning? I worked with our internal product teams or 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 would you apply product principles if you were like an internal platform to move data around or maybe security or identity resolution or any number of those things.
So you can imagine this is that me saying 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. So 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, getting triggering discussions, challenging these particular things. So that's another role that product enablement might do. Well, let me ask you this question.
Who at your company writes out these principles in general? Is it like the CPO or something? Or 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.
So we're trying to get these like opinionated principles to help that particular group. So it tends to help to have a subject matter expert. So my years at Amplitude paid off in this thing, what else am I doing? I did a workshop for that team.
Here's the five principles. And we went through and we did a nice workshop and we did this. This was today.
Today has been a long day already to do this stuff. This was very exciting, talking to them about what it means to run products and do all this stuff and they were very grateful. And so 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 bad, they're pretty grateful that anyone is trying to help them.
So this was a good moment. Finally, 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.
So I talked about how do we get partners and product teams to collaborate together effectively? It's literally my Okr stack high quality and high confidence release enablement process that drives customer trust and fosters strong partnerships between partner teams and R and D teams. So you notice how I frame that too. I could have framed it like efficiency or effectiveness.
So what I'm doing is talking. The key part of that is the partnership as we're working to the teams. And then you can see it's like in a sense that in product enablement you have a product.
So I have just like a product manager who are there, 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 day. So it's very similar to products. So 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 like a viable career option.
You get to be like a professional product nerd all day, which is really really fun. So that's another example. Here's the writing.
Yeah, that's long. Yeah, so it's going to be fun. Oh, it's duplicated, but it is legitimately.
That long. You see the second and third one are the same image, but you get those things with that. Any questions before we dig into the things? I could give you maybe a more formal definition of product ops and product name before we get going or does anyone have any questions about the two days in a life? Yeah, we'll do.
Lots of questions later. It'll be fun. And then have your drinks and stuff.
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? I don't agree with that value. But you've released that out to the entire team. Well, I show it to them.
I mean, if they don't believe in it, it's lights out, right? So a lot of it is Steve for Debt, as a founder, I have to show him these principles. And what do you think of that and CTO, Deborah? And what do you think of that big shift in my role from Amplitude, where I was helping other companies a lot with this? You really do have to kind of work these things through the process and be open to people having opinions and perspectives on those particular things. I tend to think with principles, they're either the most bullshit 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. And we have layers and layers of principles. Like the people who've been here longer from Toast knows we have the Toast Company principles.
And that was just a little snippet of principles for a particular team. And 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 customer centric? The key with principles is actually making people think. And also the same thing with strategy.
I would make that point. Someone from Netflix, a friend of mine was at Netflix for a long time and they had this strategy, one line strategy that was beautiful. It's be HBO before HBO is Netflix.
And it really makes you think versus these pretty bland be the best in SMS. That doesn't tell you very much to do those things. I don't know if that answers your question, but you need to search, I would say for any of you too who are like the kind of one other thing to realize principles.
Some people don't give a about principles and you have to not be down on those people. Like some people just think. It's kind of an 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 not for everyone to do that stuff.
Yeah. Let's just jump into questions. Let's do so I just showed you a little bit of stuff.
We could go to this slide. So John, as you said, this is a lot of writing. Yeah.
So how to make sure that this writing works? This written down stuff works. People read it and it's actionable and they refer to it. Oh, I'm never going to show that to them.
No. I think that I've come to the conclusion that I worked for this CEO, his name was Scott Kernett, and we had this pretty audacious startup that I worked at his startup and he was the kind of like, if you can't say it in a tweet, don't say it at all kind of things. 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, they don't bother with doing it in 30,000 words. I tend to write this and then maybe a couple of the nerd, like most of the people at Toast don't know that I've written this, but then I find I look at the View history and I'm like, oh, I found a fellow nerd here that I can do to do those things.
Like, someone wrote me the other day over Slack. Like, I read the document. Okay, yeah, you can't expect 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 like 15 different ways as well. And some people are just super skeptical to do it.
I find writing helps my thinking straight, so I've practiced writing. Cool. All right.
Anyone? Okay, maybe oh, yeah, go ahead. It's funny we'll just do this today, but we don't need to get the principles. It's more around where do you start? You just described the two days that you just did, but when you come into this new role, I think you said eight weeks you've been where did you begin? This seems like the product of a lot of analysis.
Oh, it was, yeah. Well, I think that in this role you can do a certain amount of organizational anthropology. And so the things that I look for specifically are where power lies, how power is exchanged between people, where there's incoherence between words and action.
I used to be really 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 also 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. So observing, doing a lot of reading, kind of seeing how people communicate. And I make a point to how does change actually happen? So 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 then only then we get it done. You're not going to come in with like quick change at that particular point. So that's what I look for.
Power things, relationships between people. And also another big one is just how our team is really incentivized. A classic one.
Like in the Bay Area, there's 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 the number of projects, you move ahead. In non Bay Area, there's sometimes more communitarian countries and companies where there's more of a team identity and the team is thinking about moving ahead. The thing forward, that is an extremely important 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. Very like, it's called promotion driven development.
It's PDD to do those things. So that's another one. Hopefully that helps.
Yeah, I'm not a professional anthropologist. I just play one. Sure.
During the week weeks you've done all of this writing, 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? I'm doing them virtually, yeah. I'm pretty normal.
I think at Toast I was doing a bunch like six hour blocks of 30 minutes meetings at a time for a bunch of days, talking to people across the organization. Actually, what I'm doing is the easy part, I think, if 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 they say that 1st 90 days I met everyone across the company and then I built up my big bold plan and then 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. Follow up question how do you plan to keep in touch with those people? How do you plan? Well, I just try to put the meetings in.
I figure we are how we spend our time. So all these companies that are like, oh, we care about reflection or whatever, and you're like, Show me your calendar. It's like, oh yeah, every five weeks we have a 20 minutes retro.
I'm like, well, apparently I understand your priorities. Back to your question. I scrape everyone's calendars and then I look through what they prioritize based on how their calendars are set up, and that's really the reality at the end of the day, how they spend their time.
Oh, yeah, cool. And then let's promise, let's jump into some enablement principles. So you came to do an analysis of what they currently have and try to make it better.
Did you encounter change opposition, people that didn't want to change, people that were seeing you as a counterfactor of their work, or someone that I probably haven't heard from those folks. So right now, everyone at Toast is really nice to do those things. 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 and 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 if any of you are UX researchers. So I said sometime as UX researcher, and if you're in that glue type of role that spans teams, you can often internalize a lot of energy to kind of care for the 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, like, 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 for those things. 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 John change. I'm a communist.
If it were me, it would be, like, six people. I would do mob programming every day. You'd be in one huge monitor.
There would be, like, six researchers and, like, seven designers on every team. Two developers? No, I'm just saying that we have to put aside our own. I don't think I'm more like communitarian or something like that.
I don't know if that helps. Cool. Hey, how's it going? Okay, so we jump into some of these principles.
So to give you some context on these things, 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 these were no effort to create principles for the rest of the team.
I'm in this small little team at the moment, so hopefully this is helpful as you look through them. So let's go through some of them that I wanted to remind myself every day about 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. And all this idea in startups of like 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 in a particular thing. But going in, I wanted to make sure that I realized I never lost sight of. If someone's passionate about coming to work and loves what they're doing and loves being around at the people they're in, that's always going to so 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 it a lot 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 put that first is that I think it's very easy. You can come in and say that and you kind of lose sight of that over time.
You lose sight of whether people are really happy or not. Maybe you block a little bit out, but that was the first thing I had to remind myself to do when I come in. The second thing which I believe extremely strongly about is this idea over the why versus the way.
So if you are a toast and you're going 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 particular job. And once I internalize this versus earlier in my career, I would think, oh, I would just need some calm in this particular thing.
But one amplitude grew really incredibly fast. This is growing fast. Other companies I've been in, I've kind of internalized that everything you do will break.
And this is why it's extremely important to explain. We could call them heuristics or principles before you do them. So as an example, let's just talk about this collaboration between the teams like the R and D teams and the partner teams, like documentation.
I make a point right in the beginning of every document to say we will observe things are working like 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 that. And so an example, there will be in 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 maintain leveling cognitive load is important for all of us to be happier to do that.
So there's no ultimate balance in that. And so with each of these particular things, it's very important to lay out your principles before you start saying, well, we're going to get a new PRDS or we're going to do this particular thing. Because then you want people to hold you to it.
You want people within six months it's not working. Like the principles, they'll come back to you and say, I call bullshit on that and that we're going to be able to do it. So this is very important.
The next thing, and I had to remind myself about this is this is in the last six months. If you read my writing, this was like a huge AHA moment for me, which is that we all progress up this pyramid and we fall down in many cases. So if you imagine the person who's completely clueless, they have no idea of themselves, they completely lack any self awareness.
It's like down below the bottom here. So let's just assume that you are 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. And then as you go up, you realize you're like, well, people who can take true ownership are the true leaders. I understand there's people who think differently.
I feel sorry for them because we know that this is the one right way. Then you get to that next level and you're like, well, I believe this. I believe in meritocracy and high individualism or whatever.
And there's these other people who don't think the same way. Yeah, 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.
So the thing boils down to you can be highly self aware, but lack complete other awareness. And 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 got high agency when that happens.
And why was I thinking about this? To just remind myself over and over and over again in this type of role that there are other completely valid explanations for what are going on. Remind myself that I'm like the communist seven designer thing. And just try to reiterate I literally wrote this down.
I have it by my desk to remind myself to those things. Anyone have any questions on this pyramid? Or have a funny story? Like does anyone have one of those. Friends who's like the most self aware person in the world, but they completely lack any awareness of other people around them.
Are you married to them? Maybe. Hopefully I'm not that person. So this is important as we're doing things, this is absolutely critical and I'll be honest, is something we're struggling with at Toast, which is 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. And at the end of the day, if your job is like facilitating change, you forget what it's like to be a poor product manager, 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. And I'd say this is manager problems or any of these particular things is trying to think about how to limit that. Change in progress is a very important thing.
And 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 and just everyone is trying to put change in progress and change things. You need to be very aware of what those things. So this was another thing that I reminded myself about.
This is a huge issue if you're in an operational role and something that I always forget too. But this is design and product 101. In traditional change management, you spin up this big change project and you get everyone aligned and 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. So what this is is a reminder to myself to not just so the flip side of this, as Jenny will claim, is everyone's like, let's just run an experiment. Just run an experiment with this thing.
And it's like the perpetual experiment. Nothing ever gets scaled. Like nothing ever gets operationalized.
So this is a reminder myself to say, yeah, start small. Start with experiments like, 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? You want to do that? But be ready if things are moving. To be able to then operationalize that like work with my different partners across the organization to make sure that it's things.
Does anyone have the eternal experiment problem at their company? Yeah. There you go. Yeah.
I'd love to get the confident handraiser. Does anyone have the eternal big bang project? Change management project? There we go. Yeah.
So somewhere between those particular things are reality and it's important to keep in mind this is a big one and we're going to get back to questions in a second, hopefully. This is interesting. You there's a quote from this guy, Arlo Belchi, and he has one of the most amazing quotes, and 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.
Now, if you're graceful with consistency, cultural values are like the cheapest consistency, but the hardest to get right in the beginning. Like, if everyone in your company respects the customer without having to say respect the customer, and having 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 a really terrible cost? You must go through the PMO sorry, to my program management friends, but 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. So this is a reminder to myself that whenever someone says, yeah, wouldn't it be just great if it was just 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. And I'd say this even extends into things like but here's the flip side of that.
Who's a UX researcher or design researcher? 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 they're going to work in a bunch of different ways.
So you have to be nice to them that's basically you have to buy them pizza to do those things. 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 then 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 kind of simple at the expense of emergence. It's simple at the expense of creative complexity.
It's simple out of these things. And there is this guy, Ashby, and Ashby's Law basically says you need to match the complexity of the system to address the problem as the complexity of the problem. And that's why this really small creative product team can do amazingly interesting things.
Because even though it's small and simple, a small team is capable of a lot of complex behavior and matches those things. So the thing that I learned about when I did this is that you have to seek graceful consistency, which is the same. Do you notice the similarity with the comment about consistency? You have to seek graceful simplicity, which is similar as graceful centralization to do these things.
So an example of that would be an example of that might be, hey, there's only five things in the world. It's either work goals, measures, or whatever. That's very simple.
But every team can adapt it in interesting, creative ways to achieve what they want to be able to do it. This is a more advanced thing. Does anyone have any questions about what this means with that? 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 to do things. Yeah. So there's a question online from Jade, and she's asked, can you explain leveling cognitive load a bit more? Oh, absolutely.
Yeah. So we obviously experienced this at Toast too, the cognitive load thing. There's two people, Matt Skelton and Manuel Pais, and they wrote this book called Team Topologies.
It's an incredible book. And their theory is that the rate limiter for any organizational design question is the rate of cognitive load, which is people can only process so much stuff happening before they break down. And have you ever noticed when you're in an organization and people are like, we want transparency, and then you get transparency, like, shit, I don't want transparency anymore.
Like, make that go away. What that is, is that you've hit that point of cognitive load. The way you know your cognitive load is too high is you feel like you're playing three dimensional chess at work.
Like 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.
You feel like you have to a very good symptom is you feel yourself taking long sets of notes for every meeting with action items that all just go away. Like, you can't you can't figure it out. And it's similar maybe when you're in maybe difficult or challenging or dysfunctional relationship or anything.
Like, you just feel like you're at the max limit all the time. And their theory is that's a signal that your design is off, that something is not working appropriately. What I have noticed, though, is that what happens in a lot of companies is they're like, we want independent, empowered teams.
Great. But then there's this whole group of designers and other people, they're like, but you guys 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 like rock star teams or something like that.
So that's the idea of the cognitive load. And so the signal that I would give to people is when you feel that three dimensional chess, like, 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 with it is 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 like going home and having a couple of beers. Or you deal with the cognitive load by saying, I just want everyone to shut up, just give me a project, I'm going to do it like that.
And so we actually have a great coping mechanisms for high cognitive load that often don't even lend us into a good spot. So that's the whole thing about cognitive load. We need to tame cognitive load in our environments, otherwise we can't think straight.
Let's do it. Yeah, these things are very good things. Let's jump through.
Trust is a huge force multiplier, but you can't tell teams to trust each other. This is one of my I made a T shirt of this. Does anyone have the red T shirt? Someone? Yeah.
Git prime made 1000 of those T shirts and gave them out for me one time, which is funny, good marketing for them. I just got I got taken for that. So you think about trust, it's like, just do it.
But what I've come to understand about the trust thing is that you can't tell teams to trust each other. Obviously, trust is an output, not an input. So the input into trust are like promises regularly kept.
Keeping cognitive load to the point where you can follow up on the things that you said it can do. Anyone working environment or have been in their career, where it's like 70% of 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 a permission to basically drop every ball, because you drop every ball.
What does that do to the trust level? You don't blame people I'm on roto rotor. You don't blame them because you're overloaded too. So that's an example of where reliability drops to the point where it's very difficult to get trust going in those things.
So the reason why I mentioned this and the reason why I keep it as a principle for what I'm doing is you could think of product enablement in these rules about creating environments where trust can emerge and then joy can emerge and happy teams can emerge and different things can emerge from doing that. So it's a very interesting idea once 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 one time when you're just like you just didn't for you, you're doing those things. I don't think design. Yeah, design.
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 like is self orientation too high or do we have so much work in progress we can't actually deliver anything so no one thinks anything's going to happen? Which reliability is low. Are we newly remote async trying to email each other at all hours of the night because we're in seven different countries and can't meet intimacy? The new management team, they're a bunch of top notch consultant types. You don't care about our business credibility, you can just keep going through this particular thing, oh, systems keep breaking, quality is 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. So real world example actually with my particular role is this is hard to unpack because our PMS are so busy sometimes they want to do well, but they just don't get back to someone in time which gets like a little bit of reliability thing. So I have to help like oh, how can I improve tooling so that you are not so overloaded, so you can get back to people to help you build rebuild trust with that particular thing.
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 this moment is the think big, work small idea where there's lots of teams that work small, we're agile, but they're just like going in circles. I mean, it's just stump and dumb and then think big.
It's like this is the big new plan eight months later and we're still working on it. Well, that's think big without the work small. So even in these product enablement roles, it's this idea of like strategy is thinking across multiple horizons and is thinking that my role is to create an environment where teams can build trust by working small and kind of move that particular thing.
But also we don't take the life like when we are going to probably enter our annual planning cycle and other things 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 or things they want to do, but they can really think big.
Like three year plans, three year strategies and things. So hopefully this was interesting hearing a couple of principles. If someone comes into a role like this, be happy to answer any other questions that folks have.
Yeah, I really appreciate you coming out. So in the beginning you posted or you mentioned things that you think every team should kind of have like team charter and so on and so on. Yeah, so I feel like team charter is a good place for a team to say, hey, these are our principles.
Right? What that leads to is like how if I'm a PM starting new initiative or I just joined the team. How do I come up with these principles? Yeah, that's a great and this is where I think that what do we know will not work. The classic PM move of, like, I had a meeting with my boss and they asked us, a couple of principals, so I just whipped them up.
What do you guys think? I've already showed the CPO. That does not work to do these things. You know, a really good activity is maybe like, not overloading the situation and saying to someone, 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, like, a good dichotomy.
Like, it'd be one thing if you just say, we prefer, because then they'd be like, we prefer everything. But just adding that other column that says we prefer whatever the strategy of the team, I think that that's a good method. So you might just want to do an activity with the team to kind of get that language going, I think would be a good start to do it.
Quick follow up, then I give up. Mike, do you have any kind of templates? No, I don't do templates. Except internally.
No. I mean, yeah, you can contact me. I'll give you some.
I've been feeling really worried about frameworks and stuff lately because I think that 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 then the net effect of that is that these diagrams were meant more as teaching tools, like, hey, if you're in this thing, maybe consider filling in these blanks. And then there's a whole generation of people doing product now that's like, did you see that eight box new strategy canvas to do those things? And then the first box is like, our strategy is to win.
Let's start there. Let's start there to do it. So I've been a little bit worried about the templates and the frameworks recently, but I have some up my sleeve in rare situations in case you need it.
Hey, John. Yeah. Thanks for the talk.
First of all, very insightful. You made an interesting point around graceful standardization, I believe you called it. So I was wondering if you can expand a little bit on that.
And how do you find the right balance between standardization and decentralization or proliferation of services? Signals that you look out for when you've gone too far in one direction versus another? Challenge? Yeah, this is more of like a heuristic to challenge it. It's not to say, obviously let me expand on this a little bit. It's to push the idea for graceful, graceful consistency.
Here's the most amazing example I heard of it. So I don't know. Remember when Google did the flat redesign? So remember Google products, all the apps had different buttons.
Literally, you'd go into docs sheets or whatever and you could see different design systems. And the way they solved that problem was so unique. First of all, I think it was Sundar.
Whoever was the CEO said like, I don't like that. That's got to change. So that's like 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 is like put on the brakes, global redesign, everyone, they were like, 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 you'll notice that 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.
Example everyone in the company is going to use this Prd because everyone's going to have to do that. 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 like an approved template library where I will do training or Jenny will do training or Jonathan is here will do training, where it's like, look, if you're new and you want to get really well enabled on a type of writing with a bunch of examples in a whole directory across the of using these particular frameworks, use it. But if you want to freestyle, here's the things it must do.
It must satisfy these ten requirements to do it. My guess is a lot of people will just go to the template library and do that. So again, it's kind of graceful consistency as you're doing those particular things.
And it's a huge anyone's like annual planning, all that kind of stuff. A lot of those things just smack of not so graceful consistency as you're doing. Hi, sorry.
Yeah, sorry. What will be your experience and maybe just to .1 about teams that are happier customers.
So what will be your experience on building a community of practice just to keep the product managers happy at a company? Oh yeah, like one thing that I would do with happiness. The thing I would say that it ranges from purely transactional stuff, like just reducing the amount of duplicate stuff. I would literally go to PM.
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 would you wish that you had better contact with customers, but it's too difficult, too hard to arrange that product managers thrive on connecting with customers. So that's going to make them happy.
The next thing would be something like, we have some programs at Toast are really cool, and some of them we actually have a nonprofit foundation within Toast where people can cycle in and do work. And I haven't seen people so happy that 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.
And I'm in that call, and I'm doing a North Star workshop from them, and they're just so grateful. And our North Star is going to be like megatons of food waste solved. And so having opportunities for people to cycle into those within your company, either nonprofit opportunities or other things, I think we have, like, what's? Impact week.
We have something coming up in a couple of weeks where people can pick one of four different areas to have impact. So there's 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 in that particular thing. Sometimes it's money. I can go now.
Hey, when you spoke about cognitive, you had a framework for you had a rubric, essentially, for when it's getting too high. Yeah. I'm more interested in what you had to say about simplicity, right.
How it's perhaps used and abused. So is there a similar framework in your mind for when simplicity is the right medicine versus yeah, complexity is the right answer. Yeah.
So I think this was my major. Let me give you an example of this. A team decides to create an enabling constraint to ship something in six weeks.
Now, they don't do that because the customer is saying that 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 it's an enabling constraint in a complex system to be able to get amazing creativity to happen.
The difference, though, is on a team, let's say someone's like your deadlines in six weeks, you notice that the team does it's. Like, they're not creative. They don't really enjoy it.
They don't do things. 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? I found the wedge in this problem. We're going to do this. You'll start to notice the problem cracking open when you're in a so I think that this kind of complexity simplicity thing gets a little bit confusing, where you can have something that appears very simple on the outside, like an enabling constraint like that.
And it promotes that level of complexity where you can have over. My classic one of oversimplification is as follows. It's like CEO.
There are four pillars. We're going to pursue this year? Just four. I didn't include the business as usual.
So there's like twelve, and then someone will be like and that one pillar has like 72 top prior p zeros. 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.
No one's ever been in that position before, usually. What's so funny? If you're in product doing that, you're like, yeah, I just got to go back to, oh, my God. These theatrics that are going to these things, like, you just find a way that's an example.
Just what do we notice about that? Creativity is going down. There's no coherence with reality, with what's happening. It feels kind of 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 like run the business RTB.
It's as if run the business is like a second class citizen. You will grow the business. You will run the business.
You will be Capex, you will be Opex to do that stuff. So my point is that those are examples of, like, very simple. It's either capex or opex.
Just count your hours and you can just feel it just taking the life out of the room as you're doing it. So that's how, you know, generally yeah. Hi.
Thanks for sharing your work. It's really interesting. Once you have these new principles in place, how do you measure throw them away.
Sorry. How do you measure their effectiveness? Well, that's going to be boiled into different goals like this. We were talking before about measurement and related to some of these things, and I think there's this kind of quantification fetish that I don't think is helping.
Everything that we do. And I don't know, one example of this is when there's like 75 different MPs surveys for every internal service that there is. First of all, MPs is a flawed metric.
So why are you sending it to 75 people in your company? Because 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 right, okay, so there's something wrong with MPs. But that aside, it's okay for some things to just be okay and good to do that. So I think that these are goals.
This is goals. And you know, the cool thing about this is I have to come up with a release confidence score that's going to be great. Like, measurement itself is an experiment.
A lot of people miss out on that. They think they'll argue for six months. I don't think we can measure that.
And if you've read the book how to Measure Anything Intangibles in Business, you can always measure it, but you can't always measure it as a kind of there's formative and summative measurements or like 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 amount of level that will help you redirect and do the things.
So I think one of the important things is kind of the principles will manifest in these activities. These will be measured and hold accountable to these particular goals. And then I think it's also asking people for harsh feedback, like, am I living up to these principles that I'm having and find a good friend to do that one.
Obviously, you don't want to ask your manager all the time for that one. Yeah, great. We have another online question.
So from Margaret in working in a paradox where a company wants to be more product led but has a growing PMO function where they're kind of enforcing consistency, how would you help the company product manager navigate through that? Well PMO function. Now, there's that program or project management. You can check with her.
It's all the same anyway. Portfolio. Well, I have a great friend, Evan, who is a pivotal cloud foundry.
Before the acquisition with VMware Man, evan really stepped up the program management function at Pcf to think about it as the lightest touch force multiplier for these things. He's like, 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 question about complex. Like when program management is acting as the human load balancer between all these dependencies, it's incredibly difficult on PMO to do that.
So I think that it's really about, well, first of all, they're doing an incredible job, and so any of these organizations, like, we're just going to be product led when meanwhile they have all these dependencies that 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 to do that. But I think it's about 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. And so I'd say that it's about creating an environment where program management can do that. Another thing that I think about a lot at Toast and I didn't include this particular principle here is 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 that, and that's when their magic can shine to do that.
So I think 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, when all of those incredible skills that they have can shine versus, like, the other. Well, you say story points are. This.
Oh, my God. It's going to eat their soul for doing that. So I think that that's what I would say is it's about enabling this PMO thing to get this more strategic function.
And then, like, Evan was like, the light touch. It's almost, in a sense, being in my role, you could imagine a really evolved PMO allowed to do all these kind of efforts to start boarding on Product Ops and product enablement. However, you also see situations where they've created a Product Ops function that's basically the Xpmo, and it's all fallen back in on itself.
So that's what I would say. Yeah. Hi, John.
Hey. I want to go back on the think big and oh, think big works small. Yeah, it's pissy.
I mean, this is one of those thought, stupid and weedery things. Okay, so this is a good one, right? Because what I've seen happening time and time again is that start of the year, everyone is quite energetic. They want to put money on the problem.
$1 million, $2 million. Ask it, you have it. The meetings cost $2 million for this? Yeah.
So after two quarters, the budget is cut half. Yeah. Right.
So how do you manage that? Constant prioritization? It's like, think big, work small, pay smaller, budget small. Well, I think it's my first answer will be it's like a show not tell thing. Like, I think a company can use these words, but until you've had a team that you've created the runway for them, where they 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 a 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 proceed and keep a 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. So this kind of gets to the role of budgeting and annual budgeting in the way it's the power vacuum.
It's like, get your projects up here. The money is on the table. Line them up.
It's November, and then by the time December hits by, everyone is so their soul is so broken that it's just like, just ship it. And then by March, everyone finally gets working by March, but then by July, everyone's tired and the priorities have changed, but they're like, well, we better not do it because it's annual planning starting this thing. So we all know that that's messed up.
So I think that the idea here is, like, it's the role of a product leader, 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 and we're going to do that.
Craig Daniel, who's my boss, has been very good at that at Toast in setting up a kind of 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 that you get rid of that kind of money is imaginary. Of course we'll bet on it for a quarter, but then everyone runs out of conviction to do it.
So I think that 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. And if you can do that and then consistently make progress and pivot out and make progress and have wins, then the organization in total starts to trust that particular model more and more. Hey.
So back to the 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 that from any product enablement process in Toast or somewhere else? Well, obviously there's confidentiality to see those things. Let me just try to, I guess, talk about it in the abstract.
Let's skip that just because we're public company now. Maybe I'll write a post and you can decode it even worse. Yeah.
Do you have another question though? I'm sorry to softball that one. Yeah, I also had one more. You spoke about convincing like CTO or CPO about the enablement process, but also getting the buy in from people who are on the ground level.
So it's not very easy. Like when you try to enable it, how do you tackle that? And those pushbacks? Yeah, actually I have some coworkers that I've started to bug them already for this enablement thing here's. What I've been reminding people to say is that it needs to be win win.
So let me just give you the exact example with this and then maybe we'll talk about it. Like, 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 punt back all your deadlines, and it's going to be great. That's not going to go over so well.
But if you say, hey, I realized that past efforts to rein this in has just made more work for you, we haven't followed up on our commitment to you to kind of reduce the amount of duplicate stuff. I have a metric, like I'd love to make that one of my goals. Like if you think about this back to the goals, some of this is to actually do you see how it's all crafted to be win win.
Like the improved visibility and situational awareness is for the partners because they're not seeing the roadmaps carefully now at the moment. Improve release confidence and release satisfaction. Just generally everyone will be happy.
Like what? PM doesn't want to be highly confident that their feature has the right documentation that sales is going to sell it appropriately. And to do those things that's win win, that's going to be great. And then build a continuous improvement muscle is there to give everyone the PMS also is that we're going to hold ourselves accountable to be always kind of moving the needle and improving.
So you have to create win win situations. I think. Amazing.
Thank you. Yeah, keep them coming. Yeah, thanks John, for your talk.
So I'm coming from the Think Big work small kind of principle. So sometimes it's not very easy to kind of quantify. We oversimplify tasks and put some estimates like what is kind of like the quantifications.
Because we all drive for happy customers. So in order to make the customers happy, we should kind of follow the landscape of the market and it changed very rapidly. So sometimes what we think is a solution from a small time perspective doesn't work for a long term.
What will be like the Pivot model on that scenario that you think? I think what that's getting at too, is this idea that product success is always like a layer cake of decisions. And your success now, I think it was like Jeff Bezos or someone 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 trees, you have to build awareness in your company that there's inputs and leading indicators that then you believe have a causal relationship to long term, sustainable, differentiated growth.
So the stuff I did in amplitude around the North Star framework, like, 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. The messy middle problem? Well, there's different problems in think big. That's it.
You only know long term success and nothing in work small, you only have inputs. So everyone's like, we're autonomous. 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, we're autonomous. You have the big picture. We're the big picture, but nothing connects them.
It's this line of inputs right there. Sorry. It's this line of inputs.
So I would say that you're never going to get away with. I'll give you a practical example. We implemented something called heart.
And Heart is a Google framework for UX. You go happiness and you can go down these things. Retention is one of them.
And the conversation I had with that team recently is we got to be careful to mention what our actionable inputs are and our long term drivers are, otherwise we might 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 doing is saying we need a little bit more of a graph and a model versus just a flat metrics framework.
Okay, last question. Jeez, we could spend this is fun. Yeah.
Keep it short, please. I have to go to this dinner too. Oh, no, I'm good.
A lot of time. Sorry, I didn't think I was going to get this. Thanks for the talk, John.
So far, excellent. Do you have any experience and or advice in relation to change management for acquisitions? Ouch. OOH.
Let's let's get a couple different ways of this. Does everyone know about the Expedia problem? You know, like Expedia bought all these companies and said, it's going to be great, we're going to have one platform and it's going to all be good. And they found out that doesn't work and they ended up splitting up, back all the companies into one thing.
So first off, this is not so much advice, it's just a commentary. People have wildly unreasonable expectations around acquisitions all the time, where they imagine that there'll be all these economies of scale and synergies that they expect will happen, and then like three years later, it's just economies of crap. You have to be careful, but assuming that you've made the decisions not to make that happen when you get these things, one bit of advice is it can take years to assimilate these teams and I think that that's completely fine.
In fact, things need to work themselves out. Sometimes people in the acquired company actually want to become they like the company, they want to be more, let's say, just in toast. Like, they want to become more toast.
Like sometimes you find the people in that acquired company who never were going to stay anyway, and one year later they're out. They never wanted to be in another company. They wanted the money or they wanted whatever they're going to get.
And then you get other things where it's like people from toast, let's say for as an example, really love that other culture and you get all these interesting things to happen. So I'd say that 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, causes like a premature convergence on those companies coming together and someone's like might as well rip the band aid off and expect everyone to get along.
And then the net effect of that damage is people are just like, yeah, it's okay, we got it. But for the next two years, everyone resents that. That's my experience happening.
Yeah. M and A and all that stuff is tough. We could talk all night about nice things, but yeah.