Lean Coffee: Are ideas overrated?

Had a great LeanCoffeeTO this morning at BNOTIONS with a lively discussion roughly summarized by the following points:

• Startups have become very popularized
• There's a trailer for an American Idol-type startup TV show
• Problem with Lean: Doesn't really allow for "blue sky" thinking?
• Ideas need to come at the right time
• Only see a limited view at any given time snapshot
• Is starting a "startup" different than starting a "business"?
• Startups need to have a "grand vision"?
• Treating Lean as "gospel" is dangerous
• Process needs to be flexible
• Lean and its process makes a great base for discussion
• Very different environment for businesses now (vs late 90s/early 2000s)
• Faster pace, easier technology
• Value of ideas: Can turn any idea into "something"
• Idea vs. vision
• Idea is just a "spark" that can lead to a full vision
• Twitter has evolved
• Started by a failed podcasting company
• Interviewing is hard
• Lean process reduces risk
• However -- Reducing the risk is not the same as getting to success?
• Starting a startup not "sensible", the sensible thing is to get a job
• Would benefit Ontario if health care software providers followed more Lean principles?

So the discussion took a few interesting turns along the way, but overall a very valuable session.

Great to see everyone and really looking forward to the upcoming one year celebration events.

Lean Coffee: How to launch a product

This morning we chatted about how to launch a product the lean way. A few key observations:

• What's the definition of "launch" for Lean?
• Multiple "launches" during customer development
• You need to refocus you team from development to sales and support
• Infrastructure: As you move from beta, backup and failover systems become more important
• Looking for early adopters
• Do beta/soft launches first to smaller groups
• Don't see a lot of "big bang" launches anymore -- more "constant" betas
• However, "hard" launches are still common in enterprise (CDs, media, etc.)
• Slowly going away and moving to SAAS (software as a service)
• Product Lifecycle Curve (from Crossing the Chasm)
• Techniques:
• Target influential bloggers in the field
• LaunchRock (a bit spammy, but works)
• Need organic growth -- make it easy for people to do the marketing for you
• It's a different story launching something that people need to actually spend money on
• Difficult to cut through the noise and get people to pay attention
• The personal approach:
• "Bribe" early adopters and influencers and give a personal touch (example: Hashable)
• An email from the founder makes people feel important
• Personal connections can't be faked
• As you grow, build the personal connections into the culture ("customer development team")
• Big launch with press release, etc. less personal -- not as approachable
• Your current users are more valuable than new ones
• Are you launching a product, or launching a company (with a business model)?
• Don't assume it's going to "go viral" -- Design for if it doesn't
• Categories of influencers: How well do you know your customers?
• If you want to get coverage, have something truly interesting, novel to say (example Gmail "goggles")
• Key influencers (especially well-known ones) can make all the difference
• Frequent, iterative launches: Find "excuses" to get heard, and stay consistent
• It takes many times of people hearing something before they actually remember

This is great advice as I personally iterate towards progressively larger "launches" of our project management software, PMRobot.

These Lean Coffee sessions are always a great way to start the day and get thinking about "big picture" stuff that you might not otherwise.

Thanks to Jeremy for hosting, and everyone else for attending and contributing!

Lean Coffee: Project vs. Product Management

This morning's Lean Coffee TO was hosted by Jeremy at Jar Creative. We had an interesting discussion (and side topics) related to project and product management, including:

