Interview with John Cutler: Multiple hat-wearer and product development nut

I’ve been reading John Cutler’s writing for a while now and been fascinated by his ability to turn complex topics into simple principles. His posts often remind me how easy it is to overcomplicate things and how stepping back helps us avoid that. John’s blog posts are great at helping you step back.

Interviewing John was not going to be easy — there were too many things I wanted to cover. In the end I decided to pick a few of my favourite posts of his and find out about the experiences that inspired him to write about those topics. We ended up talking about change management, psychological safety, product team dynamics and much more.

Here’s my conversation with him:

Sofía: John, tell us a little bit about yourself. How did you get started with product management?

John: I actually got involved in product management a little bit late. I spent my twenties playing music and touring the United States but I also did a startup. We made a bartending video game where you learned how to mix drinks. You would shake the mouse and it would shake the cocktail shaker and things like that. It was fun.

Later, I got more involved in startups. I went from business analyst to product to UX research then back to product. It would have been nice to be at one place for four or six years but that’s just not how it worked out for me.

Most recently, I was at Zendesk. That was good. I was working in search, which was fascinating. Before that, I worked at a company called Pendo in Raleigh, North Carolina. That was very rewarding because my customers were product teams so not only did I get to talk to them as part of my job, but they would also send me to talk at Meetups, which got me really involved in speaking and writing. I find it very fulfilling and will continue doing it alongside my next adventure.

Sofía: In your post, Battle for Change, you wrote:

‘You’re likely to encounter resistance and it is easy to stereotype this as ‘resistance to change’. Sometimes the resistance IS a case of risk aversion. But if you observe carefully, you’ll observe that what seems like change intolerance is actually a battle (and perhaps a stalemate) of change agendas. People want change but they (leaders especially) happen to believe in different types of change.’

How can product leaders work through the resistance? What do they need to know and do?

John: My writing tends to come from the perspective of someone who has changed a lot in their career and had a lot of unpredictability in what they were doing. For that reason I’m very change-tolerant and am usually the person saying, ‘We’re all talking about this. Why don’t we give it a try?’.

I think the first thing is to understand that everyone has a point of view on what change means and you can’t necessarily assume that everyone around you has the same appetite for shifting, reinvention or disrupting.

You need to understand your own appetite for change and how that relates to your own identity, career and the people around you. Don’t assume that the people who look like they’re dragging their feet are afraid or inexperienced. You have to talk to them to find out what their vision of awesome is.

I say that because I work with a lot of people who will say, ‘Oh, this is a little bit too much change at once’. And I’ll say, ‘Oh it’s not. Let’s go for it’. But they’re actually right, which brings me to what I call ‘promises in progress’. These are the promises you’ve made in your organization.

A promise can be very small. It can be you saying to someone in your company, ‘We’ll look at that next year’. Now, that doesn’t seem like a promise but it is. That person might really be looking forward to next year. It can be promises to your team. It can even be the values of your company.

The reason why this links back to change is that we don’t think about the changes in progress. We don’t think about the amount of stuff we’re actually doing. From a very practical perspective, I’ve seen companies keep a change board, like an experiment board. And they agree that on any given month or quarter or whatever, they have one big item of change that they all agree on plus maybe one or two smaller ones. They run experiments to see if they can improve that particular piece of change but they’re not trying too many things at once.

I see that mistake all the time, especially among leaders who are pushing change from the top down. You’ve got business as usual, all the commitments, all the promises you’ve made and then suddenly people add this. Everyone becomes completely overloaded.

Leaders need to limit the change in progress and engage people in the ‘why’ of the particular change. Invitation versus imposition. Imagine a CEO saying, ‘I’ve hired these consultants. They’re teaching us Agile or they’re teaching us this about product’. It’s very different than saying, ‘What I’m seeing is this. And what I’ve heard from you is this. I want to engage you in trying to figure out the best way forward. If it’s consultants or coaches maybe you could pick some that you’d want to bring in and learn from’.

Summing up: Self-reflection, reflecting on those around you, limiting change in progress, considering the promises in progress and not overloading the team. Invite people to be part of the solution not just to implement it.

Sofía: Speaking of change, one of the first things people tend to change is the way they execute on their sprint planning. In One Story Per “Sprint” you touched on some of the arguments people get into when they’re not ready to experiment with new ways of delivering product. In the post you say:

‘What is hard is trying to create the semblance of productivity and looking busy. And dealing with the legacy way of working.’

Could you tell us a bit more about the idea of delivering very small units of value in short periods of time? What are the benefits of working this way?

John: If there’s one thing I’ve been fascinated by these last couple of years is that exact question: What does it take to make it safe to be uncomfortable about these things? I’ve broken it down as follows: You have to learn how to work small but you need to think big at the same time and then you need to inspect and adapt.

