
The image was created with the help of Microsoft Designer
This piece has been originally posted to Medium.
What do you need to win a war?
A few things. First, an army equipped with modern weapons and instilled with high spirit. Second, a vibrant economy capable of sustaining the hardship of continued military operations. Third, strong public support for the country’s political and military leadership.
Anything else I forgot to mention? Ah, one more thing: you need an enemy. And not just an enemy, a bogeyman you’ve created to justify the war, but the enemy, the real cause of your troubles that needs to be conquered.
The War on Everything
Finding the true enemy is usually, though not always, easier in case of military operations. But we Americans love to launch “wars” against everything we consider a threat to our society. That’s where defining the enemy may become tricky.
Take President Johnson’s 1964 War on Poverty. By failing to identify the root causes of poverty, the federal government has since been shelling the elusive enemy with 92(!) federal programs. According to a 2016 study, it had spent $668 billion on anti-poverty programs; state governments had contributed another $284 billion. The result? The poverty rate in the U.S. has been steady over the past 50 years, fluctuating between 11 and 15% (11.5% in 2022).
Or take the War on Drugs launched by President Nixon in 1971. Since its start, the initiative has received over $1 trillion in funding. However, by focusing on fighting drug traffickers instead of treating drug addicts, the War on Drugs has miserably failed to eradicate illegal drug use.
The only arguably bright spot in our fight against social maladies has been President Nixon’s War on Cancer. By identifying molecular targets responsible for malignant growth and then designing drugs specifically attacking these targets, scientists have been able to dramatically decrease the death rate for many types of cancers. The total cancer death rate in the United States fell 25% from its peak in 1991.
The 80:20 Rule
I’m not a fan of using military terminology for non-military topics. Yet, it’s tempting to compare a problem-solving campaign to a military operation. Of course, you need a competent group of problem solvers (your “army”) to solve a problem. But even more important is to correctly define this problem (your “enemy”) so that it could be attacked in the most efficient way. Failing to do so will make your enemy elusive and your campaign unfocused and ultimately unsuccessful.
I call it the 80:20 rule: in my experience, about 80% of unsuccessful problem-solving campaigns fail because the problem presented to the group of solvers was not properly defined; only 20% do so because of a poor match between the problem and the solvers.
Defining problems isn’t easy, but it can be learned. Unfortunately, many firms, especially new to innovation, don’t understand the importance of this process. They mistakenly believe that they can ask their problem solvers almost anything, in any form, and then it will be up to the solvers to figure out what needs to be done. This is the wrong approach, and that’s why having around someone with experience could help.
What Is Your Endpoint?
I remember a project I had with a client, a large pharmaceutical company. My client wanted to design a high throughput screening (HTS) assay to study a specific type of cellular transformation, a process by which normal cells become cancerous.
(To those unfamiliar with HTS assays, I will say that pharmaceutical companies routinely use them for drug discovery because HTS assays allow researchers to screen tens or even hundreds of thousands of chemical compounds for biologic activity. Although HTS assays employ robotics and sophisticated software, at their core they are still a “regular” assay: you start with a normal cell, you add a test compound, and you watch for something that indicates that the malignant transformation you’re interested in has taken place.)
My counterpart on the client site, the head of the assay development group, confidently listed the most important parameters the future assay was expected to have: the volume (the number of samples analyzed per hour or day), the percentages of false positives and false negatives (the two key parameters defining the assay accuracy), and the cost (as cheap as possible. (But of course.)).
Listening to her and taking notes, I began sensing that something important was missing. Finally, I interrupted: “All right, everything is clear. But what about the endpoint? What is your endpoint?” (In a typical assay, the endpoint is what the assay measures).
For a split second, my interlocutor lost her confidence. She paused and then said slowly: “Well, we do not have an endpoint. We thought that finding it would be part of the whole solution.”
It was my turn to pause before replying. “Well, perhaps we’re asking too much. What if we start with looking for a suitable endpoint and then, after we found one, we run a follow-up project to design an HTS assay based on this endpoint?”
She broadly smiled in response: “Look, if we had a good endpoint, we wouldn’t need you: my in-house developers will design an HTS version of the assay in a matter of weeks.”
This was a turning point of our conversation. Shortly, the two of us put together a problem statement asking for a molecule whose change in structure or quantity within cells would signal that the cellular transformation in question took place.
We posted the statement online, and in a couple weeks, I got a submission from a university professor living in one of the small Eastern European countries. The submission described a protein (I’d never heard of it before) that was overproduced by the cells that had experienced the transformation my client was interested in. This overproduction could be easily detected by measuring the intensity of fluorescence, a slam dunk for any assay developer.
Frugally written, barely a page in length, the submission had a few paragraphs of text, a picture, and a reference. But it was nevertheless something I could share with my client. Her response followed almost immediately: “I love it! We’re buying this solution.”
And that was it. I completed the paperwork transferring the solution to my client in exchange for a money award. I never heard from her again: apparently, her in-house assay developers were indeed as good as she described them.
Know what you want, understand what you need
Clients always come to me knowing what they want. Unfortunately, quite often, they don’t clearly understand what they need.
I remember a client who wanted to change the design of a paint pump because it clogged when dispersing paint. We investigated the problem at some depth and found that the cause of clogging was not the pump. The clogging occurred because the paint was rapidly becoming viscous with a slight decrease of the surrounding temperature. The client fixed the clogging problem by simply changing the composition of the paint.
I remember another client who wanted to find an additive that would prevent a food product from losing sweetness upon manufacturing. It took me some effort to persuade the client to leave the door open for solutions that would include modifications of the food preparation process itself. “No, we can’t change the process; it’s too expensive!” he kept saying. To my client’s great surprise, someone came up with a solution proposing a minor, inexpensive change in the preparation process that led to the same desired result: the preservation of sweetness.
It’s tempting to say that what clients want is often just a symptom of a disease whereas what clients need is the cause of it. You can’t successfully cure the disease (solve the problem) unless you identify its real cause (define the problem).
But enough playing with words! Let me simply formulate my “golden” rule of problem solving: know what you want, understand what you need.









