Discovery, Part II: Understanding your customers

Amazon’s success is built on striving to be  “Earth’s most customer-centric company.”

Let’s start this short article—a follow-up to my first piece on Discovery—with a proposition that seems both painfully obvious and widely ignored:

Companies that give customers what they want tend to grow. Those that don’t… don’t.

Of course, “what they want” is doing a ton of heavy lifting here because customer needs are never just one thing. I may want a new 88-inch 8K TV, but I also want it at a price I can afford from a company I trust.

In other words, customer wants are often a shifting and conflicting balance of priorities and tradeoffs. Getting them right is hard, and that often goes double (or triple) if you are working in digital delivery.

Who are we really designing for?

Let’s imagine that we’re at the start of a typical development project. A client has come to us, concerned that their employees lack engagement, and wants to create a social feed app.

We could just build what they wanted, but as you already know, discovery allows us to dig deeper into the business goals, crystallise the digital goals, review the risks and assumptions (RATS), and agree on the success criteria.

In other words, discovery accelerates digital delivery by ensuring we start in the right direction.

After I talked about the 4 steps of discovery in the previous article, I said this:

Woven through the four steps above is an understanding that every project has different levels of stakeholders with differing priorities, and we only win when they all win.

So, how do we break down these stakeholders? Let’s return to our example of the company whose employees lack engagement.

1. The Client has identified a problem within their organisation. They are the decision-makers purchasing the product, in this case the Head of HR. These are the people who will pay our bills (and return in the future because we did such a stellar job).

2. The Internal Stakeholders are the internal client teams who are using the product we create. In this case, that might revolve around content creation, technical support, or compliance. (If you’ve ever worked on a beautiful website that was a nightmare to update, you know exactly what I mean.)

3. The End Users are the employees who will be interacting with the product on a daily basis. Their engagement (or otherwise) is the basis of our success criteria.

In the previous article, I mentioned the big risk of avoiding discovery, which is that you inevitably overweight the needs of the client. In that example our fictional agency, Done 4U, acquiesced to their client’s desire to “just get on with it”, and missed the opportunity to solve the client's real, underlying problem.

I get it. Pleasing those that hold the purse strings is how we get paid. But what happens when they have jumped to the wrong solution?

To accelerate our digital delivery towards a real solution, we use our discovery process to upend the order above to something much more like this:

1. The End Users.

2. The Internal Stakeholders.

3. The Clients.

Let’s see why.

Are they unengaged, or just buried?

In our example, the Client has noted a “lack of engagement” and jumped to a solution—creating a social company feed that the employees can access on their phones.

Will that work?

Maybe. We’ve worked on similar projects for multinational clients that have hugely increased employee engagement. We could take the Done 4U path and just build it. The Client would be happy and we’d get paid.

But what if it doesn’t work? What if the real problem isn’t a lack of engagement, but a lack of time. If an employee’s work is already taking 110% of their allotted time—we’ve all been there—are they likely to embrace an extra job? Probably not.

An all-too-common pitfall in product development is prioritising the client’s stated needs without validating them against user behaviour. Without asking the End User what they need.

And of course it’s not just the end user. If we are creating a social feed, something has to go in it. The Client may already have a content team (Internal Stakeholders), but what if that group is already at capacity or structured for outbound marketing.

Many of you will have seen ill-considered corporate initiatives that were launched to great fanfare but were ultimately unsustainable. It’s rarely pretty.

This is why discovery must be multi-faceted. It’s not just about fulfilling the Client’s needs but investigating the root causes of their concerns. Are employees disengaged because of poor internal communication? A lack of autonomy? A culture issue?

The right solution can only emerge when these questions are explored upfront.

The obvious truth (but I’ll say it anyway) is that each of our customer groups has overlapping but not always aligned priorities. Neglecting any one of them risks misalignment, poor adoption, and, ultimately, product failure.

We need to bring them together, along with the Business and Digital Goals discovery I talked about in the previous article.

The North Star document: A single source of truth

In the old days, I used to separate the two areas of discovery into two documents:

