“To a great mind, nothing is little.” — Sherlock Holmes

Somewhere between “ineffable twaddle” and “necromancer” lies the timeless character of Sherlock Holmes, who continues to occupy our imaginations and our screens in various incarnations. A consulting detective who can tell more about you from your Apple Watch or your ball cap than you’d be able to rehearse over a long dinner.

But aside from the deeply deductive and yet often erratic behavior, what can we “normal” people learn from the storied sleuth? That is what I wanted to know as I read (and re-read) Conan Doyle’s works. I came away with many lessons that we as product people can apply.

You don’t need to be solving murders or finding lost treaties (though good for you if your role includes those as well).

So what does Sherlock have for those of us creating the technology of today?

Data, Data, Data

I observed that he sat frequently for half an hour on end, with knitted brows and an abstracted air, but he swept the matter away with a wave of his hand when I mentioned it. “Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.” And yet he would always wind up by muttering again that no sister of his should ever have accepted such a situation

The quote above comes from The Adventure of the Copper Beeches. Watson asks Holmes to conjecture on a question, but Holmes rebuffs him. He won’t make a guess without information. He needs more data.

It is a similar refrain throughout Sherlock’s mysteries. In many other instances, Holmes tells Watson and others, “It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

It is true. We need data to make informed decisions.

I was recently reading a story with my son about a fight between a king cobra and a Komodo dragon. Before we started, I asked who he thought would win. He said he needed to know more before he could say. I smiled approvingly and told him, “you can’t make bricks without clay, can you?” I had to explain that phrase, but he gets it.

In product development, we also need data. We can make assumptions, but it will be a capital mistake to theorize without data. We will get married to our theories and twist facts to fit our narrative rather than fit the theory to the facts.

So gather data. You need quantitative and qualitative data as a product team and a product manager. The data can’t decide for you, but it can help you create the story, ask the right questions, and ultimately create the right experiences for your users.

Observe Everything

“You see, but you do not observe. The distinction is clear. For example, you have frequently seen the steps which lead up from the hall to this room.”

“Frequently.”

“How often?”

“Well, some hundreds of times.”

“Then how many are there?”

“How many? I don’t know.”

“Quite so! You have not observed. And yet you have seen. That is just my point. Now, I know that there are seventeen steps, because I have both seen and observed.”

The exchange above between Holmes and Watson is famous and telling. It comes from one of the early stories (A Scandal in Bohemia) and helps us understand a key difference between Sherlock and the rest of us: we do not observe enough.

This can happen for many reasons — we get lost in thought, we get too accustomed to the world around us, or we simply aren’t paying enough attention.

But paying attention is critical, even to the commonplace.

As product people, we need to pay attention. Especially with users, or potential users, of our products. It is far too common that what we intend and what users do are two different things.

As we genuinely observe, we may not understand better, but we can ask better questions and get to the heart of why things are they way they are and why users act they way they do. We should scrutinize what we’re seeing and what we’re not seeing. What are we missing and why?

To help exercise this muscle, there is a splendid book called The Art of Noticing with exercises to help you think more about your surroundings and get outside of the everyday.

Thought bubble, why?

Get Out of The Office

“I’ll be back some time, Watson,” said he, and vanished into the night. I understood that he had opened his campaign against Charles Augustus Milverton, but I little dreamed the strange shape which that campaign was destined to take. For some days Holmes came and went at all hours…I knew nothing of what he was doing.

Holmes and Watson usually take callers at 221B Baker Street, but frequently get out of their flat in order to see the crime scene or otherwise investigate the mystery. In the case above, Sherlock is laying the groundwork for a much more devious plot against a much more sinister criminal. But none of it can be done by staying at home or staying in the office.

It is easy as product teams or product managers to think we can stay in the office, both literally and figuratively. It is the path of least resistance. Getting out and seeing how people use our products may feel overwhelming amid the rest of our responsibilities. But it is critical. And surprisingly easy once we get started.

Right now, with many people working remotely, video calls to talk with customers are a few clicks away. It’s a matter of overcoming the inertia. And once we’re back to seeing each other in-person again in whatever form that takes in the future, we can continue to do a mix of video calls and in-person meetings to both figuratively and literally get out of the office. No need to burglar anyone.

Stop and Think

“What are you going to do then?” I asked.

“To smoke,” he answered. “It is quite a three pipe problem, and I beg that you won’t speak to me for fifty minutes.”

In the story of The Red-Headed League, Sherlock and Watson confront a curious problem. After reviewing the facts, Sherlock pauses to think for an hour before doing anything.

For those familiar with Sherlock, this is a common practice of his. Even before becoming familiar with Sherlock’s smoking, I started blocking off “thinking time” several years ago. It is some of the hardest time to guard and most difficult time to honor, given the hectic pace of life and business. But the best ideas and best work I’ve ever done have been when I actively took time to pause and do nothing but think.

