Life Sprints

It Starts with an Idea, a Dumb Idea

Ever had an idea that seemed kinda dumb and you just left it alone... and then a couple of years later you see someone else had that same dumb idea and now they've got investors and a profitable company? I have. That sucks. {shrug}

Because it is human nature to second-guess even good ideas, and since good ideas often seem like dumb ideas at first, its important to give ideas time to gestate. I believe that ideas should not just be gestated in your mind, but rather it is important to vet the idea and experiment with it in the real world over a fixed period of time. So, these days, I conduct little Life Sprints to give ideas the proper level of time investment before I call them dumb. Yep, every three months I hold up my proverbial finger to the wind and decide on the next course my efforts should take[1], and then I "sprint" to the end, putting in enough effort to be able to say I have it a good try.

The Fallicy of Waiting on a Great Idea

I know people who right this minute have ideas they are sitting on because they don't think the ideas are good enough to give them a shot. They are waiting for perfect, obvious ideas that can guarantee a return on investment. While I can sympathize, I think this approach leaves a lot to be desired. It is often in the execution of bad ideas that good ideas are found.

But, here's the kicker: you have to treat all ideas, good or bad, as if they are worth taking the shot on. Because if you don't treat all ideas the same, you risk missing that great idea that surfaces that at first seemed like a dud. Yep, good idea or not, you will execute until the end without fail and then re-evaluate at the end of the period.

I recommend this for a couple of good reasons:

1) You should avoid getting yourself caught in the cycle of evaluating ideas (analysis paralysis) and simply move forward with a hypothesis which you will prove over the period of your sprint. In this approach, the worst case scenario is that you tied up 3 months with a loser idea.

2) Distractions, which can normally beset the typical wheel-spinning entrepreneur, can be filtered by the criteria set forth at the beginning of the sprint. Your requirements cannot be changed until the next sprint, and only things that meet the criteria of supporting the goals of the sprint are allowed through. This means you can spend less time evaluating things on their merits. Instead, those new ideas are sent to the backlog. This process creates an insanely tight focus on the activities of the sprint.

Formula

Here is my new, very software-development-like version of a Life Sprint:

1) Define specific desired outcomes, not the how (ex: increase freelancing income)
2) Break down the required tasks that are assumed to support this outcome.
3) Commit to the sprint publicly
4) Track where you are.
5) Demo the outcome to your peer group.

Rules:
* No new requirements (new projects, relationships, etc) until the next sprint
* Choose challenging but doable outcomes.


My Current Experiments (as of publish date)

* My young son earning money selling auto-vaccuum services by the highway on weekends (weird right?). Its working for him. He's making some pocket money that he wouldn't have had otherwise.

* I'm setting up a bunch of content pages to try to capture local consulting leads. Early results: looking good.

* I'm setting up a physical product/service business website and seeing if I can get local traffic.


Now go, and try some things!

[1] In the past, I've not been so particular on the outcomes of those three months as long as I dutifully held the course and did my unmetered best to test my hypothesis. Now, I'm starting to think this is suboptimal. I think even brief detours need to have well-defined outcomes.

[2] So-called because 1) I'm an engineer and relatively non-creative when it comes to naming things, and 2) there happens to be a software development process construct call Scrum wherein challenging Sprints are undertaken by a team in order to finish some desired functionality without interference from requirements changes in-sprint.

[2] It doesn't have to be 3-months. In fact, I'm currently sprinting on lifecycle emails for my two most recent business concepts: sermon sharing and online payment processing for churches.