• Difference: Projects are finite (at least they're supposed to be :)
• Products: The end isn't always clearly defined
• Is Waterfall methodology still is use? Yes. (unfortunately)
• Product management is a bridge between the customers and development team
• Product Management overlaps with Customer Development
• Projects: Divide them up by features / user stories
• Time-boxing: Pick a fixed date
• Product management is about making decisions
• What do you do in the later phases when your product is launched?
• Sometimes need to go back and do a full adjustment
• Often when you release people don't use it the way you expect
• Difference between strategy and tactics: long term goals with iterations as a tactic
• Helpful: The ability to turn feautures on and off for individual users/groups
• eg: Google, Facebook, Big Bang (Woople)
• Sometimes discussing features takes longer than just implmenting it and getting immediate feedback
• How does technology affect product development? (ie. mobile, tablets, etc.)
• The technology decision should come from product management / customer development

Great seeing everyone, and looking forward to next Tuesday's session with Ali from Well.ca.

Inside The Lean Startup

This evening I attended a great panel discussion event at the MaRS Discovery District entitled "Inside The Lean Startup".

There were some great points brought up by the panel of @ashmaurya, @skanwar, @leilaboujnane, and @davidcrow of StartupNorth etc.

My takeaways:

• What do people misunderstand about Lean?
• not a step-by-step guide -- it's a set of philosophies
• not "cheap" or "bootstrapping" -- process efficiency
• Potential mistakes:
• Relying on the wrong set of tactics for the stage they're at
• Over complication in systems (ie. continuous integration)
• Should be about changing behaviour -- getting out and talking to customers
• All about efficiency -- get the most for the least
• Key Metric: Money -- Are people paying you for your product?
• Key Question: How disappointed would you be if this product would be taken away tomorrow? 
• 40%+ indicates not a fluke
• Key Points:
• Reduce assumptions
• Identify riskiest parts first and evaluate
• Don't afraid to be embarased
• Find the shortest route to get in front of customer and get feedback
• Lean applies to: unknown problems / unknown solutions
• Hypothesis test: pull the plug and see if anyone cares!
• When do you start charging? From day 1. ("free" is a customer acquisition tactic, not a business model)
• Starting out: Is this a problem worth solving?
• Make sure a hypothesis is falsifiable -- the scientific method
• "Life is too short to build products nobody cares about." -- Ash
• Adding features:
• Unused features are waste
• Creates technical debt
• Start with "no"
• How do you get feedback?
• Initial hypothesis: pain is so great that they want to be involved in the process
• Find your early adopters -- as visionary as you are (rare breed, hard to find)
• People are always open to telling you about their problems ("tell me about your pain")
• If you're not getting feedback, find out why -- not reachable? don't like forms, method of communication, type of question

And some miscellaneous notes:

• Key Resources:
• 4 steps to the epiphany
• http://www.custdev.com/
• Startup Metrics for Pirates
• Upcoming: http://runningleanhq.com/

• Toronto Events:
• http://to.hackdays.ca/
• http://democamp.com/
• http://www.meetup.com/leancoffeeto/

Valuable stuff. Looking forward to more events like this one!

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 :)

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!

Consulting Partnerships

Today's Lean Coffee Toronto features an interesting case study from Big Bang Technology. As usual, I took a few notes:

• They are a conservative company
• Diverse team with very different, non-overlapping skill sets
• Started doing consulting work with hobby projects on the side
• Found a partner that:
• Had many years experience and successful offline business
• Had a strong need for technical expertise
• Visionary
• Great with sales
• They don't own the product, but they have a revenue sharing agreement
• They do own 100% of their company
• Goals are aligned
• They put 100% of their passion into their client's product
• Advice: Don't go cheap on lawyers -- good agreements are gold
• What might they do different next time?
• Take an equity stake? (Additional potential reward for taking on more risk)

And a few of my thoughts:

• They have a really great agreement that seems to work very well aligning goals
• A partner like this is probably exceedingly difficult to find
• This arrangement came out of a failed project
• Should you chase failed projects for opportunities like this?
• What do you do if the client is a control freak?

Great job guys, and looking forward to the next case study!

Lean and Agile Terminology

As part of Lean Coffee Toronto #13, we discussed defining some of the terminology behind Lean and Agile.

This is a great way to "speak the same language" about things that we might already do without even knowing what it's called.

Here is a quick list of some of my favorites:

• WGMGD: What gets measured gets done
• Six Sigma: A method that focuses on increasing process performance and decreasing process variation through a variety of tools.
• Anti-Pattern: Repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages.
• Refactor: The disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Usually referred to when fixing bad code.
• Iteration: (or "Sprint") It is a period of time where an agile team works to complete a set of Stories. This is typically from 1 to 4 weeks.
• User Story: (or "Story") A feature described in the language of the customer.
• Backlog: The set of stories that are not yet done.
• Stakeholder: Any party that has an interest in the product/service produced by an organization's value stream.

Sources:

• http://www.ccpace.com/thought/Documents/CCPace_LeanAgileGlossaryTerms.pdf
• http://www.leanagilepartners.com/glossary.html
• http://www.agilean.com/resources/faqs/agile_lean_glossary/agile_lean_glossary.htm
• http://www.netobjectives.com/glossary/