Crafting Stellar Product Process with John Cutler

John Cutler is a Product Evangelist at Amplitude. Previously, he’s served in various product roles at Zendesk and Pendo.

If I were to attempt to describe John succinctly, I’d call him a “relentless product thinker”. When you speak with him, it’s apparently that he has thought, and is right now thinking, about how to innovate in the process of how organizations build great products.

I first was interested in sitting down to speak with John when I saw that his talk at this year’s Decisions conference in San Francisco centered around the idea of Outcomes vs. Outputs, a topic that I’ve written about before.

The notion of things not being as simple as Outcomes being good and outputs being bad was an interesting one for me, as I’ve often been the person pounding the table for the former, usually in somewhat absolute terms.

Editorial note: I have done the best I can to accurately transcribe mine and John’s conversation, and everything in italics from here on will be John’s words, though I’ll cut in with some commentary here and there.

Also, if you’re in a rush, just read the stuff in bold.

I frequently find myself as the ideologue of a group of PM’s, what are the barriers to that thinking being practical?

Sometimes people have a very idealized . People tend to say “all bets are off”. It’s the difference between being comfortable with uncertainty. It’s important to be comfortable with being a little less wrong. People feel like they don’t have the time or the tools to work on these cultural issues. Can we make slightly better product decisions today than we made yesterday? The real-world manifestation of it is much more subtle.

Product teams need to realize that “perfect” is an unattainable thing, and that improving day-by-day is the key to creating an ideal process for your team. After all, isn’t iterative improvement the whole point?

For customers that overly index on features, how can you pivot a customer back towards outcomes?

This is where the whole company is the product, because it takes the entire team to set those expectations. Sometimes you need to just build something. There’s an 8 level model that I talk about that covers how to set expectations. Talking about outcomes, and also, just the language that you use. One great way to have these conversations is to talk about options — we’re going to consider trying this, and this, and this — and seeing what feedback comes about. If you pitch a customer a project to improve a given workflow, they might come back and say that they only complete that workflow 200 times a month. It can be a good method for learning about your customers’ goals.

The model above does a great job of outlining the evolution of challenges that leaders issue to teams as they become increasingly autonomous and empowered. There’s a lot to learn from having a discussion with your leadership about where you fall.

What are some of the best ways you’ve found to help bring customers and their users together?

You need to serve by example. I advocate a lot for co-design and co-development. Why isn’t your customer joining you in your office for a week?

I was working for this property management software company, and at our user conference we would bring people in to help us co-develop our product. One of the outputs of that was them saying ‘oh my god, we need to bring our tenants into our offices for the day and try to do this example’. We lead by example, and they really saw the value of that.

I’ve long said that maintaining positive relationships with customers and users is the most powerful thing that a product group can do. It requires investment and dedication, but the results are incredible. Get your customers on your side by making them feel like they’ve built the product they’re using, and you’ll gain a long-term ally.

What is your ideal approach to roadmapping?

I think that this is cynical, but I often think about ‘what don’t we want?’ It would suck if we didn’t converge on ideas, it would suck if we didn’t do X and Y, and I think about the experiments that we can run to avoid those negative outcomes. What I advocate for are single, prioritized lists, not swim lane-type diagrams. That, or hybrid models where you experiment with a backlog of goals, and the interventions that we’re going to try

One thing I don’t like is scrambling every year or funding raise, and suddenly you’ve decided on an 18-month roadmap. I don’t care how smart you are, you can’t spend 4 days at an off-site dreaming up an 18-month product strategy, and just have that be your roadmap for the next 18 months. I think we can all agree, there’s so much bias in that situation, when someone’s dangling money in front of you, to come up with your next story. Don’t wait and do it in batches. At any point, know how what you’re doing affects your next 3 months, 9 months, 12–18 months, and so forth. This idea of continuous activity always corrects roadmap error better than the last-minute hustle and bustle of trying to figure out what you’re committing to.

Like many things, roadmapping isn’t just something you can decide to do in a day, at the last minute, and expect reasonable results. Uncluster and decentralize your roadmapping discussions by challenging teams and product managers to tell you the 9-, 12-, and 18+ month roadmap of the products they’re working on.

What’s one question that you wish more C-level executives asked during strategic planning initiatives?

Assume we don’t do this, what will look differently on a financial report? A lot of PM’s and designers feel like they’re guessing, trying to figure out what the impact of their work is going to be. They feel uncertain, but if you can’t build your belief on how what you’re doing is going to map to a number like that…

UX people often make a great business case like this of the value of increasing UX. ‘It’s going to make it so that people, even when they change jobs, will recommend your product. It’ll increase retention rates, it’ll lower cost of acquisition, it does a lot of things’, but business leaders think of UX as a philosophical thing.

Also, ‘are we going to get caught in a local maximum, and do we need to be taking a smaller number of big bets? How can we create a lot of smaller bets?’ We don’t want people to be drowning in incrementalism.

It’s really easy to get excited about what you’re deciding to build. It’s comparatively harder to really understand the opportunity cost of building all of the awesome features that you and your customers are excited about. John brings up the example of UX, but there are a number of areas that product teams continuously undervalue when it comes to roadmapping.

You obviously focus on experimentation to improve process. What is best practice for improving processes? Who are the most important people to include in the discussion?

I’m biased, and I’ve come to grips with the fact that not everyone in my organization is going to be a process nerd like me.

I was at a company that had a reasonable hypothesis, which was that if you shuffled teams around regularly, that you’d increase productivity and flexibility. The issue was that people weren’t consulted, they were saying ‘I don’t know why we’re switching teams all the time, I don’t know this part of the stack, this is terrible’, what I found is that we need to engage people in that part of the thought process.

People will come up with continuous improvement ideas — in this case someone decided that our number one challenge is to figure out to stay resilient as we scale and how to avoid having people who are specialized in one part of the stack. All someone needed to do is take that to people on the teams and ask ‘how can we experiment to make that happen?’

It’s easy to think of continuous improvement as a management problem, but I propose that there’s a high upside if teams engage in a tempo of continuous improvement every 2 weeks, look at your board, figure out what’s working and what’s not, and look at experiments that you’ve been running. These are less experiments and more interventions. It’s building that at a regular tempo, and having that level of accountability, reporting out how you’ve attained particular goals.

People often don’t see that as the ‘real work’, and that’s when you get into trouble.

What is the leadership-level message that is most important in order to drive a culture of process improvement experimentation?

First thing is that process experimentation has to be a first-class citizen. You don’t just do it for kicks. Our ability to continue to improve relies on our ability to experiment, it’s fundamental. That’s what the company is built for. That leads us to situations such as — if something like technical debt is dragging the team down, that needs to be the most important thing to work on. Teams say ‘oh, let’s dedicate 30% of our time to reducing tech debt’, but that’s crazy!

It’s a boiled frog problem. People complain about nothing getting done, but you know why, it’s sitting right there, yet you’ll say ‘well, we just need to ship some features’.

The trick is how we get to a situation where we can add team members or teams and have them actually contribute to your overall productivity, that’s when you know you’ve nailed it, when you can just start slotting teams in.

If you can’t do that, then you’re just SOL.

Thanks for reading! I’m Jack Moore, and I love writing about building products that can change the world. Thanks again to John Cutler for taking the time to speak with me!

If you liked this, you might also enjoy these: