Business Logs actually began in February 2004, when in the course of one week Mike, Paul and I posted on our respective blogs about the desire to start doing something new. A week or so later I started a blog to chronicle our conversations.
We mulled many options, most of them revolved around using the Web in some fashion. As the core idea of Business Logs came together we needed something a bit more robust than the basic blog I started, so we moved to [plug] Basecamp [/plug] and within six weeks we were up and running. Over the past five months a lot of ideas were thrown around.
While some of the conversations over that time took place via email or IM, most everything is stored, categorized, and thankfully easily searchable on our development blog.
Last night I was looking through some of the ideas we had thrown out and thought, “There are some really good ideas here, but most of them suck.” I’m sorry, did I just admit to Mike, Paul and I having sucktacular ideas? Oh well, hope that doesn’t tarnish the reputation.
The truth is, and everyone knows it, that all companies have horrible ideas. We knew this going in and tried hard to think in terms of, “All ideas suck on some level, but they may not remain that way. It depends.” In fact, It Depends was the name of the blog that started all this.
Things change over time and what seemed like a bad idea back in February is now a really good idea. And I know that because it is stored on our blog, easy to find, and easy to periodically review. We started an informal idea analysis process, which I have drawn out in the following graphic:
Every idea goes through this process. Some ideas spend more time in one part of the process than others. Some ideas are pretty obvious to how bad they are, but still go through some analysis.
Business Drivers. These are all the things that make a business go. The things that need to be done, but also the things the business wants to do. When we get to the point of asking ourselves how something might play out, we move to the next step.
Task Analysis. I use this term because of my background in user-centered design. Task analysis is getting an understanding of what is currently being done to meet the business need (including what are the competitors doing) as well as mapping out how the current tasks need to change (the future state). If it still seems viable we head to design solutions.
Design Solutions. I am using design somewhat generically here. Basically the point is to come up with a handful of ideas on how the future state might work. This is often done by writing usage scenarios; narratives that walk through the new way of doing things. Then we pick a couple and prototype the solution.
Prototype. For Web-based ideas, this means mockups (wire frames). For more conceptual things we may just end with the usage scenarios. That?s part of the reason there is a back-and-forth line between Design Solutions and Prototype.
There is also a back-and-forth line between Prototype and Task Analysis, because once you start working an idea through you start to see gaps in your earlier thinking. These are usually minimal changes, but it is always good to revisit your task analysis to make sure you are still on track with the original idea.
There is also a line that goes back to the business drivers. I put that there because this is something we follow through with if we are working with a client. Taking the prototype back to the business partners and explaining how you got to that point is essential for buy in to move to the build stage (which is another map for another time).
Technical Constraints. This is always the fun one because it redefines what you are able to do with an idea. The back-and-forth line between Technical Constraints and Design Solutions usually plays out rather quickly. It is important to note however, that we try to not think about the constraints until we hit the design solution stage. A technical constraint now, may not be one in six months, but if you think about constraints too soon, you might give up on a good idea without really trying.
A line also goes back to the business drivers, and this line is used much like the prototype line; when business partners are involved, it is important to relay the technical constraints. Partly because they may want to pay you to remove the constraints, and because they need to know as much information as possible to make a good decision.
Uh, Matthew, what about that parabolic weenie roaster?
This is why no idea sucks forever.
When I was in high school (aeons ago), one of the large mirrors in the weight room fell off the wall and smashed into pieces. Being the hippie school that it was (another story for another time) no one wanted the broken mirror to go to waste.
There were about four of us who had a great idea: use the mirror to create a parabolic weenie roaster. (I actually call them hot dogs, but Dean, the math teacher who helped us with, well, the math, called them weenies and the name stuck.)
We did everything necessary to build it, except actually building it. We did the math, drew the plans and never followed through. Part of the lack of follow-through was due to needing a power saw, but most of it was because we were lazy high-schoolers.
We had a lot of really cool ideas that never really went anywhere. Sometime we’d have a good idea that worked out and was even implemented. Those were rare occurrences, but I think that is the normal ratio: many ideas to few implementations.
We had our own, less refined method of idea analysis back then, and a lot of conversations that started, “Hey, what about…,” ended quickly with the following statement: “Sounds like a parabolic weenie roaster.” It’s a statement that gets thrown around still to this day between those of us who kept in contact from high school.
About a year ago, a friend from way back was thinking of developing some blog-like software, though much more to it. (Yes, even more than what is currently available or planned, so there. :P) Given all the other things he has going on right now it may or may not become a parabolic weenie roaster.
But the strange thing was that while I was talking to him, I was also looking through the latest (at the time) Discover magazine, and what did my eye behold? An actual, functional parabolic weenie roaster (sorta).
If only we had followed through on our parabolic weenie roaster that could have been us getting millions of dollars in research grants, being written up in Discover magazine and basking in the collective admiration of screaming science groupies (is there such a thing as a science groupie?).
Most of the ideas that Mike, Paul, and I have shared with each other will never see the light of day. But all of the ideas are worth sharing because at some point they may become viable, actionable, and implementable. And thanks to our internal blog, we won’t forget the ideas. We can revisit at any time and perhaps have the beginnings of our next Business Logs project.