John Cutler

Hello everyone. I'm extremely excited to be here for DevOps Enterprise Summit London. It's actually my second DevOps Enterprise Summit. I did the forum thing, which is super interesting. Thank you, Gene, for the invite to that. I've found this community to be incredibly welcoming and giving, and everyone is really curious, which is exciting. Sometimes I go to conferences for product management or UX and everyone kind of has it all figured out, but the DevOps community seems perpetually curious, which is great. People share their work and share their stories, and I'm super excited to be here.

First, a bit about me. I have a background in product management and UX research. I had some odd jobs in my 20s. I was in a PowerPoint factory at an investment bank where we would do hundreds of pages of PowerPoint every day. I got involved in music. I had a video game called Last Call, which is a bartending game. I drove a rickshaw in New York. Basically, I did a lot of things in my 20s and then settled into this career. I'm active in a lot of communities: agile, product management, design, now DevOps, and org design. I don't really just identify with one of these communities. Like a lot of people, I pick and choose what's interesting from different worlds and try to figure it out in my head.

I became addicted to DevOps Enterprise Summit by watching all these videos, and I found it to be some of the most compelling discussions about org design and safety and systems, so I have a sweet spot for the DevOps community. I write a bunch. My blog is at Cuttle.fish. I have a two-year-old, so my attention span sort of fits into Twitter, and I use Twitter a lot. You can find me at @johncuttlefish.

Currently I work at Amplitude. Amplitude focuses on product analytics for product teams. It's not general BI, marketing, or generic SQL. It helps teams make sense of complex user behaviors with digital experiences and digital products, and it focuses on helping and empowering teams to act, experiment, and get a virtuous cycle of learning. I mention this because it gets me in contact with lots of teams from lots of different contexts, journeys, and industries. My role is more of an external team coach. I focus on customers, prospects, and the broader product public. I do a little bit internally, but I'm mostly externally focused. I write books for Amplitude and design workshops. Basically, it's a dream job. I get to nerd out all day about product stuff.

Recently, I've had a lot of engineering leaders sitting in on these conversations, or even initiating the conversations with me, because they're interested in product management, product analytics, and design. A lot of them have had some top-down mandate in their organization that they have to become more product-driven, and they're curious. They're second guessing how it's going down in their organization, and often that's for a very good reason. That's the inspiration for this talk.

There's real hype in the DevOps community, especially around projects to products. Congrats to Mik Kersten for getting that going. How does this manifest in organizations? Suddenly product owners are popping up everywhere. Products are popping up everywhere. If you want budget, call your thing a product. It's easy. You get influence. There is a growing awareness of value streams, which I think is very valuable. At DevOps Enterprise Summit Las Vegas, I hosted Lean Coffee, and at a table the questions were bubbling up: what is a product, even? How does product thinking even fit into our organization? People are actively mulling over this question, and I decided I would try to address it in this talk.

But I have to admit that something is missing. I talked to companies about how this was being put into motion, and I would observe very well-oiled feature factories. There's a product, there are features, it's usable, and they're getting a lot of stuff done. I saw investment in tools, consultancies, design thinking, and a lot of talk of internal customers. That started to get even more confusing to me. This is a DevOps conference, so did I expect a lot more, or did I expect a deeper understanding? Communities need to focus somewhere. For example, in the DORA report there is a box in one of the mental models or hypothesis trees, and it mentions lean product development with two lines: gather and implement customer feedback, and experimentation. There is some of that, but something still felt off. It especially manifested when I would hear people talk about the business and the teams, or see silos still present in people's thinking. That's what I want to dig into today.

The goal of this talk is to share some important concepts related to product and design. I want to seed your brain with ideas that could come in handy as you interact with other people in your organization. I want to break through the dogma associated with product companies. A lot of people I speak with in the DevOps community say, I get this projects-to-products thing, but what does it mean in my environment? We're not a software product. We're not Amplitude. How does it work for us? I also want to talk about new ways to think about being product-led. That phrase gets thrown around and leaves a lot of people scratching their heads, especially in this community. Does it mean not technology-led? Does it mean product manager-led?

To summarize the talk: we'll talk about the essence of being product-led; the shift to thinking about real customers out in the world versus internal customers; moving from being funnel-driven, like a sales or marketing funnel, to thinking about engagement ladders and lifetime value; the shift from features and products as the thing we ship to seeing them as temporary solutions, today's solutions to longstanding problems; short-termism, because you can be as short-term with products as you are with projects; learning as fast as you ship; and finally, embracing the mess.

First, what does it mean when someone says, that's a product-led company? There's a lot of confusion, especially when people say they are not a software product company. They might be Anheuser-Busch or Burger King. Those are both customers of Amplitude, and I've talked to these people. Product-led does not mean product managers run the show. It does not mean you are product-management-led. It also doesn't mean you're somehow not customer-driven or customer-obsessed or any of those other cliche terms. Product-led is cliche in its own way.

