The Problem With Product Work

And Why User Experience Should Only Be Called Customer Experience…

If you work in product, design, tech, sales, marketing or customer support, then read this. Your work is “product work”, whether you are aware of it or not.

Product is not about features.

Nobody cares about features.

At least, the only person that really matters doesn’t care about features: Your customers.

And not only is product not about features that your customers don’t care about, but these features — and the roadmaps that manage the delivery of these features — are things your team should also not care about.

“But all the product teams I’ve worked with have only ever worked on features: Gathering requirements, defining features & delivering those features with sprints…”, you may exclaim, in shock & befuddlement.

Unfortunately, most teams operate according to a misconception of what a product is - and how one should be built - that is outdated & leads towards failure.

(Don’t take my word for it. Trust a lot of research on product & startup success, as well as the anecdotal evidence of top product-led companies, such as Airbnb, Facebook, Google, Revolut, etc.)

Why is this “feature-first” mindset wrong, though?

As Marty Cagan, author of Inspired: How to Create Tech Products Customers Love, notes:

“Road maps are almost always the same thing; prioritized lists of features and projects… The Microsoft Bing team recently confessed that only about ten percent of the road map ideas actually pan out. Unfortunately, this trend is pretty consistent across industries.”

10%.

Let that really sink in for a second.

A relatively high-performing team at Microsoft admits that only 10% of road map ideas actually get delivered and/or end up delivering value to the customer!

If you have worked in a product team, you probably know this intuitively by now, after managing or observing endless poorly-thought-out, rushed-through feature ideas that fizzle out & become quickly forgotten (or deliberately ignored).

Yet why do so many product teams continue to operate in this way? And what are the root causes for this repeated behaviour: Features are tangible, outcomes are not:

Humans have a tendency to jump to solutions, rather than focusing on the problem.

It’s therefore much easier to think of tangible things like features & functionality than it is to envisage things like “customer motivation” or “impact on customer behaviour”, which are intangible & nuanced.

As a result, discussions tend towards mapping out the feature & its functionality, rather than focusing on the core problem for the customer & for the business.

2. Tangible Things Seem More Valuable

Not only are features more tangible, but they are also (wrongly) considered more valuable for the business.

Time pressure means that product teams fail to stop & ask why they are doing something, instead pushing themselves to deliver something. Unfortunately, completing a feature feels more valuable than completing a batch of user interviews, despite this not necessarily leading to value-creation for the customer & for the business.

Furthermore, product teams worry that they are wasting all their expensive resources on intangible things (which are implied to be not of value to the business). “I’m not spending $100k on a developer to have them listen in to a user test”, they start to think.

3. Outcomes are uncertain

Output (i.e. delivering features) feel more predictable. Even if there are delays, you can still feel you’re 80% complete or “just a few more days away”. This lends itself to a strong sense of progress.

Unfortunately, when we start to think about outcomes (i.e. value we delivered for our customer & for our business), this is not the case. We could test any number of prototypes or product ideas but still, in many cases, not have seen any positive outcome.

This means planning using a multi-month roadmap becomes impossible if we move away from a “feature-first” mindset.

This is exacerbated by many companies still blindly following their business plan, expecting the theory to pan out perfectly in reality (which never happens), setting ambitious targets set by investors that leave no room for the messy, uncertain, nuanced world of reality.

4. The Bastardisation of Agile

Finally, many people simply do not see an alternative way of conceiving of - or the building of - product.

Scrum certifications abound. 2-week sprints are the gold standard. Estimations & delivery become the thing that a product team’s success are measured by.

Despite Agile as a theory being founded upon the premise of building products that deliver value, too many teams find themselves constrained by a company structure making decisions in a Waterfall, where decisions about what should be built come from the top, leaving product teams with very little wiggle room to question why they are working on something & experimenting with how - and what - they may end up actually building.

(I go into the topic of Agile Anti-Patterns in detail here).

A Definition of Product

Features are more tangible than outcomes. Tangible things are considered more valuable. Features also feel more certain. And the misuse of Agile theory pushes a misguided belief that building features quickly is what matters.

So if product is not really about features, what really is product all about?

“Product… Like an app or website, right?”

No, not really. Product is, at its core:

“A vehicle for delivering value to the customer AND to the business.”

Product is a “vehicle” because it can be any thing that delivers value. This could mean an app for sending emails, like Gmail. But it could also mean a world-class customer support team. Or a free webinar on improving your personal brand.

Product is focused on “delivering value to the customer” because ultimately the customer hires your product to help them achieve some internal desire as quickly & easily as possible. If your product doesn’t fulfil that desire, they will simply stop using your product & try something else.

Product is also - and this is commonly skipped over in many product teams - ultimately there to “deliver value to the business” in the form of revenue. If the business is not generating enough revenue to cover its costs, it can’t pay its team. If it can’t pay its team, the company goes bankrupt. Raising investment may fund a team for a while, but ultimately the business needs to be profitable. Therefore, your product team needs to deliver more revenue to the business than it costs to run the product team (whether directly through revenue-generation, or indirectly through increased customer activation and/or retention).

Product is about going beyond the user & focusing on the customer i.e. the person who is paying/will pay for your product.

How To Build Product Right

Unfortunately, changing how product is conceived & practiced is really hard (which is why we spend 6 weeks to teach this!). It takes a complete dismantling of how a company plans, organises itself & executes.

Instead of multi-month roadmaps, it requires teams to iterate based on new learnings.

Instead of siloed teams of sales over here & product over there, it requires smaller, cross-functional teams of, for example, a product manager, UX/UI Designer, developer, marketing, data analyst, all focused on one clear business goal.

Instead of measuring success in terms of output (i.e. number of features delivered), it requires us to measure success in terms of outcomes (i.e. what value was delivered to our customer & to our business in the form of revenue).

All of these requirements themselves require a different way of working.

It requires a discovery process of working out what to work on, by speaking to customers & coming up with insights.

It requires testing out a prototype thoroughly before committing to building it in a scalable, long-term way.

It requires us to measure the current state of things, as well as the change caused by the specific experiment or prototype we have built.

It requires us to define what to work on next ONLY once we have got the results of our previous experiment.

All of these things take a radical transformation of how the company operates, which takes a lot of time & effort.

But one high-impact, low-effort thing you can start doing right now:

Book 5 customer interviews every single week.

Offer a $20 Amazon voucher for a 30-minute conversation.

Fix it in your Calendar each week.

You may not change the business overnight, but it becomes hard to argue with the data you’ll be getting from those conversations, as well as the insights you derive from understanding the customer on a deep level.