Ideas on how not to get lost in a forest of ideas!

One of the most common problems that startups face is the inability to nail down on a core focus or a core offering that might have the potential of attracting users. Every startup founder has experienced this at some level ---<em]]>You walk into a brainjam session with your founding team thinking that you have everything crystal clear in your head, and you walk out completely fuzzy and out of focus. Worst still, every brainjam session seems to bring in angles you didn't think of... and now you are faced with the challenge of figuring out what is it exactly that you are doing. What's at play here? Is this desirable? How do you balance time spent in creating the full scope of the product, vs coding the initial working prototype that gives the much-needed comfort?At E2E Networks, we are faced with this very challenge on a regular basis --- whenever we have an idea or product that we need to architect and scope out, we always have to walk the fine balance between product scope and delivery.To tackle the problem, we have laid down a few ground rules:

1. Attack the problem at the core. Jot down the rest as points that would be tackled at some point in the future --- here, we spend 80% of our brain time in figuring out the core value proposition and the feature set that would best represent that. Rest, we just write out as points in our 'vision to-do list'.

2. Create an initial infrastructure as soon as possible, or use an existing one --- creating a seamless workflow is one that goes a long way towards increasing productivity. While not being dogmatic about it, there are several quick things that we do: -- setup a shared space for vision, milestone, idea jamming: example: basecamp (from 37signals), google calendar/docs etc. -- setup version control and feature tracking software (subversion, git, trac, assembla) -- create repositories for ui designs, documentation, and codebase -- mailboxes, shared wiki, and ftp space We have noticed an enormous amount of time 'lost in translation' --- due to lack of a workflow, the information has to be revisited, thus leading to wastage of time.

3. Build up the core objects, core db models quickly --- building an initial model of the core proposition gives a massive amount of insight into the future possibilities of the system, and whether its sufficiently different from existing players in the market, or other products. In this step, going from vision, all the way to first version of database modeling has been very helpful to us. Some tools in this space: -- High level diagrams that capture the workflow, the product overview / sitemap, the object relationships -- Omnigraffle, Mindmap, Freemind, and anything else that can help visualize object relationships... even Powerpoint can help (since its easy to draw boxes and arrows). -- Azurri Clay DB Modeling Plugin for Eclipse -- Model interrelationships in Rails, testing them using script/console.

4. Create parallel processes for prototyping, feature jamming, product design. While the team operates in an agile fashion, it helps when everyone has a key responsibility --- it their personal job then to make sure that it happens.

5. Create a staging environment asap -- going from prototype dev to stage is key to discovering bugs/nuances in the system that would otherwise remain confined in the development (edge trunk) machines. The ideal workflow that has worked for us is --- create a stage release every evening (nightly build), and let that be the system that gets tested next day while developers create the next version.

6. Play with at least one production deployment version --- you discover a lot of holes in the system early on, if production deployment is tested as soon as there is some sort of working prototype. While this was inhibitive in the past due to costs involved, that's no longer the case if one chooses cloud deployment where you pay as you go. -- it helps in figuring out number of frontend, monitoring, database servers that might be needed -- it helps in understanding areas that might need optimization later (although we are heavily against premature optimization). -- it helps discover any quirks the deployment scenario might bring into the picture. The hosts we find interesting: Amazon EC3/S2, Slicehost, Google Appengine, Railsmachine...

7. Testing. This is an obvious one, so I am not going to go deep into it --- but the gist of it is, with RAD frameworks like Rails, testing should be rigorously built into the development process, so that at the end of first iteration of the product, there are test cases already prepared. Keeping the above ground rules in mind for any particular product, idea or vision has helped us in minimizing time lost in random iterations that lead to nowhere... or from getting lost in the forest of ideas that inevitably emerges from a core one.However, most important of all, one should never lose sight of the whiteboard. No amount of milestones and to do lists can capture the synergy of quick discussions that are chalked out on the whiteboard, and then eventually make their way into system specs.</em]]>Try E2E Cloud to believe in it. Sign-up for a free trial here