John Cutler

01Opening context

Hello, everyone. My name is John Cutler. I'm super excited to be here. First DevOps Enterprise Summit. I actually kind of feel this is my tribe, and I've just found them, which is really good. Just a little bit about me before we get started. I think it's helpful to get context about where someone's coming from. I have a background in product management, UX research, some business analyst roles, some music, and some startup stuff, and I worked in a PowerPoint factory in New York, an investment bank, Morgan Stanley, where you were counted by the keystrokes, building road shows. So yeah, I got kind of a late start to this. One thing that I'm fortunate to have experienced, I think, is that I sort of swim between a couple of these communities, and I'm not sure exactly how that happened. But I make fun of people just equally.

So it doesn't matter whether it's the Agile folks or the Lean folks or the product management folks or the design folks, the DevOps folks, the service design folks, and now I'm on a marketing team, so of course, I can make fun of marketing a lot. So I do work at a company called Amplitude. I'm a full-time employee at Amplitude. Amplitude does product intelligence, product analytics. We have a couple Fortune 10 customers and a massive long tail of startups. And the product is focused on helping cross-functional product development teams get insights to improve customer lifetime value. The reason why I like the role, I don't actually sell the product. I'm not an evangelist in that sense, but I'm evangelizing the surrounding environment, which makes a product like that just something that you would do. You don't have a choice at that point.

Whether it's us or someone else, you're going to need something like that. Interestingly, we have two personas at Amplitude. One is called the Pioneer, no relation to Simon Wardley, pioneer settler town planner, and that's this idea of this passionate product manager who wants to get insights. But then the second persona is what we call the Architect, and I would actually say you are all the architects. So these are kind of early-adopting engineering leaders who don't want to build that, and they see that there's a good product out there, and they actually become our advocates internally. They've got more important things to worry about. So I'm speaking to you today because of that. They let me out for two days to come to talk to the weird community of the second persona. I write a fair amount on Medium, and I do use Twitter a little bit, where now with a child, so that's Julian.

That's my baby. Of course, the second I left, the car broke down. They shut down the power in Santa Barbara because of fires, and the daycare closed. So the second I get back, because I'm going to leave early, I will be handed the baby, and so I'm looking forward to that because I miss him. Great. Let's see. So the phone thing advanced, but that did not advance. So we'll just use the thing. So back to this, I'm an obsessive watcher of the DevOps Enterprise Summit videos. And so Matt Skelton, who always jokes that every month I recommend his same talk over and over and over again on... I feel like I'm an early adopter of Matt Skelton because I was there really early, and I kept pushing it.

But I always found these talks to be the most interesting because they're really fascinating, and these are large companies doing really big, bold things, and that's where the really interesting stuff seemed to be happening. You can build an app to deliver a burrito fairly easily, but certain things like helping countries or banking and stuff is actually pretty complex. So I felt that this was an interesting community, and I've been supporting it. I met with Gene. I did a pre-read of his book, and I got to talk to Gene, and he said, "What's your ask? Everyone has an ask." I said, "I want to be here." So that's why I'm here.

02Audience product context

So I have a couple questions just so that I know a little bit more about you so we can kind of get going. Who has a title of product manager, product owner, or technical product manager, TPM? One, two, three. Oh, okay. So maybe 6.7%. Who doesn't have that title but who thinks that they totally do it anyway, and actually they don't even want that title, but they do it anyway? Ah, all right. Not the accidental, but the sort of rogue, you don't want that title because that'll be your curse after that, but you're doing it. Who collaborates with product managers, POs, or TPMs every day? Day. There you go. So I don't even need to do week and month and quarter because about 80% of people said they were collaborating with some product manager daily. That's really amazing, and I get to skip that whole part of the question.

Thinking over your careers, what was a defining trait of the best product manager you have ever worked with? You can just shout it out. Thorough. The what? Thorough. Clear? Thorough. Thorough. Any others? Good listener. Go. Just shout it because the people next to you, I've heard these so that people can hear them. Cool. More. Enlightened. Enlightened. That's hard. It's like we're all on the Siddhartha and going on the quest. That would be a great talk, by the way, the Siddhartha thing to product management. So we heard some things there. They're thorough, they're diligent. They maybe connect with customers. There's different things. Who has been told you need more product thinking in your organization? Okay. Who's told that you need to call everything a product, that's how you can get a budget? All right. Got those things. So anyway, I could go on with these questions.

