Cultivating a customer-first culture in product development

You’ve spent months building what you believe to be a killer feature. It is deployed with great fanfare. You wait for the adoption numbers to roll in, but weeks and months pass by and the needle does not move.

This is a common scenario we have all seen, regrettably, too often.

It is easy to fall in love with an idea. When it is your idea, it is even easier to do so. But if your first customer contact is at launch, you have forgotten the most important ingredient. Useful solutions must involve your customer.

The common traps that cause us to ignore our customer

As humans, we strive to be in control. To a fault, we have a bias toward our own predictions and plans. We become attached to our ideas, hold on to them tightly, and become blinded by our own hubris.

We also believe in our ability to predict how long it will take us to deliver our perfect ideas. But amidst uncertain, complex product development, things rarely go as planned. Our ideas typically take much longer and cost much more to build than we assume.

But this doesn’t prevent many from spending months crafting detailed designs and plans. Then, they spend many more months building to their exquisite plan. All the while, the customer is absent until the end.

What could go wrong?

Plenty. The best idea you could possibly imagine may not be what your customers need at the time they need it. And you can only find this out by engaging with your customer as early and often as possible.

By the time we finally deliver our ideas — developed in a vacuum — to our customers, they are reliably too late. And even if they are by chance timely, they can miss the mark on what the customer actually needs. No customer involvement practically guarantees a poor outcome.

So, why do we avoid the customer until the end? There are many reasons, but here are a few common ones:

• Some product managers put blind faith in the ideas of powerful, vocal stakeholders — They choose to serve these stakeholder demands instead of the customer
• Many product managers don’t say “no” — They build every idea they get; there is no space to bring the customer into this unfocused morass
• Customer outcomes are hard to measure for the uninitiated — Many teams opt to focus on the easier-to-measure metrics of the output they produce. For example, they track if they delivered what they promised on time, within budget, and with quality
• Many product teams have never engaged with their customers — They don’t have time to do so. The irony is they are too busy building the product for needs they don’t understand and often aren’t needed
• Organizations mistakenly think testing out ideas will delay their timelines
• Perfection and completeness of elaborate solutions are sought — This drowns out any notion of focusing on the simple essence that meets the customer’s need
• The organization a product team operates in is not structured effectively — It impedes their ability to emerge with the right product to meet customer needs. Adapting to evolving needs can’t survive in a process-heavy, hierarchical organization

I did say a few, didn’t I? Well, it ended up being a long list. While hard to believe, customers are typically not the first thing on our minds in product development

Practicing a customer-first culture

Don’t relegate the customer to the very end of your product delivery.

You will deliver better outcomes if you practice end-to-end customer involvement throughout. Humility goes a long way here. You have to assume you don’t know the answer, even when you think you do.

A flip in perspective is required. The Field of Dreams approach of “If you build it, they will come” does not work. Instead, your customer must be at the center of building the product, along beside you.

This means if your customers have a need, you will create a solution for it with them. Customer connection matters.

---

---

You don’t want customers to have to find or stumble upon your product or its features (the Field of Dreams method). Instead, you want them to be part of its evolution from the start.

This mentality requires you to involve your customers in an ongoing, focused manner. Small steps, taken with your customer, will emerge the right product for their needs. The product you evolve will be just right, with no excess and no need for more.

And at the core of this approach is a product team, directly engaging with its customers every step of the way. No intermediaries exist between the product team and its customer.

If you have hundreds of customers, this does not mean all are intimately engaged. Often a small cohort of about five key end-users is the right size. The product team then engages this small cohort before, during, and after delivery:

Rich findings and insights can emerge from a close group of about five customers. The cohort should be legitimate end users who have active needs you can solve. And they must be motivated to partner with you.

Excited yet? Let’s explore the nature of this focused cohort involvement before, during, and after delivery. I have found the method described below to be simple and effective.

Engaging customers before delivery

Before delivery begins is a period typically called discovery.

Discovery is aimed at figuring out your customer’s needs and generating ideas on how to solve them. Sounds simple, huh? It can be, yet many don’t find the Goldilocks zone of not too much and not too little.

Outside of the Goldilocks Zone