• Business & Digital Goals

• Customer & User Needs Analysis

But we found that keeping them separate allowed teams to unintentionally (or intentionally) ignore one in favour of the other. By consolidating them into a single North Star document that evolves through the lifetime of the project, teams gain a clear, structured roadmap that ensures all perspectives are accounted for throughout the project.

Also… it’s just easier.

In addition to the Business and Digital Goals covered in the previous article, the North Star document answers three critical questions about each of our customer groups.

The four questions we want to answer in customer discovery

As I’ve said before, Discovery doesn’t have to be this big, overwrought process. For the customers, we are just looking to answer the following for End Users, Internal Stakeholders, and Clients.

1. Who are they? (Personas, roles, behaviors.)

2. What do they want to achieve? (Goals.)

3. What are their pain points? (Challenges they face that the product should solve.)

4. What support do they need? (Features, integrations, usability considerations).

There’s nothing complicated about this. While some agencies will want to run a big research project, in my experience you rarely need to do more than find the different types of customers and talk to them.

Clients are easy to reach because you’re already talking, and they can help you identify and reach out to Internal Stakeholders. Getting to End Users can be a little tougher if it’s a B2C scenario, but if you ask with an open mind, you’ll always find people who are willing to talk.

And it’s amazing how often a single thread from a simple conversation will save you from making a costly mistake or offer an opportunity that no one has thought of. Either way, it can be gold dust considering the relatively minimal effort required.

Which leads me to the MVP question…

Discovery versus the Minimum Viable Product (MVP)

When I’m consulting with other agencies, I occasionally get some pushback that goes something like this:

• What customers say is often different from what they do.

• What customers think they need is often different from what they really need.

• The only way to know for sure is to collect “real” quantitative data.

• Shouldn’t we create a Minimal Viable Product and go from there?

In truth, there’s little to argue with here. There’s (obviously) no better way of measuring the effectiveness of a product or service than by building it… and measuring its effectiveness.

On the other hand, the last decade or so has seen an increasing number of agencies take this truth as tacit permission to avoid doing the fundamentals. You can see why. Working is better than not working. Being paid is better than not being paid. Clients prefer action over discovery. The basic principle of the MVP—let’s create the simplest possible version of our idea and iterate from there—is powerful and seductive.

Then again, even the simplest MVP involves real work—concept development, UI/UX design, coding, quality assurance (QA), and ongoing support. Why wouldn’t you invest a little time to understand your “customers” before you dive in? Even if you factor in the power of AI to speed development,  having a map massively increases your chances of getting where you want to go (and solving real problems).

And solving real problems is what keeps clients or customers coming back. 

Consider Slack. 

Before it became the go-to workplace communication tool, Slack’s creators were working on an online game called Glitch. Although the game ultimately failed due to lack of users, the tool they’d built to improve their internal communication solved a real problem—one that resonated with software teams around the world.

Most of us aren’t lucky enough to be building something for ourselves, but we can all imagine the value of knowing and building the exact thing we want.

That’s the value of discovery.

The lesson from Amazon

I started this article with a mention of Amazon’s mission statement. Here’s the longer version (highlights mine):

Amazon is guided by four principles: customer obsession rather than competitor focus, passion for invention, commitment to operational excellence, and long-term thinking. We strive to be Earth’s most customer-centric company, Earth’s best employer, and Earth’s safest place to work.

You may roll your eyes at some of this, but it’s hard to argue with Amazon’s success or ambition. For hundreds of millions of people, the site is the easiest way to get what they want.

Case in point. Once upon a time, returning an item to Amazon meant packaging it back into the cardboard, taking it to the post office, and paying to send it off. Then, they introduced pre-paid labels you could print and slap on. Today, I just drop my returns into a local shop and wave the barcode on my phone.

Accelerating digital delivery requires that we minimise the amount of time spent sprinting in the wrong direction—and discovery often makes the difference. 

Companies that give customers what they want tend to grow. Those that don’t… don’t.

Which do you want to be?

Bonus: Watch us talk about Discovery-Business Goals