I'm getting a good idea. Actually, I was surprised at some of the things, so I can change some of the talk.

03Professional culture clash

The one thing that you find when you're collaborating with anyone cross-functionally, and I really like Amy Edmondson's description of it, is she calls it professional culture clash. Not necessarily culture clash or not thinking style clash. I mean, she really zeros in on professional culture clash, different values we have, different timeframes we're used to working in, different language. So there's definitely a professional culture clash situation with a lot of product folks. And it does cause a lot of confusion. Question for you. What is one word that seems to just confuse everyone that everyone uses? You can shout that out, too. DevOps. DevOps. Value. Value. Value stream. Value stream. Arch. Yeah, so there's lots of words. One that I like is MVP. So now we can play the secret decoder game. So let me use my secret decoder key for you. Success. You have now solved the problem.

You can look that up. I'm not up on these, but that is a thing. Yeah, so these words are very difficult. Those product people are at another conference right now, and they're hearing about how they should do this and that, and they're using these words, like minimum viable product, and every part of that is assaulting your being about what's happening. Like what does viable mean? What does product mean? What does minimally mean? Why are they telling me this? Why are they beating me over the head with this? So there's a lot of language that gets tossed between these folks. Moving on. So,

04Product thinking is a spectrum

one thing I need to convey to you is, just like in DevOps, there is a massive spectrum in the product community. So product thinking to some organizations means the product managers do the thinking. And in other organizations, it means that there's customer-facing teams, and then there's other people. And in still other organizations, it actually means sustainable, viable, the whole company is the product. More of a service ecology. Discussions of value networks. So the reason I'm bringing this up is the things that you're talking about actually at this conference represent some of the more cutting edge, advanced topics that are happening in the product community, just from a different side.

And it's really important to remember that when you think that there is this other thing that you're not doing, and somehow you need to learn that and adapt your whole career to that because there's a good chance just by being here, you're already, other than bits of language and other things, you're already sort of 50% of the way there. It should be really empowering, actually. And I've seen this, and I know this to be true. There are terrible product orgs that are doing product thinking that beat people over the head, and there's highly advanced places where you'd feel instantly at home coming from this conference, even if you had never worked with those folks.

05Three product-team models

So in my day job, I talk to lots of teams every day. So this is just to point out that there are... In any given day, I'll talk to these three different models of product teams. The first one is like the st umbrella. So the st umbrella takes the ideas, features, and tasks, and is like the auctioneer of capacity for the organization. And the st umbrella takes all those things and then funnels them, and it passes them to the team. Great. Now the next one is a little bit like the PM as idea person, idea woman. So they get some goals and objectives from the company, and then they dream up the ideas and the features, and then they pass it on to the team. A little better. A little better. There's no st umbrella, but it's things. So the third thing is where this is moving, right? Where the product manager is a member of the team.

They might be conveying goals and context from the rest of the organization, but they are an equal member of the team providing context to help better decisions to happen. They're not making the decisions necessarily. They're creating an environment where the best decisions can happen. The reason why I'm showing this to you is that there is no one product thinking. There is no one destination. It's just like this community. You could draw almost a similar map for DevOps and being there's s**t umbrella DevOps people, and then this full collaboration thing. So keep that in mind. It's a lot closer than you think.

06Feature factories and product-management frustration

The reason why I know that to be sure is I wrote this post called "12 Signs You're Working in the Feature Factory." I wrote the post. And most of the feedback comes from developers and designers. They are the ones that feel the most anxiety about working in the feature factory. In fact, product managers, I hear a lot less of. So I'm just indicating there that the impetus for change in the product community might actually be coming from developers and designers moving the needle, and it's very interesting. I would say there's a growing resentment of product in a way because product is not moving as fast. They're still in the belly of the beast of the organization. Wow, that time flies. Crap. I will skip some things because I don't want to hold anyone up for lunch, and we should go.

Basically, my customers when I was doing consulting were saying I need to figure out how to product manage the product manager. They were sick of these people. They knew something was better, but they hadn't gone to the conferences. They hadn't learned. So they just guessed something was better.

07The A-to-I decision spectrum

