In 2007, I was lost. Not existentially, just geographically. I was somewhere in northern Italy, wandering through narrow and unmarked roads. This was still roughly the pre-smartphone era, and my “learn Italian by singing” CDs proved less useful for communicating than for embarrassing myself.

Of course, it is only in retrospect that we know we are lost. At the time, I was iterating toward success. This piazza is definitely that one on the map, which means my hotel is around the next corner. Nope. But that clothesline looks familiar…

Scoping new features for an app is a lot like exploring a new city—roadmaps are great, but without a pinch of humility and a fix on your current location, chances are you’re headed in the wrong direction.

Lost and Found

What does it mean to “know where you are” in product development? One way to define it: understanding why you’re making the decisions you’re making.

→ What mix of gut feel, pressure from Sales, and user feedback went into the team’s decision to add AI-assisted writing tools to our product?

→ Are we going all-in on gamification because our competitor did, or because of something we observed in how people are using (or not using) our app?

At Steamclock, we’ve shipped great mobile apps on iOS and Android for hundreds of clients, and this has given us a lot of data about how a product team’s underlying motivations influence their success. From what we’ve seen, motivations are a strong indicator of whether a team is on the right track, or if they’re headed into a costly 🎶 strada senza uscita 🎶.

Two questions in particular are helpful for zeroing in on where a team is and if they’re heading in a good direction:

1. Are your decisions builder-driven, or customer-driven?
2. Are your decisions based on observed behaviour, or desired behaviour?

Plotting these two questions on a chart—with “builder vs. customer-driven” on the x-axis, and “observed vs. desired behaviour” on the y-axis—is a useful way to frame this conversation because it defines four regions that map out where you are versus where you might want to be:

Easy answers typically aren’t the most honest answers, so these questions can be surprisingly uncomfortable and contentious to wrestle with. That’s why they’re valuable. Let’s take a look at some approaches to answering these two questions and the implications of the four regions they define.

Vision vs. Feedback

No product or feature is 100% customer-driven—it takes vision on the part of a builder to make a new thing based on the belief that it should exist. Henry Ford’s famous (but misattributed) quote comes to mind: “If I had asked my customers what they wanted, they would have said a faster horse.” Sure, and on the other hand, Ford’s sales dropped by 75% between 1923 and 1927, fuelled in large part by Henry’s single-minded fixation on a purely builder-driven outcome.

Successful product teams place themselves somewhere between “pulling a Henry” and “building every customer request”, using methods like those described in The Mom Test to gather high-quality feedback. To get a handle on which way your team is leaning on the builder-customer axis and their potential blind spots, you can start answering questions like:

• Which of our assumptions have been invalidated by talking to customers?
• What do we do when what we want is at odds with what customers are telling us?
• What will we do if we don’t get the traction we’re expecting for this new feature?
• How often do we release new features without customer validation?

Observations vs. Aspirations

Billion-dollar industries have been built on the gap between our real selves and our over-confident aspirational selves (this is definitely the year I’ll finally learn Italian). Also true: billions of dollars have been wasted creating apps and features in ill-advised attempts to change customers’ well-worn habits. If you don’t believe me, I have a web browser to sell you on a monthly subscription basis.

But knowing this behaviour gap exists and doing something meaningful about it are two very different things. This is a famously hard challenge at the core of user experience design, and solving it depends on the data we gather from real world users.

(For a great discussion about gathering good data from users, I highly recommend checking out this episode of It Shipped that Way featuring Teresa Torres (Product Discovery Coach and author of Continuous Discovery Habits.))

Where are you on the observed-desired axis? The following prompts offer a solid start to pinpointing your location:

• How are we validating user feedback with observed real-world behaviour?
• What conversations are we having with customers to understand the bedrock motivations that drive their routines and habits?
• If customers are requesting a new feature, what workarounds have they put in place until they get it? Have they bothered?
• Are we making product decisions based on vocal users, or behaviourally representative users?

In the Neighbourhood

Now that we’ve sketched out what the two axes mean and how we might plot our position on each of them, let’s take a look at the four regions they define. But keep in mind that how “good” a region is depends on your present circumstances, and the goal isn’t necessarily to stay in a single region forever. Just like when you’re exploring a new city, you’ll find that different neighbourhoods have different trade-offs, and some are a better fit for your current needs than others.

Builder-driven, Desired Behaviour

• Teams in this region are typically building according to how they think people should act, with very little evidence. This is often where new apps start, but successful teams generally move toward the “observed behaviour” end of the spectrum as soon as possible.
• From what we’ve seen on most client projects, the longer a team stays in this region the lower their chances of success. A good approach to get things rolling in a more effective direction: start talking with customers to see which of your core assumptions they can invalidate.

Customer-driven, Desired Behaviour

• This is typically a risky place to be since there may or may not be a real need, and customer interviews are only as valuable as the questions that get asked. Instead of asking leading questions like “wouldn’t it be great if…” that tend to confirm our own biases, try bringing the customer back to the moment of a specific past behaviour to unearth a richer recollection of their experience—start with “Tell me about the last time you used Instagram. At lunch? Ok, what did you do next…”. The conversation with Teresa Torres linked to above goes into more details on this.
• Of course, opinionated software can sometimes be a good thing. When customer insights aren’t giving you clarity, it can be helpful to pick a direction, gauge the response, then make adjustments based on your new findings.

Builder-driven, Observed Behaviour

• This isn’t a terrible place to find yourself—the team is building based on interesting behavioural insights. There’s a vision, and the direction seems to be pointed toward product-market fit.
• If teams stop at surface-level observations without digging into why customers behave a certain way, there’s a risk of mis-applying those insights. Make sure you’re exploring deep enough by asking your customers good questions.

Customer-driven, Observed Behaviour

• The highest performing teams working at scale are generally found in this region, but there’s a danger of taking things too far—over-indexing on how things are and not enough on how they could be can put your team too far into this corner.
• Sometimes, the customer isn’t really asking for a faster horse.

Journeys and Destinations

Making software for people would be easy if it wasn’t for people—we all have evolving biases, aspirations, blind spots, and expectations that muddy the waters. This messy humanness is what makes product management so hard. So to build effectively you need to stop, do some honest introspection, and course-correct every once in a while.

Knowing where you are—whether you’re leaning too heavily on vision, chasing unrealistic customer aspirations, or aligning with actual behaviour—is the difference between getting lost and building something people love.