I was chatting with a co-worker last week about the challenges of coming up with a great new software idea / product / project. His comment to me was
“Once I have a spec that describes what needs to be done – I’m set. If I don’t know how to implement something, I know how to figure out how to do it. My problem is in knowing what to implement.”
We weren’t talking about how to write specs, or prioritize features, but really about the “writer’s block” that comes when you try and figure out how to write a piece of software – at the synthesis stage. Assume a premise, or high level goal for the software: “I want a piece of software that lets me manage my schedule.” Now what? How do you get from a vague notion of a calendar application to actually identifying what you need to do to create your calendar application? At some level, this is aproduct strategy development problem, and there are a lot of interesting discussions you can have about how to do that. For this post, I want to focus on a great tool to help you visualize thoughts cohesively, and iteratively develop an understanding of what you want to do.
Concept mapping is a tool I use for the brainstorming process of defining a product’s specification. IHMC developed this product (available at their website). Thanks to Amir Khella and his blog, Elements of Passion, for leading me to this site. His post, On Creativity, covered a lot of great resources for creative thinking. One link of his was to FreeMind – a freeware mind-mapping program available via sourceforge. The developers of FreeMind did something great – they included a section with a list of alternatives to using FreeMind. I have used mind maps before, and been successful with them – my one complaint was that they optimize on viewing information as trees – essentially spatial outlines. Definitely a valuable tool, but I always had a nagging feeling that what I needed was to be able to express ideas in a graph (instead of each element having exactly one parent, it can have more than one).
I had finished putting together a proposal for introducing automated testing for a client, where there was a small team (6 developers) working on a code base with over 100 developer-years of legacy code. To put together the proposal, I had to cover a lot of ground – to make sure that I bid correctly, and that my client would get the benefits that they should. I used a concept map to help me identify the different areas where costs would be incurred (installation, training, retro-fitting of tests to “high risk” areas of the legacy code, ongoing time spent writing tests on all code developed moving forward, “pollination sessions” for the team members to share ideas and patterns with each other, etc). I probably would have missed some areas without using this approach to defining the problem for myself, and my client would have missed out on opportunities to benefit from the proposed project.
Back to the example, rephrased – “Develop a software tool to help me manage my schedule”. First I would create a box in the center of the page, containing my central idea. Then I would add whatever associated ideas came to mind.
In this diagram, I show the idea that I live “two lives” – work and family. And each has scheduled events. And the reason I care about my schedule is that I need to prevent conflicts between the two. I use an Outlook calendar at work – people send invites, reschedule events, etc. When I remember to do it, I block out some time for family events, if they get into “normal work hours” – which is often when “normal” is not 9-5. And my wife doesn’t know what my work schedule is – she has to ask me “are you doing something on such-and-such a date?”
As I look at the diagram, I think about the fact that my co-workers and clients will schedule and re-schedule meetings, and depend upon my calendar being “current” to know if I’m available. And wouldn’t it be great if my wife knew my “current” schedule too? Of course, she shouldn’t be able to see the details of my work meetings (like “Top Secret product planning meeting”), and my client doesn’t need to know when I’m going to the dentist – she just needs to know that I’m not available before 10AM on Monday. This leads to a couple more boxes on the diagram.
Moving to the next level of detail isn’t the point in this post. The power of building diagrams that describe a problem space, to articulate user goals is the point. I can use this approach to identify the other things I need to do to make this product useful to me, and potentially others.
Two thumbs up from me for CmapTools from IHMC.