So what I want you to do to imagine this is consider a spectrum from A to I. This is a helpful tool, and you can use this in your companies next week. And so A is build exactly this to a predetermined specification. And imagine B is build something that does this. C, build something that lets a segment of customers do this. D is solve an open-ended problem. E is explore the challenges for some set of customers. F is increase or decrease a known metric. G is do much more exploratory stuff. H is generate a short-term business outcome, and I is generate a long-term business outcome. The really important thing when you look at this is that if you can get the fingerprint of your organization, and I'm showing you this to show, again, product is a huge spectrum even within organizations. This is an organization.

UX, developers, and product all sort of self-assign some of their efforts to those individual levels.And it created this huge diagram. This is my franken chart. My franken chart shows that product, like, yes, there's a hump around F and design is more around D or E, and developers were sort of taking that a little bit more prescriptive stuff. But importantly, if you map organizations like I have over and over and over, you see highly hierarchical organizations where every single one of those layers is owned by a person. And you see other organizations, which I would say product-led and more sort of forward-thinking organizations in this, where it's very nebulous. The PM is just slightly closer to the GM in that particular setting.

So we'll share the deck and you can do this, but one way to start to understand even what you're collaborating with is to understand how people make decisions and how they're making them in your organization. This whole talk is about collaboration, by the way. We're going to set up the three traps in a bit.

08Trap 1: WIP, promises, and trust

So the first trap, I know you guys have been hearing this for a long time, but here's my theory. My theory is you've heard about work in progress. I use some other terms like promises in progress, change in progress, elephants in progress. And elephants are the number of elephants in the room that are in progress. And the work actually only represents a tiny percentage of all this stuff. It's crazy. Much more, you onboard someone and you say you're going to be a good manager for them and take care of them through their career, you've made a promise. You make a promise to a customer to continue to be a valuable service to them and a partner to them, you have made a promise. All these are promises. There's this thing called promise theory. I'm not going to go that deep into this particular thing. But I know you have the best intentions to keep WIP low. I'm presenting these other ideas.

I know that you have the best intentions. When it's not that way, you blame other people, or you blame Scrum, or you blame SAFe, or they made you do it. That's why the high WIP is there. But I'm going to propose for a second that you also have a role in this. There are perverse incentives that encourage you to actually keep WIP high. I will just take one round through this because I could do this all day. So as WIP goes up, throughput goes down, time to deliver goes up, time to realize benefits goes up, outcomes goes down, morale goes down, opacity goes up, lack of confidence the team is doing its best goes up, distrust goes up, outcomes goes down. Lose key players, hire new players rapidly, throughput goes down, pressure for short-term results, need silver bullets, context switching, WIP goes up. WIP goes up, dependencies go up.

You have to hire human load balancers, AKA project managers. Those are coordinators. Then you have to do more upfront planning because you have coordinators. Then you have to do, oh, you reward output over outcomes. You're going to reward busyness. You're going to reward utilization. Upfront planning, local agendas, back to focus. So the whole point here is you can go around and around and around in a circle. I guarantee that if you were to zoom in on any of these parts locally, you actually have perverse incentives in your particular area that are encouraging this. The important part is the morale problem or your retention problem is a high WIP problem, and you're part of the problem because you're looking locally in one of these settings. Oh, my people have really low morale. I don't really quite get it.

You're going to start blaming them, and you have to step back and look at the system, and WIP has a sort of multiplicative effect. It's not just your Kanban board. Your promises in progress, your elephants in progress, your change in progress, all these things are really important. So I like to do these. Here's an actual team. So lunch, two hours. Diagnosing production issues, status checks, estimating future work, meetings about future work, waiting for CI and loading issues, delayed by technical debt, not working through it, hiring new people, response to going slow, value project A, value project B, context switching. This is a team at a Fortune 50 company, that 40 hours a week, there's 6 hours a week that are actually going to creating value. No, but what happens when you see this, right? What's the next step? Everyone know what the next step is? Yes, you get on the train.

