Elementary my dear Watson! 🔍

I’ve always loved Sherlock Holmes. I bet I’ve read the entire collection at least three times.

Cool story. Isn’t this a Product Development mailing list? 

Yes, and I think we could learn a thing or two from our fictional detective friend, especially when we’re investigating a failure. Just imagine we’re looking at a broken widget instead of a note inviting us to investigate a scandal in Bohemia 😉

Watson: “This is indeed a mystery,” I remarked. “What do you imagine that it means?”

Holmes: “I have no data yet. 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.”

I love the lesson he teaches us here. 

Be patient, gather data, then slowly form an opinion based on the facts.

Try it out, I bet you’ll begin to see things more clearly.

-Brian Schoolcraft

A Quick Communication Tip 💬

This only works in certain situations, but in those situations it can be extremely effective.

The situation:

You have a complex, high dollar product - think a small vehicle or piece of heavy equipment

You’re early in production - on the order of 100 or less units in the field

Your design is evolving - every unit is a little different

Root cause is difficult to determine - units are failing in new and interesting ways 😛

In this specific case, a powerful method of “Being transparent” is to set up a dedicated chat account (slack or similar). For every unit that fails, create a new, unique, channel.

Every time a tech touches that unit, all communication goes through the chat channel. When the service team has a question, it’s asked (and answered) in the chat channel. When engineering finds root cause, it’s shared in the chat channel.

This has the effect of documenting everything that happens with each unique unit, effortlessly. If we ever need to look for failure patterns across our product line, the data exists. It’s not organized yet, but it exists!

Compared this to the alternative of a mix one to one emails, texts, phone calls, note sheets, and who knows what else.

Which sounds more transparent to you? 😉

-Brian Schoolcraft

Uh oh. My product is failing. Repeatedly 😬

We’ve shipped product to customers. Now we find out if it actually works!

We don’t want to expect them to fail, but if we’re planning well, we’re prepared for it. What does that look like? Here are a few key areas to keep in mind when things get messy:

Be a collector - Get all the parts “on the table”

Be obsessive about collecting field failures. Bring them back to the lab to study, and try to identify failure modes. 

Be patient - Don’t rush to classify the issues

If I have ten failures at the same time, it’s quite tempting to assume they all have the same root cause. I find it best to stay curious, and let the evidence speak for itself.

Be transparent - Make it easy to gather information

Don’t create barriers to communication, and don’t allow communication to happen in silos. Field techs, service engineers, and development engineers should be able to see (but not be bothered by) all the chatter for every failure.

Be systematic - Figure out how to turn the problem ON and OFF

This is our confirmation that the root cause we’ve identified is correct. If we can turn it on and off in the lab, we’ve got the information we need to start figuring out how to fix it.

Be responsible - Assign someone to own the process

Collecting, summarizing, and classifying failure data should be someone’s responsibility - not everyone’s. This might be a single person for all field issues, or possibly a team of people each focused on their own failure mode. A distributed approach is rarely capable of keeping issues from falling through the cracks.

There’s no silver bullet to fix a reliability issue, but focusing on these five areas will go a long way to smooth things out and get to a fix fast.

-Brian Schoolcraft