Okay, so I should know better. If things are going too slowly, you gotta shake it up. Forget about the technical challenges of getting a product implemented, if you cannot communicate effectively with your partners and collaborators, then you are wasting the potential of your organization. When you are a company of two, you cannot afford to waste any potential. Despite the abundance of new tools, sometimes the tried and true tools work best.
One of the great things about our partnership is that we are both open to adopting new technologies to see how they might be beneficial. There are so many great tools out there: Google Docs, WordPress, instant messaging, Skype, Google Wave (sigh)…. Sometimes they work and are beneficial and sometimes they get in the way.
It is too easy to get caught up with all this new-and-shiny technology; it is useful to stop and contrast that with the old solution, “What was wrong with the old solution?” There are a lot of advantages to using Google Doc’s spreadsheets, for example, but they still fall short of Excel, in many ways. Make sure you keep sight of your needs rather than compromising the outcome by the limits of the tools you use.
Step back ever further and recognize that good ole pencil and paper can be the most effective and expedient way to communicate.
We have been somewhat remiss in our communication over our product definition details. We both had a solid, common idea of the functionality we wanted, but the details were not fleshed out with enough detail to be built. Our goal was to come up with a short term product road-map. We performed a high-speed version of the paper and pencil—well, Post-it notes and pen—product planning. I’d forgotten how efficient this tried and true method of rapid product definition can be.
- Agree and adjust
Brainstorm: We first, individually wrote features of the application that we wanted on separate Post-it notes. (This can, of course be done on scrap pieces of paper if you don’t have enough Post-its handy.)
Then, we also cued off the other’s suggestions to come up with even more ideas. Because we were pretty much in sync with a relatively narrow set of goals and targets for our application, this process was much more streamlined than we could have done—and would have done if we’d done this months ago.
Categorize: We categorized the, several dozen, notes, as best we could. Often features did not fall into clear categories, but, keeping in mind that we were shooting for a short-term product road-map, we did not dwell on this step; it gave us an overview of the groupings of things we wanted. Since we already knew what we wanted the core functionality to be, the features tended to fall into our categories.
Prioritize: There is a subtle difference between prioritization and road-map timetables. They do not necessarily correspond to each other. Here was our high-speed version:
- As the “product” definition and non-technical person, Cheryl took a pass. From a product stand-point to prioritize features into an achievable first pass.
- I parsed her pass, from a technical point of view, with what I thought would be achievable in short order. I moved, to “later,” many things that were simple, but focused on keeping the core work minimal since the first incarnation would be an internal prototype (and I hope to get the core working by this weekend).
Discuss and adjust: Cheryl and I looked at the result to check that we were both happy (or at least content) with the result. And, as we discussed, it was so quick and easy to iterate, when we needed. This is key.
With paper scraps, it is so effortless to move things around and discuss changes, the “tool” does not get in the way of the process. Perhaps even more important, the result is a concrete view of what is being established for the product and its road-map—less guessing and fewer assumptions.
Added by Cheryl:
Here’s a video of Bill talking about the process shortly after we finished prioritizing the features.