So you start to get Soylent. You don't even do lunch anymore. Everyone can just use the CamelBak. And productivity, you're going to jam stuff into that sprint. You're going to do 10% tech debt work down. The trains are leaving the station. Everything is value add. This is great. Going gangbusters. But what happens after that? Oh! Oh no, it's tech debt month or what I call reduced drag month. S**t, everyone needs to work 60 hours. And you buy, so I call it personal pizza size teams because everyone has one story themselves. It's not two pizza teams. You buy this vending machine and everyone gets the personal pizza. So they do that, right? Okay, so then what happens after this? Oh my god, you do that for a month. There was some animation. We all know it just kind of goes back to what it was before, just worse. There's only A and B. The company sort of settles into its vibe.

It's gone through hell and back. It's just going to resort back to earth. And there's decisions that you make that play a part in this, and there's decisions you make in terms of your collaboration with product that impact this. This seems very sort of technical. It's not the sort of human-human collaboration side, but it's important because you're making these decisions that impact these relationships. So Larry Maccherone has something he calls the trust formula. You may have seen it already, but I found it to be incredibly useful, and it says that trust is a function of credibility, reliability, and empathy divided by apparent self-interest. So I'm explaining this as we looked at the WIP diagram because you could start to see all these examples where either you were losing credibility or your product counterparts were losing credibility.

You were starting to assume that there was apparent self-interest. There's morale drop. Trust is dropping every time this happens. It's really important. Examples, product manager, they don't want to admit that anything went wrong. Product thinks engineering wants to hog the interesting work. Scrum Masters aren't developers. That doesn't go really that far. Apparent kingdom building, promises there's a technical roadmap, no one sees it. So you can imagine all these opportunities at this point to lose trust.

09Lowering WIP creates trust

So what is the alternative to this? If you lower WIP, you can start to work together, you can start your efforts together, and you can finish together. You can start together, work together, and finish together. And when you can do that, you can build the face-to-face connections and the experience that allow you to build trust and not play Tetris. That's why you lower WIP, to create trust, to create better relationships with product, and this is why your quarterly roadmap Tetris is also impacting that, which impacts this. And this works. So this is a whole cross-functional team. DevOps, designers, and people were doing a design exercise. Here we are at a customer on site watching them do their work. Here we are all doing a design activity. We're all starting together. Only made possible by lowering WIP and thinking more holistically. So some of you are running sort of platform teams.

What does starting together look like? You will have someone present in that kickoff because something might bubble up. You've got to kind of keep an eye on where that thing is going. I understand embedding is the way to do it, and then people say, "Yeah, but that's the ideal." There is an ideal time. Some 80% of an effort's success sometimes is determined in that kickoff when you're starting to get the shape of the work. So you need to have the person there. I'm going to run out of time because I love this stuff. Yes, keep small promises regularly. That's the whole point.

10Trap 2: shipping versus learning

So the trap number two is velocity becomes greater than cadence, and moving around becomes greater than the true work. If you're familiar with Taiichi Ohno, he says there's a difference between moving around and the true work. I also call this the make the product manager eat the humble pie by having insights that show that they're not quite as smart as they thought they were approach. But this is a voodoo move. You're going to work behind the scenes to make this happen, but you're going to try to work with them on this. So I want you to ponder for a second, do you ship faster than you learn, or do you learn faster than you ship? Who believes that they ship faster than they learn? Who believes that they learn faster than they ship? Okay, it's a hard question. That's why everyone isn't raising their hands for one or the other. You have to think about it.

In theory of constraints and a feedback loop, we're actually trying to balance those things. If one gets out of balance, the system gets out of balance. Now what tends to start is we ship faster than we can learn. In the beginning, we add so much non-value adding complexity to our products that eventually the problem is that we can't build as fast as we learn. There's learning inventories piled to the ceiling, but we can't actually execute on them. But the root cause was at one point we shipped faster than we could learn. It's a very, very interesting model. You could ask this question next week and have a conversation about it, and it'd be interesting. Another way to think about this is, I worked with a team recently, we know when something's working when we spend longer on it. Huh. Because the feedback loop is so tight that they know that it's working, that they continue working on it.

So add that to your flow metrics, right? Pick the resolution of the work you're thinking about. Maybe it's the rapidity of experiments and actually the mission level work, the opportunity level work. You think about lead time, but you have to accommodate for the fact that when something's working, you actually want to double down on it, which means you keep working on it. That's what you can do when you're learning as fast as you ship and ship as fast as you can learn. This is the one that I think I have it wrote. I was really tired doing this and I was looking at the circumference of the circle and trying to time it in Keynote to get them to go through the right things. But essentially, the balls are moving at the exact same speed. One company is learning a lot faster, but they are moving at exactly the same speed.

