Jon Moore: Focus on problem solving, not features

Do Thu Trang

Heureka Group’s product development stakeholders attended an eye-opening workshop organized by the Silicon Valley Product Group (SVPG). The intense event led by Jonathon Moore helped us develop and encourage a culture of product discovery that is the hallmark of modern product organizations.

If you don’t know Jon, he passionately believes that the customer should be at the heart of product development. He has left his mark in management roles at consumer-oriented giants such as Microsoft, Skype, and the BBC.

In this interview, you'll learn from his insights and experiences about sustainable and effective collaboration between product managers, designers, and engineers, who together can create EMPOWERED teams, the single-most-important prerequisite of a successful company. 

What made you become so enthusiastic about product and product development? Was there a specific moment or experience when you realized this was your dream job?

As a teenager I’d been engaged in technology (I remember well programming numerous very basic computer games in my teens) but hadn’t made any real connection that it would be useful. And I had no concept that it could ever relate to a career. This was the late 80s and so it took me a while to understand that these skills would end up becoming a core part of my career. The truth is also – I got lucky.

I worked at an organization that invested very early (the BBC early 90s) in digital technology and I immediately saw the power of the medium and the power of the two-way conversations that were possible. Being able to engage people on the other side of the world – in seconds – was extraordinary. It felt like a whole new world had opened up and I wanted to be a deep part of that. 

As an experienced advisor, what are the biggest differences between Europe and the US when it comes to approaching product development? Are there any at all?

The major difference between the US and Europe is the level of exposure senior business leaders have to strong product and technology cultures. For many organizations this side of the Atlantic, the leaders have no idea what is possible.

Thinking is much more constrained and while some don’t like to publicly admit it – technology is thought of still more as a service to wider stakeholders and the organization in general. In the US, there is a much wider recognition that technology is the key asset we have in delivering strong value to customers and the business. That said, things are changing. 

There is a new breed of leaders, many of whom have worked at Google, Microsoft or Ebay or similar who expect to work with empowered engineers and product managers. But we are behind, no question, and the gap is growing. It’s frustrating to watch, especially when the evidence is all around us that powerful technology companies are very clearly the same organizations achieving the single most value for shareholders. 

What’s the main talent or skill that a good product manager should have, or is there something they should really focus on?

My favourite definition of a product manager is „smart folks who know how to get things done“. That’s from Merissa Meyer and it holds true. Forgetting about smarts for a minute, it hints at a strong bias for action and grit – you don’t give up until you’ve completed the job. That counts for a lot. I see a lot of shared characteristics in the best PMs, yes they are smart, but more importantly they are good communicators, very data-oriented and understand that they have to be real experts at understanding what customers truly need

They work hard to take the business with them but they’re also not afraid to stand out. Many of the best people I work with have all taken some risk, pushed ahead of their environments, and therefore showed what is possible. Even if that’s not expected or the organization has attempted to reign them in. A bias for action and results really shines through.

Source: Jon's Twitter; @moorej

One of our takeaways is “Focus on problem-solving, not features.“ What’s the most important question to ask when discovering the real problem?

It’s not a single question, it’s never that simple. But it is a dedicated understanding that you are there to solve some element of pain for customers (and/or the business). We only ever get to see that by spending some real amount of consistent time with customers and figuring out the patterns. 

But some basic questions will always help: „What are you trying to achieve here?“ or „What problem are you trying to solve for yourself in doing this“? „What is wrong with the solution you see here?“ „Why is this a better way of solving your problem than competitor x, y, z“ are all good ones. Dig deep and keep going.

Looking at all the teams you’ve talked to, what’s the most common mistake or misconception that experienced product managers have about their product? Is a roadmap always a „road to failure“? 

Roadmaps are harmless in and of themselves but it’s the way most approach them and use them that causes so much harm. Unvalidated feature-based roadmaps really are one of the main causes of so much waste. You heard me call them a „prioritized list of ideas“ and that is really a more accurate description. It’s just so arrogant to assume our ideas will work and it betrays an extreme lack of understanding of how difficult winning technology products are to create

If roadmaps have been validated or focus on solving real problems or leave a necessary level of flexibility to react to changing circumstances and learnings that I’m very ok in using them. But most execs love the certainty of dates. Sadly they aren’t asking the right question which is: „even if we bring this in on time – will it even work?“