For example, working small with code has advantages but then all the UX folks and design folks will say, ‘How can you do that? It’s not valuable for the customer’. They’re not appreciating the value of working small. You have to do both. You have to work small and then you have to appreciate that your big picture has to work with that too. And then you need to inspect and adapt to see if it is working.

I like cycling and I like training. When I’m training a friend, we never start the season by going out and riding as hard as we can. You pick a sustainable amount and work from there. So why do we think, ‘What’s the most you can get done in a period of time?’ and then get everyone to commit to these deadlines and that workload? It doesn’t make sense.

I think managers think that people won’t work hard unless they are pushed. They won’t hit deadlines and teams won’t keep themselves accountable. And so the big leap there is to think about it from a pull perspective, like, ‘We only have so much bandwidth. Let’s get the customer to pull us with what they need and then deliver small’.

Sofia: You seem to be very interested in the topic of Psychological Safety within product teams. Can you tell us a bit more about that?

‘An organization that establishes safety as a prerequisite and experiments together will improve together, and win together’

John: I went out and asked a bunch of people what they do to create safety. I got 60 or 70 responses so I wrote a post about it.

I’m involved in this Modern Agile thing and one of the four principles is safety as a prerequisite. If you go into a meeting with executives and you mention it, everyone understands. Everyone nods their head but the reality is that the steps to get there are hard. It’s about being vulnerable and it’s not easy to get there.

Amy Edmondson, Associate Professor at Harvard Business School, wrote a paper called Managing the risk of learning: Psychological safety in work teams. She studied nurses and other people in hospitals — really high pressure places — and she talks about principles like the leader speaks last, modeling the behavior of things, admitting you don’t know about stuff… I thought a lot about the type of people I feel safe around. Often they’re happy to admit they don’t have it all figured out.

We all know what it’s like, especially in startups because startups are usually based on an assumption. If that assumption was 100% true, everyone would be doing it, right? So the core assumption is always a little risky. It’s a bet. And what happens is that people, especially when talking about data or Lean Startup or any of these things, will start saying: ‘We need more data to prove what we’re doing’. What they’re really saying is, ‘I don’t feel good about this assumption’. For example, early on you might have to choose between bringing in sales or more of a self-service model. There are many of those kind of core decisions that every startup makes.

Now, once you go down that road, that’s it. You’re going to have to sit with that decision for a while to make sure it works out. What I’m trying to say is that I think in the startup world especially, one way to address safety is to be very transparent about the bets you’re making. And I think that people are scared of doing that.

I remember talking to a head of sales and saying, ‘I’m going to do this presentation that talks about all our bets’ and they said, ‘Oh, no, I can’t have you do that because I need every sales person to drink the Kool-Aid and believe that everything’s going to work out’.

I think that trying to be very open, talking about the bets and thinking of them as experiments helps address the elephant in the room. And I think the elephant in the room is the main reason for lack of safety. It’s not people being mean to each other, talking over one another or arguing.

When the CEO goes down a certain path and no one thinks it’s the right path, it creates really poor psychological safety. I’ve heard discussions on Slack channels, every back channel, over coffee… People say things like, ‘I don’t know what’s going on. The VP of Sales is not doing their part and this thing is going down the drain’. You can’t have that in your company.

Personally, I’d much rather go into a startup and hear someone say, ‘Hey, this thing might explode in eight months but let’s go for it’. I remember when a CEO said to me, ‘If this doesn’t work out, my goal is to make you successful in whatever you do next’. It was transformative. I knew he had my back and, if things didn’t work out, he would give me a referral. It was a huge thing.

Sofía: John, from your perspective, what does it mean to be customer-centric?

John: A lot of data-driven products are very aspirational at the moment and want to use all their metrics. But you run the risk of trying to do everything for all of your customers. I think that’s a huge issue, especially with venture-backed companies or businesses that are trying to grow like that — their whole premise for investment is that the business is going to expand beyond its walls. The tendency is to think that every time you cater to a new customer archetype or persona, you’re somehow validating your ability to go beyond your walls.

I think customer-driven startups become compromised by the funding system and the growth imperatives of that environment. People will say they’re customer-driven when, really, they’re trying to hype up the startup. How your company is funded can have a massive impact on your methodology regardless of the principles you set out with.

It’s funny when someone says they’re customer-driven or customer-obsessed and you find they have one UX person for seven or eight teams! Being customer-centric means hiring people. It means investing in the thing they’re doing.

Something that’s dangerous, I think, is when people treat their customers really well but their employees like shit. I don’t think you can be truly customer-driven unless you consider the health of your own people. You can fake it for a while but at the end of the day you have to ask: Are you giving them career opportunities? Are you allowing them to move up in the organization? Are you giving them new challenges? If you can’t do any of that and you’re customer-driven, you’re not going to stay customer-driven for very long.

Interested in learning about customer-driven development? Visit EnjoyHQ for more information and tips to harness the power of customer research.