To any observer locally, when those are going around, you'd think they were moving at the same speed, but one is actually learning faster. In fact, the one on the right could slow down and still outperform the company on the left and have more sustainable thing. I'm trying to orient your thinking around this stuff because when it comes to collaborating with product, if you sort of understand these concepts, they may not understand these things yet. But if you understand them, you can be thinking ahead about how you could help them. How could your platforms help them? How could infra help them? How could you be focusing on the learning loops versus the shipping loops? It's really, really important. No one wants the top one. It's just chaos. Nothing's valuable. All red. The second one's a well-oiled feature factory. Some fives, some fours, maybe a seven out of 10.

I'm saying scale of one to 10 of valuable. There's some duds. What we want is the rapid feedback loops that start out crappy, like three, six, seven, eight. You hit a thing. You start the next thing, two, six, 10, nine. Netflix and Gibson Biddle talks about 10 years at Netflix, they sort of understood their batting average for strategic efforts. Not A/B experiments, but strategic efforts. And they're batting about 300 at Netflix. Which is pretty good at some of this stuff. That means 3 out of 10 of their strategic initiatives actually kind of met the... They weren't just mediocre, they really did well. Sorry, one out of 10 did really well, and three out of 10 actually did decently. So you have to think about these things when you think about your feedback loops. So in my work, so this is really funny, just two weeks ago, I'm talking to someone.

They've got 10 new reqs out in the Bay Area for $3 million to $5 million a year. Can you identify one customer-facing outcome for the last quarter? No. What have you been working on? We have a massive five-year data warehousing effort. I swear it's going to be done soon. It takes three to five weeks to get a report. They're losing people. Oh, well, I don't know, but the passionate people are leaving. There's a reason why they're leaving, because no one knows the work has impact. And just coincidentally, I was like, "Well, how about our product? What, like three-quarters of a million dollars. You are like a fortune big company. It might be a lot." "Oh, well, that's way too much." So again, back to the incentives that you create within your departments. Once someone gets the budget and someone wants to hire on a lot of people, you have to be thinking about these learning loops.

Are you making decisions that are allowing you to learn as fast as you ship and ship as fast as you learn? Because you could hire these engineers and they would be great. But you still have a problem. If Netflix is at batting 300, you're batting it, 10 or five out of those. I've lost so much time. So

11Shorten the distances

the critical point is to consider the distance, and I think this community is super well-positioned to think about this. The distance from the team and their users, each other, the customers, support success, sales, marketing, the budget. How close are you to your budget, the data, the insights, the strategy, the deployment into prod, prod-like environments, hiring, all these things. That is where you get your step changes, is to figure out how to-- You think it's about getting developers to move faster, but increasingly that's not actually the differentiator. The differentiator is to shorten these distances within your company. When you can think about that, then you become an advocate for product and design and they start understanding outcomes instead of it being-- Often I meet product managers who say, "Oh, of course, outcomes over output." But we can't measure any of that stuff.

We've got observability. We can tell when something's wrong in the world. We're chaos engineering, but we don't understand whether anyone's using this feature to start with, and so that's kind of a dichotomy.

12Trap 3: separate technical backlogs

So the final thing that I want to get into is to technical backlogs. And this is an anti-pattern that if you can solve this, you can really improve your collaboration with product. And this is these sort of separate technical backlogs. It's engineering feeling like they don't want to go head-to-head with product in an apples-to-apples prioritization. So they run their whole world off of some capacity percentage. "Well, we'll just take 33% or not even tell you about it." Now the big challenge with this, imagine every company you're at is a value creation system. It is a restaurant. The cutting board is as valuable. You've got meat coming in, you've got chefs, you've got everyone. You are a service business. Forget about product for a second. You're there to make people-- Your product is this great experience.