How do you balance focused hard work vs. unsustainable overload?

Most (but not all) unsustainable overload comes from not taking enough time to plan a working week. More and more I see vague meetings being scheduled with limited outcomes or decisions made, requiring yet more vague meetings being run. And that eats up a mighty portion of everyone’s time. 

So the first answer to this question is that you have to realize it’s all of our jobs to limit the time people spend on unfocused work. As an engineer or a designer or a PM I’m thinking (every week) what % of my time am I spending on validating my work? If that number is low, then I have an absolutely critical problem I need to solve.

Mostly I can solve that myself but sometimes I will definitely need the support of management. I find that most folks don’t even ask the question, or don’t look at their diary and say „which of this is critical and which is secondary“? We need to do that because no one is going to do it for us.

That’s on us. So we have to go do it. Management also plays a role in this of course, so as a leader I need to feel my employees will hold me to account if the culture is off in some way and the days are full of activities that don’t result in strong value creation.

When should teams and companies acknowledge that they need to pivot or a revision of their product? 

This is a very broad question, pre-PMF it’s all for nothing if we can’t achieve strong evidence of value creation for customers. Nothing else matters. So I would expect strong discovery pivots in all companies or teams who are producing new products and bringing those to market. That’s normal. True company pivots are much less common (because they are very very hard). There are only a handful of organizations that have successfully transformed across very different segments or have pivoted their missions

Normally because it takes them too long and a competitor eats their lunch. This is really where Product Vision becomes a strong asset. If our vision is solid, that means we truly have a dedicated understanding of the problems customers have and we can build solutions for those over time, flexing as we go.

When it comes to revisioning, if you’re testing your solutions against competitors and consistently coming up short and your base KPIs are looking unimpressive (all of which you should, of course, be monitoring and testing against regularly) then that would be a real red flag for me and an example of needing to think differently and taking some risk to re-focus our efforts. The point being we can’t get to that stage, we need to consistently test and validate to get as far ahead of that curve as possible. 

How often do you come across mature tech companies that don’t have a functional product development process; they don’t discover, prototype, or test enough?

This is more common than I would like and it appears to happen mostly because they have changed the management or leadership. I love to hate Oracle – and it’s not uncommon that they’ve had a senior exec from Oracle (or similar) who says „we need to do this, show me the roadmap and get it done ASAP.“ So the team reverts and becomes feature-driven or delivery-driven. And they develop a huge Product Ops function or strict Programme Management function with an extreme desire for process. And then five years later they realise they've lost a big share of the market and their best engineers.

SVPG Workshop for Heureka Group: How to Create Tech Products Customers Love

What are the most important next steps that companies should take and implement after completing the SVPG workshop? Are companies successful in doing so?

This comes down to desire and (again) leadership. Changing the way we work always requires transition. I think it’s critical to obsess over the key ways of working that we need to achieve real success: meaning a dedicated and strong exposure to customers and users and a deep desire to validate our risks before delivery – using prototypes.

That’s honestly not so hard – but it does mean changing things. So we need all that to happen with immediacy. If we can commit to that we can change pretty quickly. I’ve been working with a pharmaceutical company that has been the epitome of delivery-oriented for years (the great irony being on the practitioner/medical side they deeply believe in test and learn and strong validation to produce the medical drugs – this is the very basis of science). 

But they’ve run their own technology org as a service and they've been mediocre at best. Honestly, they’ve invested tens of millions and had no success at all – for years. In 18 months post workshop they have completely reset the culture and just recently launched a new suite of software products that are gaining very significant traction. The hard work starts post workshop and it requires focus and desire and grit (that word again). 

And to close our interview with something less work-related, what is your favorite product right now? 

I’m going to say Wise (formerly TransferWise). They consistently remove subtle frustrations when it comes to x-border banking and I’m more and more impressed with their ability to poke away at very hard problems and solve them in a completely frictionless way for customers. I fully appreciate this comes at huge costs to the teams, who are solving some very hard, real-time problems, but none of that is exposed. They definitely do the hard yards and it's impressive.

Useful links:


Do Thu Trang

Trang manages the tech community at Heureka. She likes to work with texts and connects technology with creativity. She loves pho soup, dancing, and people who don’t take themselves too seriously.

<We are social too/>

Interested in our work, technology, team, or anything else?
Contact our CTO Lukáš Putna.