The outcome for me was often a whiteboard of ideas and topics to explore. Most didn’t turn into anything. But a few turned into the most successful products I’ve ever worked on. And that’s the best return on investment you can hope for.

I won’t endorse taking up smoking or buying a pipe, but actively pausing every day to just think, whether it is about ongoing problems or upcoming ideas, will result in some of the best work you’ll ever do.

Don’t Seek The Spotlight

“I’ve heard of your methods before now, Mr Holmes,” said he, tartly. “You are ready enough to use all the information that the police can lay at your disposal, and then you try to finish the case yourself and bring discredit on them.”

“On the contrary,” said Homes, “out of my last fifty-three cases my name has only appeared in four, and the police have had all the credit in forty-nine.”

Product development is arduous work. When things go right, we all celebrate together. When things go wrong, we often look for a person to blame. So it can be a tough balance of ensuring you are getting the right amount of exposure for your work but not seeking the spotlight.

But let your monumental work do most of the talking.

Question Assumptions

“Now, my dear sir,” said Holmes, “is it not obvious to you now that this matter really strikes very much deeper than either you or the police were at first inclined to think? It appeared to you to be a simple case; to me it seems exceedingly complex.”

With The Beryl Coronet, Sherlock is again presented with what appears to be a crime that seems straightforward. But as he peels back some details, he shows that not everything adds up. He questions the assumptions his clients and the police have made so far by showing that they don’t add up with behavior we would expect.

As product teams, we need to first clarify our own underlying assumptions. Then we need to question them. Are we assuming that by building Feature X we’ll drive a certain behavior? Or that users care about X over Y? Once we know our assumptions, we can question them and investigate whether they are correct.

When I was working in online education, we assumed that students cared deeply plagiarism checks and scores, largely because we cared about plagiarism as a school. We had tools built in to check for plagiarism before students submitted their work. At one point, I questioned that assumption and we tested it. It turned out many students did not care nearly as much as we did (because most students weren’t plagiarizing their work). In fact, it was a minority of students who were using the tools extensively, and most weren’t really bothering. That changed how we approached our development.

We need to recognize our assumptions and question what we often take for granted.

Sort The Signal From The Noise

“The principal difficulty in your case,” remarked Holmes, in his didactic fashion, “lay in the fact of there being too much evidence. What was vital was overlaid and hidden by what was irrelevant. Of all the facts which were presented to us we had to pick just those which we deemed to be essential, and then piece them together in their order, so as to reconstruct this very remarkable chain of events.”

Even in Sherlock’s time, they were being bombarded by too much information. He had to sort out what was important and what was irrelevant.

That problem hasn’t gotten easier. We have massive amounts of information and data at our fingertips. A key part of our job is to sort the signal from the noise. What is really important and what is just noise?

It is easy to get caught up in vanity metrics or things that are easy to measure but don’t matter. Number of features you release is easy to measure but ultimately doesn’t matter. Story points are meaningless as a measure of value. It is our job to cut through all of this and get to the meaningful data. What really drives value for your users and your company? What can you focus on? Find that thing and focus on it.

I wrote more about this in an article called Signal vs Noise as a Product Manager.

Detach

One of the most remarkable characteristics of Sherlock Holmes was his power of throwing his brain out of action and switching all his thoughts on to lighter things whenever he had convinced himself that he could no longer work to advantage. I remember that during the whole of that memorable day he lost himself in a monography which he had undertaken upon the Polyphonic Motets of Lassus.

Throughout his cases, Sherlock applied himself relentlessly to his work. But when it came time to wait, he was able to switch to other pursuits until he needed to get back to his work. He was able to give his mind a rest, which was important.

Product development is difficult work. If you are an engineer, a designer, or a product manager, you know this. I speak mainly from a product management background, but all of the disciplines in product development are more than full-time roles. To be effective, most of us are working far more than 40 hours per week.

Besides the work, we are often constantly thinking about our roles as well. I find my thoughts turning to my products, my teams, and my role all the time. When I’m driving, when I’m exercising, when I’m getting ready for bed. It can be difficult to turn off the constant desire to make things better or figure out one more part of the puzzle.

That’s why this last example from Sherlock is so critical. We need to be able to shift our focus away from our products and our roles, even if for short periods of time, in order to keep our minds fresh. Whether that is through long walks, interesting hobbies, or monographies on the Polyphonic Motets of Lassus.

Sherlock Holmes, whether original or adapted, offers many lessons for modern product people. While we don’t need to become as eccentric in our habits, we can take a few pages from his books for our own benefit.

Product-Led Festival is well underway, and there's still time to catch Kyle Evans and his talk on how to take OKRs from theory to practice while delivering value.

Reserve your ticket.