Some of the best products happened through one of two means; the first is the traditional market research, deep study and so on. The other is practically by accident; often the flash of inspiration entrepreneurial route. Everything else is somewhere in the middle. This series is about how we can maybe do better in either case.

I’m going to handle this topic in two parts. This first is just a story illustrating the value we can learn by going deep into the weeds and emphasizes the value of deep discovery; in this case for a B2B product. Why bother? Because I think otherwise we may be missing things. After that, in a separate article, we’ll run through the more basic discovery checklists.

Introduction

As a Product Manager, product discovery should be a cornerstone of the role. It’s the process where we identify and validate customer problems so we build the right solutions. It’s the part where we’re “living in the problem space” and not the solution space; at least at first. Through market research, user interviews, and data analysis, we uncover insights that guide us. This helps us deliver real value, aligning our company and product vision with customer needs. Effective product discovery mitigates risks and accelerates our path to market success. Yes, there are plenty of products and services for which large scale market research is useful. Which is why market research is a multi-billion dollar industry. (See Statista: Revenue of the market research industry, and Market Research Services Global Market Report 2024.) Unfortunately, we still risk missing the mark because Discovery can be turned into a check-the-box exercise if this is all we look at.

We might rush in the form of an overly hasty design sprint, or quickly made up personas. We might make assumptions based on “we kind of think so,” vs. reality. How can we do better? We’ll get to tactics in a next article. First, I want to drive home a few ideas in a more personal way. To do that, first I’m going to tell you a story.

Get to the Customer for Real

With all of our tools from survey research to observational analytics, it feels like we could have a risk of disconnect with customers. I believe that even opinions should be evidence based where possible. And maybe I’ll find more valid data to back this idea up one day. But there’s some real-life stories I can offer you that illustrate the point. Often, especially early in a project, actually dealing with real people can generate insights you’re just not going to get otherwise. The following example is from a B2B product effort; in this case a custom product, but all the learnings apply to just about any other type of product or service. Anyway, I promised a story. So here it is…

Martha. The Sticky Tab Customer.

It’s business legend that the sticky note was created by accident. While the Post-it note may have been invented by accident, it was Martha’s top choice for screen decoration! (By the way, her name is made up. And the business condition I’m going to express is also fiction for NDA reasons and such. But the scenario I went through is real. And the general experience was not a one time thing.)

We were brought in to Martha’s company for business process re-engineering, systems analysis, new applications, and so on. (Big customers love that fresh “new code” smell, right?) A lot of work had been done beforehand. There were procedures, process diagrams and more. This is going to be easy! Why are we even here? Still, something was bothering me. And then I asked a few questions. (Kind of my job.) Then I made a request to visit work sites in person.

My team of several business analysts, a systems architect, and a few others, trundled out to a work site. Which is where I met Martha. When I saw her computer screen, I had some red flags go off immediately. Lovely woman. Been in the business for decades. Knew more intuitively than any Business Analyst (BA) was going to learn in months of analysis. Her screen was surrounded by sticky notes. Differently sized sticky notes. Color coded sticky notes. I dreaded the question I now needed to ask. But we needed to know. “So, Martha, what’s with all the sticky notes?” This led to a good 30 minute explanation of how the notes helped her to use the software, deal with this or that procedure and so on. I glanced around and saw other team members had the notes. The obvious next question, (as I also noticed the old school calculator on the desk), was, “So, Martha, what other tools or things do you use to get your job done that aren’t in the applications the company provides?” “OH, WELL… I use this, that and the other thing, etc. etc.” Then a call comes in on her cell phone. She says “excuse me,” but takes the call right there as it’s not really a personal call. It’s someone in the field who needs something. None of this is being handled via company systems, or being logged. The call was with a customer, and it wasn’t just about the work issue at hand. There was something about how a kid was feeling better, and so on. And it wasn’t just BS, Martha and this customer were genuinely friendly; having spoken together every few weeks or so for years. In an under 60 second chat, Martha did more for brand retention that you’d see some Customer Satisfaction Score improvement campaign capable of at all; over any time frame.

How much of this was represented in our process diagrams? OK, it wasn’t “none.” But the docs sure didn’t cover all of this. Was this the fault of the prior discovery team? At least partially. Or maybe they had been blocked from a site visit because the company could just tell you what you needed to know. Maybe they thought their stakeholder surveys were good enough. Regardless, had we implemented our early ideas without knowing all of this we probably would have made things worse. We would have caused these hardworking folks to grumble about how “those” dumbass corporate idiots make it so hard for them to serve their customers. (This – I’ve come to believe – is often a bigger challenge when the users aren’t the customers. That is, if you’re selling into procurement or finance or whatever, but the actual users aren’t at the table anywhere.) What I think I know with a reasonable degree of surety is that we would not have gotten these insights without talking to Martha. I doubt a survey would have captured this info.

