A new project starts as a complete picture in your head. Then you open an editor and realize you have no idea what to do first. That gap is where projects stall.

Start with a mind map

I've done this with 100+ developers. Every scoping conversation starts the same way: a mind map.

Either on a piece of paper, a whiteboard, or a digital tool. The goal is to get the idea out of your head and into a visual format that shows the relationships between features and stages.

How to build the mind map

You need 30 to 60 minutes, a blank mind map (paper, whiteboard or any software), and the willingness to write down everything without filtering.

Step 1: Sketch the user journey.

Don't start with features. Start with one question: what happens when a user first shows up? What do they need next? What closes the loop? Those answers give you 4-6 stages, each representing a moment in the user's workflow. That becomes your app's structure.

Relating to a product I've built, Pybites Rust coding platform, this could look like this:

  1. User signs up and logs in
  2. User browses and selects an exercise
  3. User writes and submits code
  4. User sees results and tracks progress
  5. User exhausts free exercises and upgrades to premium
  6. Admin manages content and reporting

Features slot into stages naturally. Stage position tells you what matters, which makes it easier to prioritize. Anything that appears in stage 1 or 2 is critical, anything in stages 4-6 can wait.

Step 2: Draw the MVP boundary.

Look at your stages. The first two or three are almost always your MVP; they're what a user needs before anything else makes sense. Draw a boundary there.

Highlight those stages (here I use orange). Everything past it is post-MVP: it won't disappear, but it stops demanding your attention right now.

For the Rust platform, stages 1-3 are the core: exercise listing, code execution / validation and to a lesser extent, user management.

If the code runner does not work, nothing else matters. Premium subscriptions, an affiliate program, admin reporting: they matter eventually, but shipping without them is still a good initial product.

This is the step that makes the project feel scoped. The moment you draw that boundary, you are not building everything. You are building the part that makes the thing real.

Mind map with MVP stages in orange, post-MVP in dark blue; orange sub-items show where to start within each stage

Step 3: Break down the priorities.

Now drill into each priority node and further spec them out. What are the sub-features? What are the dependencies? What are the unknowns?

  • User management: signup, email verification, social login (GitHub, Google), password reset
  • Exercise listing: track model, sequence ordering, free vs premium flag
  • Code execution: in-browser code editor, submission and result display, and in this case an external (sandboxed) validator API.

Keep going until each sub-item feels like something you could write an issue and PR for.

You can apply the same orange highlighting one level deeper. Within your MVP stages (1-3), highlight the sub-items you want to tackle first. Those are the critical areas the rest depends on. Here:

  • User management: email + password login (could even defer signup and just have a demo account for MVP)
  • Exercise listing: list and detail pages for navigation (defer exercise tracks and search)
  • Code execution: code editor and validation (defer result display, progress tracking, hints, etc)

You will not get it right on the first pass, and that is expected. The map changes as you write, and that is the point. Ideas you missed will surface as you write the sub-items. New branches will appear.

This is just the first pass to get started, not the final spec. From here on you'll build a plan, write code, and make small iterations based on feedback.

This is exactly why I'm skeptical of rigid, traditional spec-driven development. Product design isn't a one-and-done process; it's continuous. The map is your guide, not your contract.

Bridging the gap between idea and building

When I work with a developer on scoping their project, the mind map is the first thing I ask for. Not a spec or wireframes, just this map. It gives us a shared artifact to point at which helps with scoping, prioritization and making the idea concrete.

It makes the project feel real. And when a developer can point at a map and say 'this is the thing I'm building', the coaching conversation gets much sharper. The map is also a forcing function: a developer who can't fill in stage 1 isn't ready to start building yet.

Try the exercise before your next project. 30-60 minutes, a blank sheet of paper or digital canvas, and a willingness to write without filtering. The 30 minutes you spend on this will save you weeks of building in the wrong direction. What happens when you skip it is exactly what I wrote about in Design Over Code. Let me know what you come up with.