FATMAP Chrome Extension lets you see a new adventure inspiration with every tab

At the recent FATMAP Christmas Hackathon, one team set out to make it easy to be inspired by the outdoors every day, even when we’re sitting at our desk.

The new FATMAP Chrome browser extension gives you a new adventure inspiration, every time you open a new tab.

It’s free, and you can get it from the Google Chrome Web Store.

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!

Twitter de-emphasises follower count… by making the font 2px smaller…?

From The Verge:

Twitter has made follower counts appear less prominent on its iOS app by making the font size smaller in a new redesign effort, according to a Twitter spokesperson. The change comes after CEO Jack Dorsey repeatedly said that he wants to rethink how the company could prioritize “meaningful” conversations over numbers like retweets, likes, and follows.

I would absolutely love to know how much design time, discussions, debates, arguments and philosophy went into making this change.

Positioning this as a “de-emphasis” in any meaningful way seems quite a stretch to me.

The attention on followers and volume of attention is the product of a decade of social media’s push on attention, clicks, scrolls and feeds. We’ve been conditioned by years of Twitter, Facebook, LinkedIn, Instagram etc to value audience size over quality of conversation.

Wanting to change this is admirable, but it’s going to take more than font sizes. It will mean changing the incentive structures of the products in ways that might hurt growth in the short-term… and that’s still going to be a tough row to hoe for these companies conditioned on growth at all costs.

Innovation in tech is just getting started, says Benedict Evans

When we look around and see the absolute domination of companies like Amazon, Apple, Google and Facebook, it’s easy to assume that the technology boom is over, and that these companies took all the profits.

But a16z’s Benedict Evans has a different take: he argues that tech is only just getting started.

He calls it “the end of the beginning”… the “beginning” being connecting every person on earth to the internet.

In the next phase, we have a new set of decentralised building blocks – such as machine learning and the blockchain – to power a new wave of tech innovations that could target the trillions dollars worth of market share still not captured by the tech industry.

Health care, housing, finance, retail and more… not to mention politics or social welfare.

Watch his presentation from the annual a16z tech conference, which he originally posted on his blog here.

Companies microchipping employees is real – and we should be scared

I just finished reading The Circle, the dystopian view of a world when the next Facebook completely abolishes privacy once and for all. The scariest thing about the book is how real – how possible – it all seems. The world is a few decisions away from being set on that path.

I read today in The Guardian that companies are starting to microchip employees for real:

The tiny chips, implanted in the flesh between the thumb and forefinger, are similar to those for pets. They enable people to open their front door, access their office or start their car with a wave of their hand, and can also store medical data.

It’s super scary. It’s a precedent that leads to a scary future.

How Marty Cagan measures Team Empowerment

Marty Cagan was in Berlin recently and did a talk about why teams are not truly empowered, and what teams might do about that.

He shared his “True Test of Empowered Teams”:

1. The team is staffed with competent people with the necessary range of skills.
2. The team is assigned problems to solve, and they are able to decide the best way to solve those problems.
3. The team is accountable for solving the customer or business problem (outcome).

This is a powerful lens to use to look at a team – either one that you’re managing, or one that you’re a part of – and assess the level of true empowerment.

The framework also fits well with the general idea of using OKRs (Objectives and Key Results) as a tool for managing autonomous teams:

1. The team is staffed with competent people with the necessary range of skills (the pre-requisite for any team to be productive and impactful).
2. The team is assigned problems to solve (ie, OBJECTIVES), and they are able to decide the best way to solve those problems.
3. The team is accountable for solving the problem – which you measure with metrics or other measurable outcomes/KPIs (ie, KEY RESULTS).

Basically this is a recipe for using OKRs to drive empowered teams:

Objective = problem to solve
Accountability = measurable outcome

You can use this framework while evaluating the teams in your company. It could also be used as a tool in a retrospective: the team can each provide a rating, say out of ten, to the extent that they feel they are empowered, measuring each of these three trajectories, and you can track this self-evaluation over time to monitor the trend.

You can watch a recording of the talk here.

Printable sketch sheets for wire-framing by hand

I have always believed that the best place to start when designing a new feature or product flow is with a pen and a piece of paper. I think if you go to quickly to screen/UI design, it’s harder to take a step back to focus on the actual user problem. Instead, you immediately start thinking about pixels and your thinking is by default limited to your current UI.

I just came across these printable sheets for wire-framing by hand. It’s been put together as a side project by Pasquale Vitiello.

You can choose Mobile devices, tablets, desktops, or even just plan grids.

An example of the printable desktop wireframe

An example of the printable mobile wireframe

A photo of a stack of printed wireframe templates with sketches

Software engineers are more valuable to companies than money

CNBC posted an article last week that really resonated with me.

From their article:

A recent study from Stripe and Harris Poll found that 61 percent of C-suite executives believe access to developer talent is a threat to the success of their business. Perhaps more surprisingly — as we mark a decade after the financial crisis — this threat was even ranked above capital constraints.

I’ve been working on recruiting for FATMAP for the past few months. Whether for internal positions, or freelance, not only are qualified engineers more and more difficult to find, it is increasingly they who are alone dictating the terms of their employment.

When I first started recruiting engineers back in the early 2000s, engineers applied for a position. The employer set the terms of the employment. Now, it is increasingly the engineers who set the terms.

It’s no longer companies interviewing candidates. It’s candidates interviewing companies. Companies must convince the employee, rather than the other way around.

This is of course great for employees. But when I look at the candidates coming through, sometimes I worry that this generation of developers are being conditioned by the extremely employee-friendly environment to respond to the wrong incentives.

With so much competition for engineers, is there less incentive for engineers to focus on doing great work and developing themselves…?

There are so many companies with so much capital, which leads to so much competition for engineers, and when the demand for something goes up, so does the price. That price is being borne out not just in salary, but in an expectation of perks and other benefits.

At FATMAP, we place a lot of focus on finding the right people for the team. We look for missionaries rather than mercenaries. We want people to be in it for the mission; people who share our values but most importantly who believe in our company and want to share in our success.

We believe that building the most talented team of missionaries is the key to success. We’re not climbing on the mercenary engineer treadmill.

I only hope that the next generation of new software engineers follow incentives to build great products that customers love and that make a difference – and don’t just chase the big money and free snacks.