We already explored the pitfalls of too little customer engagement before delivery begins. Inadequate customer engagement leads to product features the customer does not need. In other words, it leads to unnecessary clutter.

Too much engagement at the wrong time can be equally catastrophic. And it is a common overcompensation that does not pay off.

Too much upfront customer research would be spending months doing all discovery upfront. This is an exhaustive period of:

• Interviewing large numbers of customers
• Meticulously documenting, approving, and locking in requirements
• Designing perfect, elaborate, bloated solutions
• Prototyping every idea

All this is done before building and deploying anything for use in the wild — a costly, risky approach.

Even worse, many organizations deploy a separate team to perform this upfront discovery with the customer. The product team does delivery and this separate team does discovery. With shenanigans like this, it’s no wonder product teams don’t know their customer!

A more balanced, customer-centric approach, owned fully by the product team, is needed.

The Goldilocks Zone of upfront customer engagement

A better path does exist. We don’t need a separate team doing all the discovery upfront.

The best pattern is an ongoing process of a little discovery followed by a little delivery. This deploys an extreme focus and an intentional purpose to solve a single, in-demand need. And as a critical aspect, both the discovery and delivery are performed by the product team.

A product team moving in small loops of discovery and delivery works incredibly well. It allows the right product to emerge through small, iterative experiments. And the secret ingredient: customers go through the loops with them.

Let’s refocus on the discovery part of this loop. The team starts by recruiting a small cohort of its customers. These customers begin the journey with the product team on the first discovery slice.

Initially, the product team may conduct research in the form of cohort interviews. Or they may use ethnographic techniques, such as observing cohort members working. These are rapid, inexpensive learning techniques appropriate for the initial high-uncertainty situation.

Along the way, after a few iterations, a vision for the end product starts to emerge. The product team forms a situational understanding of the landscape of its customer’s needs. Potential target customer outcomes and business impacts begin to crystallize. The team often crafts a product value canvas to portray this rich tapestry of information.

Instead of solving every need, the team and their cohort take a different tactic. They progress to solution ideation of one, not all, of the key problems identified. They pick something that will notably enrich and ease the daily user workflow, according to the customer cohort.

The ideation intends to diverge a wide range of possible solutions before converging on one to try together. One avenue is to involve the customer cohort in a blank-page, co-creation activity. Alternatively, the team can generate options ahead of engaging with the cohort. But the cohort must be involved.

Once options are elaborated with the cohort, one is selected for experimentation. Here, discovery shifts into delivery. This commences the first discovery and delivery loop.

As you can see, the customer is at the core of discovery. And you are not boiling the ocean by spending months uncovering every stone upfront. It is a fast, inexpensive, and focused approach.

Engaging customers during delivery

Delivery is rarely considered a place for customers. Yet, involving customers in delivery is critical for developing a product they love.

The typical customer vacuum of delivery

Many product teams fall into a common trap where they choose to develop perfect, complete, ready-to-ship features out of the gate. Even more perilous, they don’t include the customer until the perfect solution is complete.

This approach doesn’t leave room for learning along the way. We fall back into the mistaken comfort of deterministic thinking. As a result, we run a costly, lengthy experiment that is at a high risk of failing.

When we bet big on a solution idea and go all in, we take a big risk. And when we spend too much money and time on something that customers don’t like, we will stubbornly keep trying to make it work. We want to make sure our effort is not wasted, and this sunk-cost fallacy can lead to our doom.

Delivery without the customer is not a bet worth taking.

A better bet: Involving the customer to emerge the solution path

Until an end-user tries to use a solution, we can’t be certain it will hit the mark and fill the need. This is a truth we often don’t acknowledge.

Unlike going all in on the ideal solution, we should instead start with a simple version. We can then evolve it with customer cohort input. This method embraces learning to emerge the right solution.

This path of experimentation could take many forms. Each test pass should be fast and cheap; we want rapid learning loops to arrive at the right solution, and no more.

One avenue of iteration could involve adjusting the fidelity of the experiment. Instead of building a ready-to-ship feature, you could build a lightweight prototype. You can then put this prototype in front of the cohort for feedback and use the insights to chart the next step.