Anyway, I liked Martha. She reminded me of Bridgette. During his life, my dad had a small business in downtown New York City for over 40 years. His secretary, Bridgette, had been with him most of that time. Through ups and downs, through three kids and just as many marriages, and a parade of employees through this small manufacturing plant over the years, from an IBM Selectric typewriter to computerization, and more. She knew things. She knew everything. And so did Martha.

Martha had answers to questions we never would have asked sitting back at corporate. Martha doesn’t post on Reddit. Or anywhere. So no AI would have hallucinated any of the challenges faced even if asked the right kinds of questions in developing a user persona. The raw data wasn’t in the great AI scrapable maw of content. (Well, maybe it is now with this article posting.) You had to talk to Martha. And her colleagues. And the field service folks that Martha talked to on the phone and messaged via their mobile data terminals. Because a whole lot of business was happening via relationships and discussions not managed by any systems at all. Martha had depth of implicit knowledge. And that can be challenging to get out unless you ask really great questions. And follow up on answers. And even then you’re likely to miss things in a first round of discovery.

More Stories?

You know what? I think that covers it. Prior to writing this, I considered a few stories from over the years. But as I wrote out the Martha scenario more in depth, I think I’ve found that covers the point I’m trying to make. I’ve got a lot more of these, but we’re going to just stand with Martha. Having had the privilege to work across multiple industry categories, I’ve seen similar across different industries.

The Empathy Thing – What You Can See

Is this all “the empathy thing?” Yes. But it’s not just empathy as a tool because you read the book about emotional intelligence. It helps if you actually care. And if you don’t, at least hire people that do and send them into the field. Because here’s the main thing… we only see what we can see. Basic communication theory goes like this: Sender > Channel > Receiver. More importantly, there’s perceptual filters at both ends. We tend to find that which we seek. (Obviously.) If we’re not asking good questions, how are we going to get useful answers? And with zero insight, how can we ask good questions? Part of the answer is real world observation. And entering into a relationship with the information space and people involved; both from a systems perspective as well as empathetic perspective. Sometimes this can be done at a distance via tools. Other times going beyond the basics into a deeper ethnographic study can be useful. This is now we got the Swiffer after all. (It was through a great deal of study and home ethnography. See here and here.)

The point? Discovery can be more useful if you’re going in depth and not just running the exercise. While we think we’re “the customer” as well as builders, we’re mostly not. Or rather, maybe we are, but we’re not the only cohort. There are AI tools that purport to help generate personas. This might be a great idea. The way AI works across so many information sources suggests this could be a useful tool. And also a dangerous one; potentially fraught with assumptions. In a lot of ways, it’s similar to search. If you stop at the 10 blue links based on your possibly imperfect search query, you’ll maybe get a right answer. But going deeper can often offer much more; as can trying different search tools. One problem with search tools is that they’re mostly really good. Until they’re not. They suffer from the same arrogance of AI results. That is, they’re occasionally wrong, but never in doubt! My suggestion is that if using such tools, start with them, but don’t stop there. As it is, some teams just make up personas based on assumptions and don’t do the real work. This means your product directions are going to be based on your beliefs rather than a higher degree of confidence that you’re solving for the right problems. And if you haven’t really lived enough or empathized enough with the problem space how do you think you’re going to solve anything. Oh, that’s right! Fail fast and learn!

Wrapping Up

There are a lot of places where you’ll hear any experienced practitioner telling a less experienced person, “OK Kid, here’s what the book says. Here’s what you need to write on that paper for the test. But here’s how it really works.” If your Discovery is missing this real world practitioner reality, just how well do you think you’ll be getting the problem right? And if you’re working in a Mission or Safety Critical area, you might be doing more than missing the mark, you may hurt some people. It’s possible that just running a Design Sprint won’t catch these things. Why? Because there’s a risk of becoming so enamored with the process and time boxes and getting to a Minimum Viable Something that you just ignore inconvenient things. And sometimes, that’s just not going to get anything Viable at all.

Think about going deeper. Even Machine to Machine (M2M) processes probably have their vagaries beyond the obvious. But with people in the loop? There’s almost always some nuance. Finding it can be really hard because people have trouble expressing implicit knowledge. They just assume, “well, everybody knows that.”

Just think about all this. Next, in a second part on Discovery, we’ll go through the more basic checklists.