At its core, being product-led is about believing in the power of design and technology, and believing in the power of cross-functional teams, both small teams and larger teams of teams, to have an impact. It's about connecting to the real humans using and paying for your product. It's not necessarily about selling a software product. It's about believing in the power of products, and that's an important difference.

By sustainable impact, I mean that the way you use design and technology should drive sustainable, defensible, differentiated mid- to long-term growth for your company and mid- to long-term outcomes for customers out in the world. A sales-driven company can be extremely short-term and close that quarter, but when we are product-led, we believe design and technology can create moats and sustainable growth. These are asymmetric outcomes. Marketing and sales can be pretty linear: you put money in and get money out. Now we're talking about step changes for the business, where a business working in one way gets lifted to another level by design and technology.

Sustainability also means the people in your company feeling their impact sustainably. You can talk to a developer who's been at your company for five years and they can recount, by the quarter or by the half, ways their work impacted people out in the world. That's special when it happens.

To make this real, I remember a quote from a developer working on what they would call an internal platform: I'm working on one of our internal platforms, but I'm so inspired by what we're doing out in the world. That's the essence: a relationship to impact out in the world. Anheuser-Busch, or AB InBev, is an Amplitude customer. What did it mean for them to be product-led? How did they use design and technology to create an asymmetric outcome? They needed to figure out how to get their field sales team working more effectively. They are very lean-centric and have a foundation in lean thinking. They applied that to the problem and thought about how they could create digital experiences for their field sales team. They were using technology to make the sales team more effective. That's the kind of thing we're talking about.

Another essence of being product-led is breaking down silos. I often hear about the business and IT, or the business and the technology org. When we are more product-led, those silos begin to fade away. Everything is the business. That's a critical difference from the imaginary line between the business people and the people on the hamster wheels making the software. At that point, the whole company becomes the product. If you work in a huge organization that makes shoes or something else, this is why product thinking and being product-led apply: at a certain point, the company is the product, and you're thinking about more creative ways to use design and technology to create outcomes. Projects to products is interesting, but imagine projects to products to experiences, ecosystems, value networks, and all kinds of things that make the whole company the product. That's the leap we're hoping to make.

The next thing is the shift to real customers. Let me start with a story. At one company, they tried to adopt product thinking. Everything was a product, and they started talking about internal customers. The team described that as really helpful at the time. There was more empathy, it was less transactional, and the way they worked was more connected. At that time, thinking in terms of internal customers was really helpful.

Then what worked started to become their Achilles heel. People started asking more questions. How is our work on ETL impacting the real human beings out in the world? Our internal customer is happy, but how about the real customers? Is our internal customer making great decisions? Or: I have a better idea about how we can do a better job for the humans out in the world. They became a victim of their progress. They had up-leveled their teams to take systems thinking and impact seriously, and now the teams were extending that thinking out into the world. That was the start of healthy tension in the organization.

The shift to the term partner was critical in that organization, while keeping customers out in the world front and center. This may seem like quibbling over words: partner versus internal customer. But when we think about becoming product-led, we're talking about becoming a single business, a single product, and above all aligning with the customer we are helping out in the world.

The third idea is the transition from funnels to engagement ladders and customer lifetime value. If you can nail this, you can nail a lot of internal discussions about what you are doing and what you are optimizing for. A traditional marketing and sales funnel is literally like dropping people into the top. You pay to market to them, they move down the funnel, you sell to them more, and there is top of funnel, middle of funnel, and bottom of funnel. You buy that customer and then you have a customer. It's like dropping a human down a funnel. It's linear. You can improve how it works, but it is highly competitive because everyone is trying to get those customers at the same time.

The larger landscape has changed with subscription models and decreased switching costs between products. Once you've landed a customer, it is actually the start of the relationship. It's just the beginning. Now you have to think about retention, expansion, evolving your product, taming and grooming product complexity, new technologies, and new opportunities to meet their needs. That's customer lifetime value. When I hear engineering leaders advocate for efforts or initiatives, I don't often hear about lifetime value of the customer. I don't hear how they intend to increase it.

This is at the core of the shift from projects to products. It's not just a command-F replacement of projects with products. It's fundamentally about how customers are paying for and interacting with what your company has to offer. It's persistent, longstanding, and evolving. It's not just a dogmatic new way of working. The reason we're shifting to products is that we have to shift how we work to respond to how consumers and businesses are purchasing software. It's more like an ecosystem or service ecology. It's not dropping the product off the back of a truck and hoping it ends there. The question you need to ask is: how is my component, service, or tool contributing to customer lifetime value and moving customers up the engagement ladder? Instead of a funnel, imagine a ladder, where you move customers higher into an elevated state in terms of the value they can get from your product.

Similar to that, I've noticed in many projects-to-products efforts that people get obsessed with features and start explaining what products are. But products and features are temporary but differentiated answers, solutions to longstanding needs. They're actually ephemeral. Some products last forever, but many don't, especially with software and what we can do with technology. We're constantly finding new ways to meet human needs. I worked at Zendesk, which helps support agents handle support requests. That has been around for a while, but if machine learning or AI helps humans out in the world get their problems solved more quickly, that creates a step change for the business. Once we make the shift to persistent products, it becomes harder to define, and in a sense the company becomes the product.