The maitre d' is the product, the chef is the product, the person who makes your kitchen is the product. You're all the product. You're all a value creation system. Great. So you're making money. January, you make $5 million. In February, you make $10 million. In March, you make $15 million. But now imagine all sorts of drag in the system. There's all this pressure. There's all these headwinds. The health inspectors start to show up and your best chef leaves. Your cutting boards have salmonella on them. It's disgusting. Customers are leaving. You buoy it up with a coupon, but the coupon sucks. And so that's all sorts of stuff that's headwinds coming into your thing. Call Gordon Ramsay. You could. Yeah, John Smart is the Gordon Ramsay of this-- He's not, he's too nice for that. Gordon Ramsay's kind of a jerk if I remember correctly. So anyway, so you imagine that this slope goes down.

The value creation system, you're not feeding enough people. It is going down. So the interesting thing here, what I'm trying to leave you with is when people talk about money and how to prioritize infrastructure and tooling, one solution is to just hide your roadmap. It's going to be okay. Don't worry about it. The other way is to find out how the organization is creating value and how your tooling can improve the value creation capabilities of the whole system. Then you've hijacked their value in some ways. You're able to piggyback off of whatever value they're creating in the system, which then improves your relationship with product once you get over the hump. Because the hump is you don't want to show too much. You want to keep it opaque. It turns into micromanagement after a while. If you're too opaque, it turns into micromanagement.

13Trust proxies and prioritization

So I want to finish on a couple thoughts. That says I have 1 minute 20 and this says I have four minutes, but I think we're in good shape. I want us to go back to Larry's trust diagram and the drawing that I did with-- So, obviously in the beginning, if you have trust, just do it. Thanks. And if you don't, you go through this incredible quagmire process and stuff. And I want to ask you one question. How many of your processes and systems internally are trust proxies? Yuval Harari says that humans create robust stories to transact business. So what are the stories you tell internally to proxy trust? What's the process you create and the systems you create? And if you look at those things, and if you look at opportunities to improve that trust with your product counterparts, the people you're collaborating, or if you're a product manager, that can have a dramatic effect in your company.

Someone said, "Well, how do you prioritize this?" I just remembered. My prioritization is really simple. There's only two things you need in your company. The highest opportunity thing that's experimentation-friendly, one, and two, any big opportunity that's guaranteed very small. Forget about estimation, really. You estimate the highest opportunity, and if it's really valuable, it doesn't matter if you're Netflix and it takes you 3 out of 10 times to be able to get the value out of it. It's the most valuable thing. And if something's guaranteed very small, but really valuable, well, you win there too. Guaranteed very small is easier to know about than medium level very small. So there's a form of prioritization here.

14Review: three opportunities

I want to wrap up in the review. I have to run and I have to go home early because of all this mess, but there's three opportunities you have. And this seems distant from the idea of the human-to-human collaboration that you have with product, but it all builds trust. And if you can build trust and if you can keep small promises, then you can build trust more and more. One is really lower work in progress, promises in progress, change in progress, the elephants in progress. Elephants are hard. How do you limit? Because the elephant's already in the room. That's the bummer about the elephants in progress. There's like a thing on the bottom of the Kanban board that just has elephants in it. There's no to elephant, doing elephant or thing. They're just there. The second thing is this balance between shipping and learning.

I think this community's actually the best positioned community to attack that problem of feedback loops, which will then unlock these sort of-- A lot of your companies are chasing this tiny little 1% gain on some product. And some C-suite person has been talking about the big thing that you could only do if you could just figure out experimentation and the innovation lab in North Carolina could send their people somewhere else, right? And they're just waiting for that asymmetric outcome to happen, but they aren't seeing it. So really the root of a lot of those outcomes are in feedback loops and being able to learn quickly, and then that's where you can actually create not just tiny cost savings that you're doing or sort of reductions, but you can explore CapEx increases and things like that. So it's really, really important. And then finally is this apples-to-apples prioritization.

If you can partner with product and start talking, find what their value streams are, then it becomes infinitely easier to prioritize what you need to do to be able to help their value creation through the system, and then call the kettle black. If you're doing one thing that's worth a million dollars a month and the other person's thing is not worth anything, you should not have to do both those things. You should always maximize for value throughput and you should pick the million dollar a month thing if that's what you're doing. So that's my talk. I can't hang out a lot, but I do office hours as part of Amplitude. You don't need to be a customer. We don't really expect people to buy it through these, but you can just reach out and just schedule an hour through LinkedIn or Twitter and we can do it. I'll do all the questions there. Thanks a lot.