Case Study: Side Projects

Lean Coffee TO met again today and we discussed an interesting case study from Chris Eben, hosted by the good folks at My City Lives.

Brief summary of the presentation and discussion:

• Started with the idea in 2008
• Talked to investors, nearly secured funding, but disappeared during market crash
• Should you go it alone? Started out with another non-technical partner
• Turns out going it alone is very difficult (especially motivation)
• Side comment: Are Entrepreneurs not taking big enough risks anymore?
• Another comment: Investors will look closely at how much you've risked personally ("skin in the game")
• Another risk: While working full-time, could you get sued for your side project due to employment contract?
• What's the true motivation behind the side project? (you're always accountable to someone)
• Want to build fun/challenging/new stuff
• Possibility: Could you team up with your existing employer to do the new project?
• Having a family/kids/mortgage can increase the potential risk of quitting a steady job
• Should you learn technical skills to get a prototype done?
• Process has been fun, but frustrating now that so much time has passed since the initial idea

And special -- for this week only -- a full-fledged off-topic rant!

I've been doing consulting with Syllogistic Software for almost 8 years now. I mentioned today that one of my key selection criteria for projects is one simple question: "What documentation do you currently have?"

I think this was was misinterpreted by some. (This ties in a bit to last week's documentation discussion.)

I wasn't suggesting that an idea needs to be fully spec'd out prior to starting. Quite the opposite. That's so un-lean it's not even funny. I would never waste time documenting unless it was strictly necessary.

My point is that this step is critical to demonstrating that you have more than just an idea in your head.

I've noticed that people can lean towards being "talkers" or "doers." I assume, perhaps unfairly, that someone is a talker, until they prove otherwise. That's why I ask potential clients what they've accomplished so far.

Don't get me wrong. I love talking too. I'm always chomping at the bit to get my two cents in at Lean Coffee :) Nobody is 100% one way or the other.

Let's face it though: There's a time for talking, and there's a time for doing.

Talkers can survive in big, bureaucratic organizations. They chat up their boss, attend meetings all day, send lots of emails, hang around the coffee room. They can talk to customers and investors. A properly motivated talker can be a good sales person.

As far as I'm concerned, when it comes to entrepreneurship, there is no room for talkers. There's too little time, and too much at stake.

There's a little saying on the Internet, "pics or it didn't happen." There's also the more traditional "actions speak louder than words."

When it comes to side projects, goals, and life in general, my all-time favorite is one I was introduced to many years ago (on a consulting practice business card of all places):

"JFDI", or "Just focus and do it."

Hope you enjoyed the rant. Next week I'll try to get back to my brief bullet point format :)

To Document or Not To Document

As Lean Coffee TO's unofficial "documenter", I found our discussion on documentation very enlightening.

There seemed to be two opposing viewpoints -- oddly enough, from two physical sides of the room.

My bullet point summary follows:

• Why are people afraid of documentation?
• Makes it "real"
• Not enough time
• Documentation makes delegation possible
• Must be kept up to date
• Cost: overhead for every document you make
• Sometimes you'll write something and never look at it again
• Can documentation limit creativity? (depends on the type)
• Very important for remote teams
• Also important for new hires
• Organizing documentation is very difficult
• It should grow organically
• Document according to risk level
• Surgeons that document their process kill less people
• Helps "be kind to your future self"
• Example: Captain Picard and his log (had to be there to get this one -- awesome example :)
• People have many ways of learning -- writing helps think about problems differently
• Our brains are not designed for storage
• Lean aspect: Wait until there's real pain before documenting

And my own thoughts on the matter:

• I personally hate writing documentation, but...
• Our memories are more like goldfish than we think -- we forget stuff quick
• I document Lean Coffee out of necessity -- It's the only way I can justify the time invested to get some long-term learning that I can refer back to
• Documentation leads to Automation (and automation is very efficient/lean)
• Templates -- I only mentioned this briefly, but think it's ultra-important:
• Saves massive amounts of time with certain processes
• Again, leads to automation -- with a good, up-to-date template, I can create a proposal in 10 minutes that might have otherwise taken 3 hours
• You need to keep stuff in one place (or at least link the multiple sources together)
• Everything to do with my company is either in Google Docs or our project management system, and they both link to each other
• On the personal side of things, my girlfriend and I keep all important info in shared Google Docs and Google Calendars
• I've found that numbered lists or bullet points are better than paragraphs and sentences (since that's how we tend to think)
• Finally, I think that organizing documentation is far more important than simply creating it
• Perhaps you'd use some of your previous notes if they were actually somewhere you could find them :)

Refreshing Lean Coffee Toronto

Today we celebrated Lean Coffee Toronto's 20th meetup, hosted by the awesome folks at Foundery.

This was a "refresher" session, devoted to discussing the group itself and its future. A brief summary:

• Lean is all about the reduction of waste
• "Lean Startup" perhaps a cross between agile software development and agile customer development
• LeanCoffeeTO has a strong "support group" aspect to it
• Resource / Definition reminder: "Running Lean" book: Steve Blank, Eric Reis, Bootstrapping
• Comparing to religion -- pick subsets, slightly different beliefs, but common uniting factors: principles
• Useful stuff: Processes, Case studies
• Needs improvement: Moving from high level to specifics -- ie. metrics, measurements
• Needs more coverage: Marketing, Financing, Scalability
• Potential revisits of core topics
• Important to record and/or summarize (No record of some earlier meetups)
• Potential spinoffs or separations:
• Workshops
• Two different weekly sessions, split on Product/Process or Cust Dev./Technical
• Foundery: Coworking, Incubation, Unfinished on purpose: Let participants define what it is

And some personal opinions:

• Awesome (and somewhat surprising) how many people/companies have donated their space and bought coffee and snacks to support LCT -- My personal thanks to all of them!
• 30+ people is too big for the current format and splitting into multiple sessions would be beneficial
• I personally favor the biz/technical split -- possibly on tues/thurs morning
• Also I vote for a regular "official" Lean Drinks night -- perhaps once a month?
• Not big on the workshop idea, but seems like others are
• All of these things do require a bit of planning and organization
• Still, important to keep a nice balance between "formal" and "organic" (ie. it will suck if it gets too formal)
• Perhaps other can post their ideas as comments here or the LeanCoffeeTO message board?

P.S. If you'd like to be added to my LeanCoffeeTO Twitter list, just remind me at @jasonhanley or tweet with hashtag #LeanCoffeeTO and I'll add you.

Structuring Experiments: Product within a service company

Some notes on today's Lean Coffee Toronto case study, hosted superbly by Jet Cooper.

• Rocketr: 0 to launch in 99 days
• Andrew joined the firm after some long-term travel
• They had 3-month and 10-year plans, but nothing in-between
• Unique: Created a separate entity external to Jet Cooper for Rocketr
• Corporation
• Board of Directors
• Legal Agreements
• Monetary Investment (both from Jet Cooper and people involved)
• Hardest part: Defining the MVP
• Artificial constraints: Having a hard launch date helped keep focus
• Talking to people early on was extremely valuable
• Every week they had potential customer using it
• First 30 days were basically lost due to a substantial change in methodology and approach
• But, this lead to valuable lessons learned for Jet Cooper as a whole
• Now focused on "Agile Design"
• Tools: Paper, Balsamiq, HTML (all the standard stuff)
• Product vision: "Open source" your early thinking about projects
• Focus and forget about the stuff that doesn't matter
• If it's truly important, it will be brought up again

Jason's thoughts:

• The "Agile Design" lessons sound extremely valuable
• Would love to see these organized and documented publicly (perhaps in Rocketr? :)
• Is the separate entity and investment really necessary?
• How much overhead does the legal/corporate stuff add in the early stages?
• There was mention that the board of directors often took up a lot of time
• The "throw stuff out" advise is good (sounds very Tim Ferris or 37signals although not 100% sure of the source)
• Could this approach be "lean-ified" a bit?

Really great to hear these cases studies. Looking forward to next week!