In many enterprise product transformations, this thinking is missing. They're taking early-2000s or mid-1990s ideas of product life cycles and smashing them into 2020 ideas of what it means to offer products. You go from linear old models to new engagement loops. It's a new game. Thinking of features and products as temporary is important because it is the shift away from well-oiled feature factories that we need to see. People argue about what thing of value has been built: is it the thing, the bits deployed, or is it your deep understanding of the core needs of the customer you're meeting? I would argue that technology comes and goes. We need to plan for the obsolescence of our products and the technology we make. We're never done, and if we are, something is wrong.

I mentioned sustainability a couple of times. Craig Larman and Bas Vodde, in 2009, had an interpretation of the Toyota Way and the lean thinking house. At the top of the house is sustainable shortest lead time, best quality and value to people in society, most customer delivery, lowest cost, highest morale, and safety. The part to notice is sustainable shortest lead time, best quality, and value to people in society. It isn't sustainable shortest lead time and just quality. It's quality, lead time, and value to people out there, and people and society. You can make your customers happy but destroy the planet.

Yet in business-to-business and large enterprises, it is way easier to ship new shiny objects for short-term revenue growth than it is to be great design thinkers or product thinkers. Those are shiny objects. Marketing will do their thing, sales will do their thing, and before you know it those things will be flying off the shelves. You'll be closing deals and everyone will celebrate, because really, humans buy on features but renew on outcomes. How often have you obsessed about the features in something you were about to buy, then bought it and found out your outcome wasn't exactly what you thought? When you renew and decide to pay up, you're not looking at features the same way.

The differentiator for sustainable product-led growth is that you have a product strategy, make great decisions over time, build this foundation, and design and technology become engines for growth, retention, expansion, and so on. That's what differentiates the best product-led companies in the world. It's not the A/B experiment that proves landing page A is better than B, C, D, or E. That's an interesting activity, and marketing does that all the time. But really, the interplay of product strategy, experimentation, delivery, and learning about customers on a deep level becomes the differentiator.

I like to point this out with a quote from a salesperson I used to work with: we used to sell on the roadmap, but now we sell a record of innovation; we sell the outcomes we generated over the last year for our customers. That's a great quote because sales is always asking for a case study. Sales says they just need a case study; if they could prove the ROI, things would fly off the shelves. What's ironic is product hears that and then goes off and builds all the features sales thinks are needed. What you should do when you hear that is build what will produce the ROI for the case study. That's an interesting angle on sustainability.

A key idea is: are you learning as fast as you ship? I've been tracking this in the DevOps community and other communities for a while. A couple of years ago, for many companies, the story was: we just need to execute. We're going so slow. Gene Kim bragged about a competitor shipping every hour, and we ship every six months, and this is the end of the world. Those companies developed massive inventories of ideas and things to do. Maybe they were drowning in debt or needed to re-architect, but they had all this learning accumulated and they just couldn't ship fast enough.

Then the company starts catching up. They go to DevOps Enterprise Summit for a couple of years. Features are flying out the door. They've gone from six weeks to six days to six hours. Each new release turns heads internally. But for many teams, the bottleneck has shifted. They've gone from learning faster than they can ship to shipping faster than they can learn. That's a good place to be, but it's important to understand that this is what's happening. The danger is that as you add more complexity to your product, offering, architecture, and everything else, the proportion of that complexity that delivers asymmetric outcomes for customers really matters. If you don't pay attention, your product will become the mishmash of ideas that got you here because you didn't learn fast enough. The challenge is closing the learning loop. These insights are as important as elements of CI/CD. Solve those problems, but also think about closing the loop. This is an extension of observability, in a sense, but related to the product and the value it delivers.

I'll end with embracing the mess. This is one of the hardest things leaders, engineering leaders, and others in larger companies have with what it takes to be truly product-led. When teams are doing this, and the best teams in the world are doing this, to someone from the outside it looks like a disorganized cluster F. It looks like a mess. You might stumble in and see designers and developers pairing, the team picking up the phone and talking directly with customers, learning something and pivoting. I love when a team told me they know things are working when they spend longer on it. Chew on that. It's a mess to anyone from the outside. That's the hurdle companies need to get over: what works doesn't look like work to people, especially around product.

In closing, hopefully I've given you ideas ranging from what it means to be product-led, to engagement ladders, learning as fast as you ship, lifetime value, and products and features as temporary but differentiated solutions. We sort of want our technology to become obsolete in some sense. I am eager to chat with more product-oriented engineering leaders. I'm doing a lot of work at Amplitude trying to answer their questions about what this whole product thing is in a way that passes muster with them, and frankly the bar is pretty high with a lot of engineering leaders. I want to understand what makes adopting these ways of working difficult. I want to brainstorm with people, especially around the analytics question, about why we get this Conway's law of data in the organization, what makes finding a single view of the customer so difficult, and your journeys to becoming more product-led, both the good sides and the bad sides. That's my talk. I'd be happy to answer questions. Thank you so much.