Brainstorming: how I start a project
I think brainstorming is one of my favorite activities. While some of my brainstorming leads to making cool things, I have piles of mind maps for ideas I’ve never started working on, probably never will, and that doesn’t bother me at all. I enjoy the process, and I love having the trove of inspiration.
I use mind maps for planning out writing projects, making decisions, even sharing ideas. I once submitted a mind map instead of the requested “time boxing” when I worked a corporate job and it ended up being sent up the chain and I received compliments from the top on the “ingenious presentation.” But what I most often find myself mind mapping is ideas for software or other projects I want to tackle.
I’m not a project manager by any stretch of the imagination. I do have a working system for brainstorming, though, and I’m happy to share it with you. What follows isn’t a professional study on brainstorming, it’s simply the method that has arisen from a couple decades of doing this. It’s a starting point for all of my brainstorms. Every project has its own needs and the framework adjusts based on the context, but it always starts with the same basics.
I prefer brainstorming in a mind map because the process is not at all sequential for me, and the way I develop a mind map works with that. I might be thinking about a feature I’d like for an app, but at the same time pondering questions I have about an implementation of something else entirely. With a mind map I can start pouring those thoughts out in any order, organizing them on the fly, and constantly freeing up more space for new ideas. A lot of times a finer point or possible solution to an earlier thought comes up while I’m brainstorming an ostensibly separate part of the project, and a mind map makes it easy to drop it where it needs to go.
I’ll mention my favorite apps for mind mapping before I get rolling. The app I use most often is iThoughtsX, available on Mac and iOS. iThoughtsX offers all of the things I like: great keyboard navigation, map balancing an auto-coloring, images, icons, notes, task management, search and filter, presentation mode, great Markdown export, and easy integration with Marked 2 (among many other features). On iOS you’ll find it in the App Store, and on Mac you can find it available for direct purchase from toketaWare as well as through Setapp (in addition to the Mac App Store).
MindMeister is my second most-used mapping tool. It’s a web app with an iOS companion. It’s full-featured and a delight to use, but its most obvious draw for me is its collaboration capabilities. Live mind mapping with other people, with full attribution and history features. And you can easily convert a mind map into a kanban board in MeisterTask, MeisterLabs’ other major product. It also features one of the coolest presentation modes of all time.
Though I often show it less love, I also have great appreciation for MindNode, available on Mac and iOS. It’s a bit prettier than the competition, they’ve continually expanded its feature set, and it works with Marked 2 as well. If you’re comparing options, it’s a top contender.
Ok, so I’ll let you choose your weapon and we’ll move on to my project brainstorming method.
As I said earlier, the reason I do this in a mind map is I can be adding to all of these parts simultaneously in way that makes the most sense to me. You could pull it off in an outline just as easily, if that works better for you.
I start with a map where the central node is a name for the project. It might be “notes app” or “solving world hunger,” just a general topic for the session. I then add five top-level nodes off of that: Problem, Requirements, Barriers, Questions, and Plan.
Top Tier Sections
- This usually only has one child node. It’s basically a thesis statement, succinctly summarizing the overarching problem that I want to solve. That may have sibling nodes if it’s multi-pronged, or child nodes if I need to expand on details.
- As an aside, I usually only write full sentences in the last node/topic in a chain. A string of nodes represents a train of thought for me, and if the train ends up leading to a destination, great, otherwise I keep the topics as brief as possible, four words at most.
- How should the project solve this problem? This is not a list of steps—that comes later—but rather a description of what the final product should be. In the case of an app, this describes the final product’s attributes, minimum viable product features, and/or things it must do for me to consider it successful.
- Not every topic in this section is actually required. It will often have a subsection of “optional” features or nice-to-haves that will likely come up as I follow trains of thought in the other sections.
- This section is the most pure “brainstorming” part of the process. Ideas about what could work, what could be, what I’d like to see. I separate out the barriers and questions that come up so that they’re easier to take action on.
- What are the biggest issues I’m going to run into while solving the main problem(s)? What complications can I predict coming up? Do I need to learn a new framework? Is there going to be something I’ll be dependent on someone else for? Are there legal issues I’ll need to understand and solve?
- When it’s possible, my barriers have child nodes that detail possible solutions. I just list out everything I can think of at the time. I’ll sort them later.
- As I brainstorm I will absolutely run into questions I can’t answer. These get collected here. If an item in the Barriers or Requirements sections leads to a question, I add it here and create a relationship arrow back to its origin. If a question gets answered in the process of brainstorming, its solution gets added to the original barrier or requirement, either as a child node or as a note on the topic, and the question gets marked as “answered,” usually with a green checkmark icon.
- The plan section gets filled in as I go, but generally is the last section to populate. When a barrier has a confident solution or a requirement results in an obvious action step, that gets added to the plan. Once it’s as complete as it’s going to get, this is the section that usually gets turned into an OmniFocus or MeisterTask project.
- Note that a plan doesn’t always have to be a list of action items. Sometimes I’m just brainstorming a decision I’m making, and the plan is more philosophical than it is anything I’m going to be sticking into OmniFocus. It might even just contain the final decision I made.
Using the System
I call the Requirements section what I do because it’s the easiest way for me to start the process. The question “what do I most need this to accomplish?” is one I usually know the answer to already, and a good place to start thinking. Not everything here is actually required, it’s simply the way my starter questions are usually prefixed. Knowing what I need from the final solution gets me thinking about all of the things I need, the things I want, and the things that could be, the problems and barriers that come with those things, and all the solutions that could exist.
I put it all into the map, every thought, the thoughts that leads to, the random and possibly stupid questions that come up. Unless I’m collaborating live, no one will ever see this first stage. It’s ok for it to be wrong.
So the brainstorming really starts in Requirements and continues in Barriers. Filling in those sections and brainstorming as deep as a topic needs to go leads to things that fill in Questions and Plan. I draw relationships where they’re appropriate, add notes when I have more to say than I think should be a node title, and use icons to sort and prioritize thoughts as I go.
When it comes time to review what I have, I start rearranging and doling out icons, tags, and labels. With barriers and questions I’ll put red flags on the ones that I haven’t solved, calling them out for further review. If I have a barrier with a list of possible solutions, I’ll do my best to sort them and label them. I’ll even delete obsolete ideas, though a mind map is a perfect place to store even “failed” trains of thought as seeds for other ideas. As this sorting happens, more items usually move into the Plan section.
Keep in mind that just because you’re reviewing doesn’t mean you aren’t still adding to the map. As I review thoughts I had early on in the process, it inevitably leads to new ideas or solutions that are now available through the filter of all of the other problem solving I’ve done. Reviewing happens when there’s a lull in the process, not as a final step.
In the end I have a record. It might serve as a starting point for a completed project, or it might make me realize that an idea isn’t feasible right now. I have a couple of “master” maps for things like App Ideas and Projects where I add links to these individual brainstorms and sort them into sections like “planned” or “sky pie.” Each session becomes part of my compendium of ideas, and like I said at the start, I love having these records of all my crazy ideas.