Nemawashi: get agreement before you change something

You have a change ready. A new process, a new tool, a new way the team works. You book a meeting, present it well, and the room goes quiet, then the objections start. Nemawashi is the fix for that moment. This guide covers nemawashi: where the idea comes from, how to run it one person at a time, and how to track every concern you hear so none of them surprise you later.

What nemawashi means and where it comes from

The Lean Enterprise Institute defines nemawashi as the process of gaining acceptance and preapproval for a proposal by evaluating first the idea and then the plan with management and stakeholders, to get input, anticipate resistance, and align the change with other perspectives and priorities. Formal approval then comes in a meeting to sign off on the final version. The page says the term literally means "preparing the ground for planting" in Japanese.

In plain words: you talk to each person affected, one at a time, before the decision meeting. You explain the idea, listen to what worries them, and adjust. By the time the meeting happens, nobody hears the proposal for the first time.

You do not need to work in manufacturing to use it. You need a change that affects other people, and the patience to talk to them first.

What can go wrong when the meeting is the first time people hear

A proposal heard for the first time in a group can stall for reasons that have little to do with its merits:

• No time to think. Some people want to mull an idea over before they answer, and a meeting gives them none.
• Feeling left out. A senior colleague who hears about a change at the same time as everyone else may push back to show it needs their input.
• Hidden objections. A worry like "this makes my job harder" may come out in private and not in front of peers.

Nemawashi moves the hard conversation to a setting where people can be honest.

Nemawashi vs. consensus: what it is and what it is not

Nemawashi is not the same as getting everyone to agree. It is also not a way to manipulate people into a yes.

What it is: a structured way to hear concerns early, change your proposal where the concerns are valid, and explain your reasoning where they are not. People may still disagree. But they disagree knowing the full picture, and they know you listened.

What it is not: lobbying, where you only talk to allies to build a voting bloc. It is not a veto for every person. And it is not a promise that the change will be watered down until nobody minds it.

A useful test: after your conversations, is the proposal different from where it started? If nothing changed, you were selling, not listening.

How to do nemawashi, step by step

Here is a process you can run this week. The example: you want to replace your team's weekly hour-long status meeting with short written updates.

1. Write the change in one sentence. "Replace the Monday status meeting with written updates posted by Monday noon." If you cannot say it in one line, you are not ready to pitch it.
2. List everyone the change touches. Include people who will not use it directly but whose work depends on it. In the example: your manager, the product lead, two engineers who lead the meeting, and the person who runs the team calendar.
3. Order the conversations. Start with people who will give you honest feedback, then the most influential, then everyone else. Talking to the most senior person last risks them feeling bypassed. Talking to them first, before you have refined the idea, risks a quick no.
4. Hold short one-on-one conversations. Fifteen to twenty minutes each. Use the script below.
5. Write down every concern. Not just the ones you agree with. Every one.
6. Revise the proposal. Address what you can. Note what you cannot and why.
7. Go back to anyone whose concern changed the proposal. Show them. This step is easy to skip.
8. Bring it to the meeting. Now the meeting confirms the decision.

Map each stakeholder's objections as problems to solve, not obstacles to push past

Step 5 is the easy one to lose. Eight concerns from five conversations are hard to hold in your head until you revise.

Treat each concern as its own small problem. In the status meeting example, your notes might look like this:

• Manager: "I will lose visibility into blockers."
• Product lead: "Written updates get skimmed. Nobody will read them."
• Engineer: "The meeting is the only time I see the whole team."
• Calendar owner: "Removing the meeting frees a slot other teams will grab."

Each one has its own fixes. Visibility could be solved with a "blockers" field at the top of each update. Skimming could be solved with a three-line limit. Team contact could be solved with a fifteen-minute social call every other week. If you need more options per concern, try the methods in brainstorming solutions alone and getting past the first idea.

This is where Problem Graph helps. It is a problem and solution journal drawn as a map. You write each concern as one line, put it in the work lane, and it lands on the graph when you press Enter. Then you attach the fixes you are considering, mark the ones you are trying, and record the outcome as worked, partly, or failed.

Make the change itself, "Replace Monday status meeting with written updates," the center, and link each stakeholder concern to it. Now you can see at a glance which concerns have a fix attached and which are still open. Patterns show up too. If three concerns all trace back to "people will not read written updates," that is the real problem, and fixing it fixes three things at once.

The status meeting example on the graph. A made-up team, not a real user or result.

Your graph is private by default. Only you see it, which matters when your notes say things like "manager worried about losing control." If you later want a co-lead to see the plan, you can mark the change as a main node and share it into a private network you create, using an invite code you give only to them. Anyone with the code can join, so pass it carefully. Problems you only linked to the main node stay home, but the solutions and outcomes attached to the main node go along. Keep anything sensitive off it before you share.

A simple script for one-on-one nemawashi conversations

You do not need to memorize this. Use it as a shape.

1. Context: "I am thinking about a change to how we run Mondays, and I wanted your view before I take it anywhere."
2. The idea in one line: "Replace the status meeting with written updates posted by noon."
3. Open question: "What would worry you about that?"
4. Dig once: "Can you say more about that?"
5. Ask what would help: "What would need to be true for this to work for you?"
6. Close with a promise you will keep: "I am collecting views from a few people. I will come back to you before anything is decided."

Then keep that promise. Step 7 in the process above is how.

Pair nemawashi with a pre-mortem to catch risks early

Nemawashi tells you what people worry about. A pre-mortem tells you what could actually go wrong, including things nobody thought to worry about. The two fit together well.

After your one-on-ones, run a short pre-mortem: list what could go wrong before you start. Imagine it is three months later and the written updates failed. Why? Maybe people stopped posting after week four. Maybe updates were posted but blockers sat for days. Add those as new problems linked to the same change.

If you want more ideas for fixes, Problem Graph can suggest new solutions based on what worked for others on similar shared problems. Treat these as proposals to consider, not answers. You still decide what fits your team.

Once the change goes live, go back and record the outcomes. Did the blockers field work? Did the three-line limit only partly help? A fix that failed stays on the map as a failed fix. That record is what you need the next time you run nemawashi on a different change.

Frequently asked questions

Is nemawashi just office politics?

It can be if you only talk to allies or ignore what you hear. Done properly, it is the opposite: you give everyone affected a private chance to object, and you change the proposal when they are right.

How long should nemawashi take?

For a small team change, a few days to a week can be enough for five or six short conversations plus a follow-up round. Larger changes that touch several teams can take a few weeks.

Does nemawashi work in remote or Western teams?

Yes. The core idea, talk to people one at a time before the group decision, works on a video call or a direct message as well as in person.

What if someone still disagrees after nemawashi?

That is allowed. Tell them plainly what you changed because of their input and what you did not change and why, so they hear it from you before the meeting and not in front of everyone.

Get started

Pick the change you are planning next. Open the app and write it as one line. Then, after each one-on-one, add that person's concern as its own problem and link it to the change. By the time you walk into the meeting, you will have a map of every worry and what you did about it.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.