The Knowing / Doing Gap: Why Product Teams aren’t doing the things they know they should

Access to high quality resources for product management is better than ever before. There are so many excellent people writing about product management that it’s easier than ever to find the knowledge that you need.

So why are there still so few product teams actually working in the ways described in all of these resources?

When I talk to other product people, I see the same thing again and again: Most PMs can talk convincingly about the benefits of and process for anything from customer discovery techniques, growth accounting, data driven validation, lean startup techniques, etc etc. But when I dig deeper and ask how much of this stuff do they are actually doing, the answer is too often something along the lines of “oh, we haven’t really started that yet.”

I call this the knowing / doing gap. 1

Knowledge about great product management practices is cheap. It’s available everywhere online and in countless books… knowledge is no longer your competitive advantage as a PM. Your competitive advantage is in actually doing it – and doing it well.

Why don’t more product teams do the things they know they need to do?It turns out it’s very easy to know you should be doing something, but then not do it. 

Why is this? Aside from the psychology of procrastination, I have a few theories:

Doing these things is hard

Doing customer interviews for example requires you to go outside the comfort and safety of your office and talk to real people. Many people find that really hard… but with customer discovery, it’s as unlikely as ever that the right answers are in the building.

Doing these things takes time

It’s easy to fall into the “we don’t have time to validate this” trap. Running a usability test on this prototype might take a few days, and we need to ship it next week! If we validate it we’ll be late!

It’s true: validating something, from a product idea to a user flow, takes time. But would you get behind the wheel of a race car if the mechanic told you, “we didn’t have time to test the brakes or the steering”. I wouldn’t; but that’s what you’re doing when you plod ahead shipping production code for an idea that’s never been validated.

One of my favourite quotes from Peter Drucker is:

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all.”

Product Teams don’t have autonomy

I wrote about autonomy recently after Marty Cagan did a talk on the topic here in Berlin.

When teams are set up to deliver the feature list as proscribed by a Head of Product or CEO, then validation work feels useless. The ultimate success or failure of the product rests with the CEO. Right?

Well; I always argue to people in this situation that the best thing that you can do is run the validation anyway. Bring your findings to your Head of Product or CEO and discuss them. Either they will applaud your initiative and encourage you to run more validation; or they will deny the results and tell you “we’re doing it anyway”.

(If the response you get is the second, I would encourage you to find a new company.)

How to get started

At the end of the day, there are seldom really good excuses for not doing better customer discovery and product validation. Resources and knowledge are plentiful. The only thing that’s holding you back – is you!

A simple way to start building a validation mindset: every time you find yourself looking at a product feature or solution you’re planning, force yourself to step back and ask these questions:

  1. What is the problem we’re trying to solve?
  2. For whom?
  3. How do we really know it’s a problem? 
  4. How do we really know this solution is the optimal one?

A validation mindset is all about moving from “I think” or “I believe” to “I know”. The first step is just asking the question: “How do I know?” 


1  I’m not the first person to use the term “Knowing / Doing Gap”. There is at least one book with that title and an article from Stanford Business from 1999. 

Christmas Hack Day at FATMAP

At FATMAP we celebrated Christmas last week by getting the whole company together for two days here in our Berlin HQ.

We started with a one-day Hackathon. We started with idea proposals, and teams quickly formed around the most interesting and creative ideas. There was only one rule for a hack day proposal: you had to be able to tell us how you were going to measure the result. If you can measure it, it was fair game.

The results of the day were some incredibly creative and interesting ideas. Among the projects:

  • a new Adventure Search bar
  • a Chrome extension to introduce you to a new inspirational adventure destination every time you open a new tab (currently awaiting approval in the Chrome extension store!)
  • tile platform usage analytics data visualisation
  • a proposal for a new FATMAP Premium safety feature 
  • a very interesting and creative way to answer the question: “Can I make it back before it gets dark” 

The best thing about a Hackathon day is the energy: the room was full of it and teams were busy hacking, discussing and working together.

You always wonder: why isn’t every day like a Hack day? 

My theory is that hack day teams work well together because:

  • there is a clear goal that is shared by the team – the team has a high level of shared understanding about what they are trying to achieve, and why
  • the idea normally came from within the team so there is a large level of inherent ownership
  • teams are cross-functional – good hack day teams bring together people from marketing, product and design into one team that works end-to-end, from idea, to solution planning, to execution and delivery
  • teams are autonomous 

We’re making some changes to how we work in 2019 to make it easier for teams to work more like Hack day teams. We’re shifting the FATMAP Product Roadmap to be more focussed on prioritised and validated user problems, rather than a list of features. (Much has been written about problem-based roadmaps; this is a good start). And we’re focussing more on building autonomous, cross-functional teams that can deliver product value end to end.

We strongly believe that small, autonomous teams with a clear, aligned vision build better products – and this week’s Hack day has definitely shown  that.

Note: the photos from this article were taken by our Community Manager, Jon Williams.

Ways to think about working smarter (not harder)

When Reid Hoffman talks about building a startup, he says it’s like jumping off a cliff, and assembling a plane on the way down. It’s a reference to the fact that when you start building a startup, you set a clock ticking. 
If you can find product-market fit and a viable business before the clock runs out, your startup has a chance of success. If you can’t, then you’re in for a hard crash landing.

That’s why for startup product teams it’s critical to move as fast as you can. The most valuable resource you have is time, so you need to be extremely wise with every hour you and your team spends.

The key to moving fast is not to work harder, but work smarter. It’s not about working weekends, skipping lunch or pulling all-nighters. It’s about making smart choices about how to get things done.
Here are a few ways to think about moving fast.

Stand on the shoulders of giants

Isaac Newton famously said: “If I have seen further it is by standing on the shoulders of Giants.”

When building a product, don’t be afraid to borrow from solutions that already work. Steal what you can with pride. Look for existing patterns and use them. Don’t waste time re-inventing the wheel, especially not in areas that aren’t key to your differentiation. 

As Picasso said: “Good artists copy, great artists steal”. 

Rethink the constraints

Every project has constraints. For an artist that might be the size of the canvas. For a technology product it might be the business model or the underlying technology. 

But not all constraints are equal. Some are very hard, and others are flexible. 

Look at the constraints you have and ask: which ones are flexible? Which are not even constraints at all?

Can you simplify the task by challenging one of the constraints?

Do the simplest thing first

Alfred Einstein said (approximately): “Everything should be made as simple as possible, but no simpler.”

Complexity is the silent killer of products. Complexity is a poison that spreads lethargy and chaos in your startup. The more complex your product, the harder it becomes to maintain. Avoid complexity at all costs.

Always start by doing the simplest thing first. Ask this key question: What is the smallest, simplest thing we can do that will validate our hypothesis and deliver value to our customers? 

Ask for help early 

I’ve seen people (and whole teams) bang their head against a hard problem for days, or weeks, without asking for help. Sometimes it’s a mix of stoic determination and pride; sometimes it’s that feeling of being ever-so-close to cracking the problem… for days and days on end.

Productive people know how to ask for help early. Whatever the issue is that you’re facing, the chances are there are people out there who can help you. Sometimes a point in the right direction is all you need to unblock yourself and save hours or days of wasteful wheel spinning. 

First and foremost, use your colleagues. Don’t be afraid to ask more experienced team members for help early on. It’s not your job to know all the answers; it’s your job to find the answers. There is no shame in asking for help! It’s how great people learn. 

Second, build your network outside of your team. This could be in your company, or outside it. Find the networks, groups or meetups in your area of expertise, and use them.

If you have any questions or would like some more detailed tips, get in touch!