Jonny Schneider helps digital product teams learn faster

Jonny Schneider’s product management and strategic expertise is unarguable. He’s worked with leaders at places like British Airways, Origin Energy and Standard Chartered, and he’s collaborated on products for Amazon, Telstra, National Australia Bank and Mazda. Not that he drops names in conversation. He doesn’t need to.

Instead, when you talk with Jonny about creating successful digital products his experience just shines through. He brings a realistic, dogma-free sensibility to the complicated world of building better things. It feels like honesty, not false modesty, when he explains that he’s built up knowledge “mostly through failing a lot, that’s the short answer.”

Last year Jonny founded Humble Ventures, a “proudly uncertified” vehicle for his consultancy and coaching. He’s an outsider-for-hire who helps companies do away with perfectionism, move faster, and feel their way towards the right path. Not chasing best practice, but achieving better practice.

Speedy learning cycles: “Figure out how to be wrong faster, more often”

“The cold reality of the way product success happens is that most of the time you're wrong, no matter how hard you think,” Jonny says.

In the workplace this means that teams who pour time and energy into making perfect-as-possible decisions, and laying down concrete product roadmaps, don’t usually end up making the most successful products.

“There is an expectation that if you do high quality analysis and make decisions with good synthesis and knowledge and thinking and gut feel and all those other things, then you're going to win,” Jonny says. This ignores how unpredictable users and markets can be, but a lot of companies stick with it - “usually due to fear of failure, ironically.”

This is why a lot of Jonny’s work with product teams comes down to adjusting the way they approach decision-making. “The fastest way to be successful is to figure out how to be wrong faster and more often, and to do it in a way that gets you away from wrong to right,” he says. “My goal is to make the cycle-time of learning as short as possible.”

I’ve probably had a dozen clients now, in different contexts around the world, who have said that product innovation is a first class consideration for the company and they have big aspirations. But then it takes six months and costs half a million dollars to get through a cycle and learn how successful an idea is.

Sooner or later one of those carefully-conceived ideas isn’t going to work out. “That’s a ‘we did everything right, we still failed’ moment,” Jonny says, “and it’s not tenable.”

Rather than a series of big investments, he believes that product development works better as a series of experiments. As he puts it, “designing and building real software and launching it to market is the slowest, most expensive experiment you could ever run, right?"

Thinking in weeks, not months

“So let's think about this in a different way and see what we can do in six weeks. Enterprises often haven't worked like this before, and it's really exciting to help them see what's possible. On Monday, find the most risky assumption that we need to learn something about. Tuesday: How are we going to go about it? What's the right experiment to help us learn that thing? Wednesday, design the experiment and prep for it. Get it going on Thursday by talking to customers and seeing how right or wrong the responses say we are. By Friday you can work out the next decision we need to make and what we’re going to do next week," Jonny says.

“You can rinse and repeat that cycle, but not for not too long because it can be exhausting and unsustainable. More often than not in about six weeks, when you've sometimes spent nothing on these experiments, you've got enough information about your assumptions. Usually the outcome is that you were more wrong than you thought, but you're not guessing anymore. You get real information to base the next decision on and enough evidence to see whether there's something here that you should build.”

Ideally you’ll have found plenty of reasons to go ahead with the product work that you’ve started. But a negative result can be valuable too. “A lot of times what you hear at the end is hard to hear but hard to ignore. So you shelve the idea and you’ve saved six months and half a million bucks.”

Learning faster: “It all comes back to the way you make decisions”

If it was easy to work at high speed and deal with the failures along the way, we’d all be doing it already. So what do product teams need to do differently?

“It all comes back to the way you make decisions. A lot of people will already be familiar with the book Thinking Fast and Slow by Daniel Kahneman, and his fundamental idea of two decision-making systems. System One is instinctive, and fast, and almost automatic. It’s a reaction to a situation and decisions happen almost unconsciously. System Two is deep analysis, with a lot of thought and breakdown and consideration. It’s a slow style of thinking.

“In business, people tend to treat everything like a System Two decision, but the reality is that most decisions are quite safe to make with System One,” Jonny says.