Another experimentation path: progress the feature through a good, better, and best version. You test each version with the cohort to determine what works and what needs improvement. And you stop when you have enough. What emerges will be only what is useful, with no excess — the essence of what is necessary.

These two paths — fidelity and evolution — can be combined or used in isolation. You can even perform A/B tests to flesh out options. These techniques will help you emerge the right feature to meet the customer’s needs quickly and cheaply.

The insights you gain from these incremental steps can lead down several paths:

• You might choose to move to a higher-fidelity experiment
• It may make more sense to abandon the idea and go back to the drawing board
• Maybe you explore a new option that became apparent during the experiment
• Perhaps you are ready to launch your solution for use in the wild

Delivering incremental and iterative paths alongside your customer elevates learning. It leads to the right solution sooner and with less risk. We maximize the outcome and minimize the output.

Engaging customers after delivery

After completing the discovery and delivery loop with our cohort, we aren’t finished. We must continue our customer partnership after we release it to the masses.

While hard to believe, I have seen many product teams release it and forget it. Focus shifts to the next priority and the team moves on. They don’t give a second thought to the success or failure of what they release.

Release it and forget it is a tragic mistake, as learning is not over until what is built is adopted.

You want your users to find your feature, try it out, and keep using it because it enriches their experience. It should solve a critical workflow need they have. Even better, you want them to spread the word to others about how awesome the feature is.

---

---

There are three routes I’ve seen to be effective when engaging with customers after delivery: analytics, surveys, and continued cohort engagement. Below are some simple yet effective ideas on how to use each.

Adoption analytics

A good analytics tool will help you take a look at the adoption patterns of your user base. Here are some behaviors you should look for to determine the outcomes you are achieving:

• Are they using what you built?
• Are they starting to use it and abandoning it before finishing?
• Do they use it for a time but then abandon it, never to return?
• Do they use it but only infrequently?

Then, once you see a trend, get curious about this data. Here, the other techniques of surveys and post-launch cohort engagement become useful.

Surveys

Surveys can be broadly distributed to your customers. Or they can “pop up” when an individual user encounters your feature in live usage. Both techniques can be effective in getting general feedback or investigating analytics trends.

However, an over-reliance on surveys is not ideal. The feedback in survey responses can be misleading without context. And follow-up with the respondent to fill in the gaps is often not an option.

You will need to investigate further to find out what your surveys are actually telling you. Post-launch cohort engagement is a great way to follow up on both survey and analytics trends.

Post-launch cohort engagement

You may be thinking, “Why would I engage the cohort after delivery if they were involved before and during it?” This logic path is also why many opt to write all requirements down, design the entire system, and then build it all without a second thought. We know in our bones that our ideas and solutions will work.

But you must see how the feature is working for your customer cohort in real life. True, this small group of users partnered with you closely before and during delivery. But nothing beats live usage by the masses. Only when a feature is in daily use, can its merit be fully evaluated.

As a side note, I’ve also seen new cohorts be effective here too. A new set of customers to provide feedback post-launch can provide a fresh set of eyes. It can reveal an alternate, novel perspective.

So, partner with your cohort to see a feature all the way through to its live usage and adoption. You will then complete your learning path and maximize your outcomes.

Taking it forward

Learning loops need not be long, slow, and expensive; they can and should be short, rapid, and cheap. Smaller bets are phenomenally better than going all-in. Learning speed is what you need.

Alternately, if you build your perfect product in a vacuum without your customers, this is the biggest gamble of all. Sure, you can always put your labor of love on a shelf and admire your creation. But that’s likely the most admiration it will get.

Don’t expect a positive customer outcome or business impact without ongoing customer involvement.

Learning speed plus customer engagement produces reliably better outcomes. This translates to you taking small slices of a need and solution ideas and experimenting to find the perfect fit—not too little and not too much. And you do this best with customer engagement before, during, and after delivery.

So, don’t assume you know the answer when it comes to delivering the right product. Moreover, don’t assume your customer knows the answer. Instead, you should emerge the simple answer, together with your customer, in small, evolutionary steps.

Did you get some ideas on how you can better embody a customer-first approach? What will you do today to speed up your learning and engage with your customers?