Turning an idea into a plan your team understands

You have had the idea for weeks. You can see it clearly. But when you explain it in a meeting, people nod, ask a few questions, and then nothing much happens. Or they go off and build something different from what you pictured. This is very common. The idea is fine; it just has not been turned into something other people can act on. This guide shows how to do that in a few short steps.

Why ideas get lost between you and your team

When you explain an idea out loud, you fill in the gaps from your own head without noticing. Your team does not have those gaps filled. They hear the exciting parts but not the boundaries: how much time it should take, what it should not include, or how it fits with everything else they are already doing.

Writing it down forces you to notice the gaps. It also gives people something to refer back to, which a conversation does not.

Step 1: Get it out of your head first

Before you write the plan, do a messy brain dump. Write, talk into a voice memo or sketch on paper. Do not organize yet. Then ask:

What exactly is the idea, in one sentence?
Why now?
What would be different if it worked?

An AI assistant can be helpful here: talk through the idea, then ask it to organize your rough notes into the six questions below. Edit the result heavily, since it is your thinking that matters.

Step 2: Answer six questions

These six questions are the core of the plan.

What problem does this solve? Describe the problem in terms your team and customers would recognize. "Clients keep asking for monthly reports and we build each one by hand" is clearer than "improve reporting."

What does success look like? Pick one to three signs you will be able to see. "Monthly reports go out in under an hour each" or "Ten clients signed up for the new package by June."

What is in scope, and what is out? This is the part most people skip, and it causes most of the confusion. List what this project will include, and explicitly list what it will not.

Who owns it? One person should own the outcome. Others can help, but someone needs to be accountable. List the main people involved and what you need from each.

What are the milestones? Break the work into three to six visible checkpoints with rough dates. Each one should produce something people can see, like a draft, a test, or a first customer.

What could get in the way? List the main risks and open questions. A short pre-mortem helps here.

Step 3: Decide how much it is worth

Before the team starts, decide how much time or money the idea is worth. Some teams call this an "appetite": "This is worth about six weeks of one person's time." It is different from an estimate. An estimate asks "how long will this take?" An appetite asks "how much are we willing to spend?" and shapes the scope to fit.

This one decision prevents a lot of drift. If the work starts heading past the appetite, that is a signal to cut scope or come back and decide again, rather than quietly letting it grow.

Step 4: Write it on one or two pages

Put it together in a short document. Use headings that match the six questions. Write in plain language and avoid internal jargon. If you need a structured format, the one-page strategy brief template works well for this.

A few writing tips:

Lead with the problem and the outcome. People need to know why before how.
Use concrete examples. "Like the report we sent Hartley last month, but automatic."
Be explicit about what is not decided yet. It is fine to have open questions. Name them.

Send the document before the meeting, with enough time for people to read it. Then use the meeting for questions, concerns and improvements rather than for reading it out loud.

At the end of the conversation, ask someone to explain the plan back in their own words. Where they get it wrong is where the plan needs to be clearer. This takes a few minutes and saves weeks.

Step 6: Turn it into work

Once the plan is agreed:

Create the tasks in your project tool, starting with the first milestone.
Book the check-ins: one per milestone is usually enough.
Write down decisions as they are made, in the same document or alongside it.
Revisit the plan when something important changes, and tell people what changed.

If this is work that will repeat, the steps can become a written process later. See the operations guide on writing SOPs.

Common mistakes

Presenting before writing. You will find the gaps live, in front of the team.
No out-of-scope list. Scope will grow until it collapses.
Shared ownership. "Everyone owns it" means nobody does.
Too much detail too early. A ten-page plan for a six-week project rarely gets read. Keep it short and fill in detail as you learn.
Never updating it. A plan that does not match reality loses people's trust.