This is true in companies of any size. “The way that Amazon interprets this is to talk about ‘one-way’ and ‘two-way’ doors. A ‘two-way’ door is a decision where you go through, see what's on the other side, and if you don't like what you see you can just go back and pick another door. One of the fundamental characteristics of digital product development is that it's malleable and adaptable and you can change it. Most of your doors are going to be nice, safe two-way doors,” Jonny says.

“One-way doors are decisions with significant and irreversible consequences. Once you've committed you can't just turn around and change your mind. In Amazon’s context an example of a one-way door decision is launching amazon.com in a new geography, like when they came to Australia. That’s high commitment! You're gonna do a lot of deep thinking and analysis to make sure that that's the right direction to go in.”

One key here is to build the turn-around point into a decision. When you know how and when you can retreat back through a two-way door it is a lot less scary to poke your head through.

Jonny says, “The problem in a lot of product teams is a belief or assumption that decisions aren't reversible. Then every decision needs lots of analysis and thinking. It's really slow, and it’s how teams get stuck in months and months of product discovery on a bit of value that takes two sprints to deliver. It doesn't really make that much sense, right?”

When you see two-way doors for what they are, you can avoid those months of dithering. It’s quicker to test assumptions and revert the ones that don’t work out. But not every assumption is worth testing, and not every test design is equal. Jonny stresses the need for clarity as teams set expectations, choose which metrics to use, and define the indicators of success that the experiment will attempt to produce. It’s much more directional than just moving fast and breaking things.

“I’ll direct teams down paths. We won’t be sure if it’s going to work, and we might be wrong, but we try it and see what we can learn to get us closer to the right path,” Jonny says.

For anyone leading your own product team, “My advice is to think about the nature of the decision you're trying to make and to have enough confidence to go back through the door when you get it wrong.”

It’s advice that Jonny wishes he’d received earlier in his own career.

Mobile apps before the iPhone: “There wasn’t much advice”

“I spent at least the first half of my career believing that success is about making better decisions. It took me longer than I would have hoped to reach a turning point and figure out that although process and method is helpful, it's not enough.”

“There have been occasions where we did everything ‘right’, in terms of careful decision-making, but still had an abject failure. Imagine how devastating that was! After a few of those I realised that doing everything right is not the game. It doesn't matter what framework you use. It doesn't matter what approach you take to customer innovation or product design or software development. None of that stuff matters at all because there's no right way to do it. So I then started to think, well, if that's the case and things that worked in the past don’t work anymore, how do I need to change my mindset?”

The mindset that Jonny set out to change had its roots in the first product team that he worked in. Back then, it made sense to hunt for the best tools and methods because, as Jonny remembers, “we were trying to do things that didn't have a name or a playbook yet.”

“In the mid-00s I was a couple years out of university with qualifications in computer science and design. I was Juniorburger in a company called Sensis, part of Telstra. My role was best described as a generalist, and it was an experience that really got me started on the way to product management. I was very fortunate to find myself surrounded by people who were very early adopters of things like agile software development principles - things that I was all about, too - and who were also a fair bit ahead of the curve on user experience.

“We were building products for mobile phones in a time before the iPhone. Web browser apps using WAP technology and 2G networks, and native apps that Telstra would pre-install on devices before they were boxed up. The technology was advanced for the time but it came with loads of constraints. Screens were tiny, input was difficult, touchscreen didn't really exist yet.

“We were trying to figure out how to integrate user-centred design into the agile product development lifecycle while building mobile products and services on very limited technology. There wasn't much advice around on how to do this, so we were very much finding our own way forward,” Jonny says.

That way forward crystalised years later, when Jonny - still in his “tools, process, and method” phase - wrote a short book called Understanding Design Thinking, Lean, and Agile, which remains available as a free download.

“One of my reasons for writing a book is that I have a pretty good knack for explaining complicated things in simple ways. I have a general curiosity about how things work, too, an intrinsic motivation to understand stuff, and I've more or less built my career on that. I feel like three quarters of my job today is understanding complicated things, then explaining them in the ways that my mum can understand. So the book came from there.”

