Today I want to talk about something that looks very simple at first, but I think it affects almost every part of life more than we realise.
The idea is this:
General problems require specific solutions.
Always.
I know this sounds like a sentence that everyone can agree with very easily. Nobody wakes up in the morning and says, “I want to solve a serious problem with a lazy and generic solution.” But when we look at real life, companies, schools, families, friend groups, communities, startups, governments, and even software products, we see the opposite happening all the time.
People see a problem that affects many people, and because the problem looks general, they immediately try to solve it with a general rule.
There is a communication problem in the company, so they create one new meeting format for everyone.
There is a productivity problem in the team, so they force everyone to use the same tool.
There is a discipline problem in a school, so they punish the whole class.
There is a social problem in a community, so they create a big statement, a big policy, a big rule, a big announcement.
And sometimes, yes, this gives the feeling of action.
It feels like something is being done.
But action and solution are not always the same thing.
Maybe this is one of the biggest mistakes of people who manage other people. They confuse the visibility of action with the quality of the solution. A general rule looks strong because it is visible. It looks professional. It looks like leadership. It creates the feeling that the manager is not passive. But if the problem is coming from a specific person, a specific process, a specific habit, a specific misunderstanding, a specific incentive, or a specific culture, then the general rule is not solving the problem.
It is only covering it.
And covered problems do not disappear.
They usually become heavier.
This is especially important in modern life because almost everything around us is becoming more complex. Companies are not simple machines anymore. Communities are not simple groups of people anymore. Even a small startup can have engineering, design, sales, operations, marketing, customer support, investor pressure, user feedback, technical debt, and internal culture problems at the same time. So when we say “there is a problem,” we are usually not talking about one single clear object. We are talking about a living system.
That is why I think every serious problem should first be brought back to its smallest human circle.
Who exactly is affected?
Who exactly is creating the problem?
Where exactly does the problem appear?
Which habit keeps repeating?
Which assumption is wrong?
Which person is unheard?
Which process is broken?
Which incentive is pushing people in the wrong direction?
Without answering these questions, a general solution is mostly just decoration.
There is a famous idea in planning theory called “wicked problems.” Horst Rittel and Melvin Webber wrote that social policy problems are not like ordinary scientific problems, because they cannot always be definitively described, and there is often no clear “optimal solution” that everyone can accept. [1]
This matters a lot.
Because many leaders still behave as if human problems are math problems.
They think if the issue is big enough, the solution should also be big enough. But I think the opposite is usually true. The bigger the social problem looks, the more carefully we should search for the small specific mechanisms inside it.
A company does not have “a communication problem” in the abstract.
Maybe the sales team promises features that engineering never agreed to build.
Maybe the CEO gives unclear priorities.
Maybe the project manager hides bad news because the culture punishes honesty.
Maybe the team uses Slack, Notion, Jira, Google Docs, Linear, and email at the same time, so nobody knows where the truth actually lives.
Maybe there is only one person who interrupts everyone in meetings, and nobody wants to say it directly.
All of these can be called a communication problem.
But they do not have the same solution.
That is the point.
A general name does not mean a general cause.
And if the cause is not general, the solution should not be general either.
The same thing happens in technology. A product team says, “Users are not engaging.” This sentence sounds clear, but actually it says almost nothing. Which users? New users? Power users? Mobile users? Users from one country? Users who came from ads? Users who signed up but never activated? Users who activated but did not return? Users who like the product but do not understand the pricing?
If you treat all of these as one general “engagement problem,” you will probably build the wrong thing.
Maybe you will redesign the homepage when the real issue is onboarding.
Maybe you will add AI features when the real issue is trust.
Maybe you will send more notifications when the real issue is that users do not understand the product’s value.
Maybe you will hire a growth person when the real issue is that the product does not solve a painful enough problem.
This is why startups can be so dangerous and exciting at the same time. A startup is basically a machine that tries to survive uncertainty. And uncertainty punishes generic thinking very quickly. In a big company, you can sometimes hide behind process. In a startup, the market gives feedback directly. If your solution is not specific enough, people simply do not care.
This is also where AI becomes very interesting.
Because artificial intelligence gives us a strange new power. It can make general solutions look much more impressive than before. A generic dashboard with AI summaries looks smarter than an old generic dashboard. A generic chatbot with a nice interface feels more advanced than an old FAQ page. A generic automation system with “agents” sounds more futuristic than a normal workflow tool.
But the danger is the same.
If the solution does not understand the specific context, it is still weak.
Actually, with AI, this problem can become even more dangerous because the output looks confident. A human manager may write a bad general policy, and people can immediately feel that it is shallow. But an AI system can produce a very polished explanation, a long report, a clean action plan, and a beautiful interface. It can give the illusion of depth.
But polish is not depth.
A startup that builds “AI for customer support” is not automatically solving a real problem. The real problem may be that the company’s refund policy is confusing. The real problem may be that the internal knowledge base is outdated. The real problem may be that support agents do not have authority to solve anything. The real problem may be that customers are angry because the product is unreliable.
In that case, adding an AI chatbot is not a solution.
It is a mask.
And sometimes a very expensive mask.
This is why I think the future of useful AI tools will not belong to the most general tools alone. It will belong to the tools that understand context deeply. Tools that understand the company’s structure, the user’s habits, the team’s workflow, the product’s real constraints, and the human reality behind the data.
A general AI model can be very powerful.
But a powerful model without a specific workflow is still incomplete.
This is also why I like local-first tools, custom workflows, and domain-specific software so much. Because the best tools do not just add intelligence from outside. They become part of the real shape of the work. They respect the user’s actual situation instead of forcing the user into a generic productivity fantasy.
Martin Fowler explains Conway’s Law with the idea that software systems often end up looking like the communication structure of the organization that built them. The original formulation says that any organization designing a system will produce a design that copies the organization’s communication structure. [2]
This is one of those ideas that sounds technical, but it is actually deeply human.
If your teams do not talk to each other, your product will probably show that.
If your organization is full of silos, your software will probably have silos.
If your company does not have clear ownership, your product will probably feel confused.
If your internal communication is slow, your user experience will probably become slow too.
So again, the problem cannot be solved only from the outside.
You cannot fix a broken product only by changing the interface.
You cannot fix a broken company only by buying a new SaaS tool.
You cannot fix a broken team only by creating a new meeting.
Because the system reflects the people.
And if the people, incentives, responsibilities, and communication lines stay the same, the problem will usually return with a different costume.
This is why I find many management trends suspicious. Not because all of them are useless, but because they are often copied without context. A company sees that another company uses OKRs, so they use OKRs. A startup sees that another startup uses squads, so they use squads. A team sees that another team uses daily standups, so they use daily standups. A founder sees a viral post about async work, so suddenly everything becomes async.
But every practice belongs to a context.
A tool that creates clarity in one company can create noise in another.
A meeting that helps one team can waste another team’s time.
A process that makes a large company faster can make a small startup slower.
A rule that protects one community can kill the natural culture of another.
This does not mean we should reject frameworks. Frameworks can be useful. Models can be useful. Principles can be useful. But they should be used as lenses, not as automatic answers.
The Cynefin framework was created to help leaders understand challenges and make decisions in context. It separates different domains so people do not waste energy overthinking routine problems, but also do not force complex problems into standard solutions. [3]
That last part is very important:
Do not force complex problems into standard solutions.
I think this sentence should be written on the wall of every office, every school, every startup, and maybe every family WhatsApp group too.
Because many conflicts in life become worse exactly because someone tries to apply a standard solution to a non-standard situation.
Imagine a family where one child is struggling in school. The general solution might be “study more.” But maybe the child is not lazy. Maybe he does not understand the basics. Maybe he is anxious. Maybe the teacher’s explanation style does not fit him. Maybe he is distracted by problems at home. Maybe he actually studies, but studies in a wrong way. Maybe he needs confidence more than pressure.
“Study more” is not always wrong.
But it is not always enough.
The same happens in friend groups. Sometimes a group has tension, and people say, “We should all be more respectful.” Of course, that is true. But maybe the real issue is one person constantly making jokes that hurt another person. Maybe two people have an unresolved conflict. Maybe someone feels excluded. Maybe the group only meets in a way that works for some people but not others.
Again, a general moral sentence is easy.
A specific solution is harder.
But only the specific solution has a real chance.
This is also true in society. When people talk about social problems, they usually speak in big categories: education, poverty, loneliness, youth, migration, unemployment, polarization, digital addiction, inequality. These are real problems, of course. But when the category becomes too big, the human being inside the category disappears.
And when the human being disappears, the solution becomes cold.
Elinor Ostrom’s work on commons governance is important here because it showed that successful institutions are not always created by one central universal rule. The Ostrom Workshop summarizes her design principles as best practices for robust institutions, and emphasizes rules-in-use developed by participants and users of the resource. [4]
That is a very strong idea.
People who live inside the problem usually understand parts of the problem that outsiders cannot see.
This does not mean local people are always right. It does not mean every personal opinion should become policy. But it does mean that solutions designed far away from the real context are often missing something essential.
I think we can connect this directly to product building.
The best founder is not the person who only reads market reports.
The best founder is the person who gets close enough to the pain.
The best engineer is not the person who only writes clean abstractions.
The best engineer is the person who understands the user’s real workflow.
The best AI builder is not the person who only connects an API to a text box.
The best AI builder is the person who understands where intelligence should enter the process, where it should stop, and where the human must stay in control.
This is why I think the sentence “AI will automate everything” is both interesting and incomplete.
AI will automate many things, yes.
But the valuable question is not only what can be automated.
The valuable question is what should be automated in this specific context.
Should the AI write the final email, or should it only prepare a draft?
Should the AI answer the customer directly, or should it suggest answers to a human agent?
Should the AI generate the whole design, or should it help explore alternatives?
Should the AI make the decision, or should it organize the evidence?
Should the AI replace the process, or should it reveal where the process is broken?
There is no single answer.
Because again, general problems require specific solutions.
And maybe this is the part that matters most for leadership.
A good leader should not be addicted to generalization.
A good leader should be able to move between levels. He should see the big picture, yes, but he should also have the courage to go down into the details. Because details are not small things. Details are where reality lives.
A bad leader says:
“We have a culture problem.”
A better leader asks:
“Which behaviour are we rewarding that creates this culture?”
A bad leader says:
“People are not productive.”
A better leader asks:
“What exactly is blocking their work?”
A bad leader says:
“Our users do not understand us.”
A better leader asks:
“Where exactly does the user lose trust, interest, or clarity?”
A bad leader says:
“We need AI.”
A better leader asks:
“Which specific decision, workflow, or pain point would become better if intelligence entered there?”
This difference looks small, but it changes everything.
Because the first type of leader creates slogans.
The second type creates solutions.
I also think there is a moral side to this. When we use general solutions too quickly, we sometimes punish innocent people. In schools, in companies, in communities, one person’s mistake becomes everyone’s new restriction. One team’s failure becomes everyone’s new process. One bad experience becomes a rule that makes life harder for people who were not the cause of the problem.
This creates quiet resentment.
People may not always say it directly, but they feel it.
They feel when a rule is not designed for the real problem.
They feel when leadership is avoiding a specific conversation.
They feel when a process exists because someone did not have the courage to address the actual source of the issue.
And this is why specific solutions require courage.
Because sometimes the specific solution means talking to one person.
Sometimes it means admitting that the system you built is wrong.
Sometimes it means changing incentives.
Sometimes it means removing a tool everyone pretends to like.
Sometimes it means accepting that the problem is not lack of effort, but lack of clarity.
Sometimes it means accepting that you, as the leader, are part of the problem.
Generic solutions protect the ego of the decision maker.
Specific solutions protect the system.
That is why they are harder.
But that is also why they matter.
In the technology world, we often talk about scaling. Scaling products, scaling teams, scaling infrastructure, scaling companies. But maybe before scaling a solution, we should ask whether the solution is actually true at the smallest level.
If it does not work for one real user, why should it work for one million users?
If it does not solve one real team’s workflow, why should it solve the company?
If it does not help one real human being make a better decision, why should we call it intelligence?
Scale should not be an excuse for abstraction.
Scale should be built on top of understanding.
I think this is also one of the reasons why many great products start from a very specific pain. Someone gets annoyed by something in their own life. Someone sees a broken workflow. Someone notices a repeated frustration. Someone builds for himself, for his team, for his community, for a very small group of people who share the same pain.
Then, if the pain is real enough, the solution grows.
But it starts specific.
Not generic.
Maybe this is also true for life itself. We often want big answers. We ask big questions: how can I become successful, how can I become disciplined, how can I improve my life, how can I become someone respected, how can I build something meaningful?
These are good questions.
But the answers usually begin in very specific places.
Sleep earlier.
Finish the project.
Send the message.
Read the book.
Fix the portfolio.
Go to the event.
Talk to better people.
Stop wasting the morning.
Build the first version.
Write the first post.
Do the uncomfortable thing.
Life becomes general only after many specific actions.
So when I say “general problems require specific solutions,” I do not mean we should stop thinking broadly. I actually think broad thinking is very important. Vision matters. Big ideas matter. Philosophy matters. Society matters. Technology matters. AI matters. The future matters.
But broad thinking should not become lazy thinking.
A person who truly sees the big picture should also respect the small details.
Because the big picture is made from small details.
A society is made from people.
A company is made from teams.
A product is made from workflows.
A culture is made from repeated behaviours.
A future is made from decisions that look small when they happen.
So yes, maybe we should talk less about solving everything with one perfect framework.
Maybe we should stop pretending that every organization needs the same playbook.
Maybe we should be more careful when we copy solutions from other people’s lives, companies, or countries.
Maybe we should accept that real solutions require listening, observation, patience, and sometimes uncomfortable specificity.
Because the world is not a template.
People are not templates.
Companies are not templates.
Communities are not templates.
And intelligence, whether human or artificial, becomes truly useful only when it understands the context in front of it.
That is why I believe this very strongly:
General problems require specific solutions.
Always.
Not because general thinking is useless.
But because real life is specific.
Take care for now.
I.S.A
Sources / References
[1] Horst W. J. Rittel & Melvin M. Webber — Dilemmas in a General Theory of Planning, Policy Sciences, 1973.
https://link.springer.com/article/10.1007/BF01405730
[2] Martin Fowler — Conway’s Law.
https://martinfowler.com/bliki/ConwaysLaw.html
[3] The Cynefin Company — The Cynefin Framework.
https://thecynefin.co/about-us/about-cynefin-framework/
[4] Ostrom Workshop, Indiana University — Ostrom Design Principles.
https://ostromworkshop.indiana.edu/courses-teaching/teaching-tools/ostrom-design/index.html