Getting hired to make mistakes: “Nobody wants to buy failure”

Jonny’s consulting work has seen him operating as a “translator” between company leaders and the teams on the coalface.

He says, “One of the things that I’ve become pretty well known for over the years is kind of translating between different groups. Being able to understand what engineers are trying to achieve, and how they think, and what kind of conditions they need in order to do their work; then likewise working with designers, who didn't always have deep technical knowledge, and helping them understand the constraints that we're working within. Then explaining all of these things back to the business so we can all see where the boundaries are and what a solution could be.”

The freedom to sometimes be wrong, which is pivotal to Jonny’s view of product success, gets less attractive the further you go up an organisation’s structure.

“In some ways, it's kind of easy and acceptable for a designer, engineer or even a product manager to make a call that goes wrong. The reaction will probably be that things go wrong all the time, mate, that's how it goes. But I don't think leaders give themselves the same freedom or space to get things wrong. They’re thinking, I'm 30 years into a career and I've got a reputation to uphold of not making mistakes and growing businesses in significant ways. I'm successful!

“Individuals in executive leadership teams don’t believe that they got there by mistake. The default behaviour is to be diligent and thorough, and to do things that have worked in the past. It’s hard to switch your story to, ‘I'm gonna help us fail quick’. Nobody wants to buy failure,” Jonny says.

So he’s put his translation skills to work. “I talk about a set of movements that help people identify big assumptions and learn things about them quickly, so they can get more information and make better decisions.”

Strategy and narrative: “Why are we coming to work today?”

Once he’s found a way to talk with the people at the top table, there’s a common set of problems that Jonny sees.

“There’s often a lack of clarity around product strategy, or business strategy more broadly, which makes it very difficult to maintain alignment. There’s meaningful work to do there so teams don’t execute the wrong missions and achieve the wrong outcomes,” Jonny says. Not that he’s becoming a management consultant.

“I've done stuff across domains like healthcare, automotive, retail, Government...and I’m not an expert in any of them. Organisations don't need a new strategy from me. They've got their own experts, but usually the strategy is stuck in their heads. The problem is translating the strategy, and making it actionable.

“With scale-ups or growth stage startups lately, I’ve been working with executive teams to hear and understand all the things. Then my role is to turn it all into a strategy artefact - often a short, six-page document that reflects what they believe is important and the direction that they want to go in. I think of the document as a Product Narrative.”

Product Narratives

Jonny’s written up a thorough breakdown of Product Narrative documents on his own blog, but briefly there are four sections to cover:

• A background that looks at the business itself, who its customers are and what problems they have. “This usually needs empirical data and evidence to set the scene for the game you're playing,” Jonny says.
• Thematic observations that identify specific opportunities and shape the action we are going to take.
• Initiatives that are distilled from those observations. This isn’t about product features, but what the business wants to achieve. “How are we going to pursue and exploit the opportunity, and what outcomes do we expect? How do we think we're going to get there? How do we invest resources like people’s time, and what can we organise around?”
• Finally, an appendix for any supporting information, references, etc.

Jonny says, “The Product Narrative makes the executives’ thoughts accessible for the teams and individuals who are executing the strategy. It becomes a core product management artefact, because it clarifies why we are coming to work today and what we want to achieve. With a direction and a set of expected outcomes, the team can begin rapid experimentation. What's the smallest thing we can do to learn whether we're going in the right direction, and then repeat to get there? It lets teams see how their day-to-day sprints make the strategy come true.”

One huge benefit here is that senior leaders can be more hands-off. “You need a really clear strategy to create autonomy in teams. Moving away from a command and control management style is not trivial! It sets you down the road of doing some kind of digital transformation or product-led transformation,” Jonny says.

As much as Jonny enjoys thinking about the full-sized picture of organisational change, he wouldn’t want anyone to overthink things or lose sight of the most important goal. If your company can find its way to lose the fear of failure, run shorter cycles of experimentation, and learn quicker lessons, then you’ll be on a better path to product success. And if Jonny’s advice helps you get there sooner, he’ll take that as yet another win.