Lean Coffee: Pirate Metrics and Customer Feedback

Great little Lean Coffee session this morning at Big Bang. My notes:

• How do you decide what to build?
• AARRR!
• Acquisition: Signups
• Activation:
• Subjective: 1 post, 2 posts, a series of events?
• Retention
• How many coming back every X days, X months
• "Active users"
• Referral
• Revenue
• Example: How many signups per blog posting?
• Focus on one metric at a time -- for instance "how do we get people to activate?"
• Activation phase: Need to focus on particular group/niche
• What is that "painful" thing people need to do to set up
• Switching costs
• Revenue: What makes the highest profit?
• Sometimes your metrics are wrong
• For instance, are your activations _really_ activations?
• Metrics: Are you tracking the "offline" parts of the experience?
• Retention: Continued activations
• It's not just one feature -- it's how they all fit together
• Everyone has their one different "one thing"
• You can divide into different users groups, and each one can have their own activation
• Example metric for Basecamp: "User has a conversation"
• You often have to sell to your customer multiple times
• Activation metric should always be testing your _new_ users, not mixed up with existing users
• What set of features provide the most value: to customer, to business
• Which feature is causing us the most problems?
• Start measuring first -- then set goals

SUPER BONUS!!! Live screenshots from PMRobot's custom dashboard.

You can have a look at the type of metrics we currently track.

Click to zoom in.

Recent signups: Note that contact information is right there so we can email for feedback quickly

"Active" users: Currently defined as created more than 7 days ago and logged in within past 7 days

More active users: We use highlighting and bold to show which ones are further along in the process

Organization dashboard: Shows a small subset of "key" accounts

Lean Coffee: Git Money!

Some brief notes from this morning's "Git Money" Lean Coffee TO session at Big Bang:

• No, this was not about Git :)
• How do you validate whether someone will pay, before you even build the product?
• Example: Coffee Shop owners
• Biggest problem: How to get feedback from their customers
• Made up rough wireframes and brought them to coffee shops
• Asked for $20, promised working software by a certain date
• In return, they got $200 of service
• Reduced the discount rate as more customers signed up
• Social proof made it an easier sale
• Would this approach work for more expensive products?
• Potentially -- Companies sell unfinished software all the time
• Start with a discount, and reduce that discount over time
• What is the product is really complicated?
• Customers may ask to see more before handing over money
• In that case, you may need to look to a different type of "visionary" customer
• What if your product has an existing competitor?
• All products have some type of competition (ie. the "do nothing" alternative, or other channels that might not be "direct" competition)
• How much do you need?
• Depends on how good a sales person you are
• Might be able to see just based on a conversation
• Otherwise, might need wireframes, working prototype, etc.
• Future discussion topic: Customer Objections

Insane Apache FastCGI settings

We recently moved PMRobot to a new server, configured very similar to the old one with WHM/CPanel.

The only major difference was a newer version of the Apache Web Server -- 2.2.21 vs 2.2.16.

Unfortunately, not long after the switch, reports started coming in that most attachments were not uploading. Only very small ones (less than 100K) seemed to work.

Since there were no recent changes to our attachment code, I started digging through logs to discover the source of the problem.

None of the usual error logs reported seemed to contain anything useful.

Finally I worked my down down to the root Apache error log and discovered this little gem:
[warn] [client ...] mod_fcgid: HTTP request length 137881 (so far) exceeds MaxRequestLen (131072), referer:

A nondescript little warning that thankfully led me to this post which solved the problem.

This person also seemed to have had the same problem. 

The icing on the cake was the little warning at http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen, which reads:

Warning: Before 2.3.6, this defaulted to 1GB. Most users of earlier versions should use this directive to set a more reasonable limit.

My question is WHY!?! Why did they reduce a 1GB default limit to 128K? Surely someone must have realized that havoc that might wreak, no?

In any case, if you encounter this problem, simply add the following to your Apache config:

<IfModule mod_fcgid.c>
 FcgidMaxRequestLen 1000000000
</IfModule>

and you should be good to go again.

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: Raising your first round

I think I've been spending a few too many late nights coding PMRobot UI enhancements, as I had some trouble actually finding today's Lean Coffee Meetup.

I was running late due to the TTC, and the Meetup Android app hadn't updated the recently-changed location. So I wandered through an empty building trying to figure out where I had gone wrong.

Luckily somebody (who had obviously had more sleep) pointed me to the open door I had just walked past, and I was able to join in and take down some notes about raising investment:

• The Canadian Angel investing community is not as established as in the US
• Tech startups are getting more popular -- getting harder to find developers here
• Canada is "a couple steps behind" but heading in the right direction
• Investors are looking to invest immediately and get their returns in 5 years
• Currently near the end of a 5-year cycle -- little money available
• Something to check out: Angelist
• Canadian companies get government matching and SRED, so big financial advantage
• It's not beneficial to hold back on communicating the details of an idea
• What is the right time to approach investors? Probably not the idea stage
• Government grants, funding, etc. can work at the concept stage
• Having solid market research can help with grants
• There are grant writing companies who will help you apply for a cut of the cash
• Board of advisors
• Not easy to establish
• What's in it for them?
• Angels place a large value on your board
• Angels tend to be on the team more than the idea

Glad I finally found everyone this morning. Next time I may need a pre-LeanCoffee coffee :)

See you then!

Lean Coffee: Vizualize.Me Case Study

The summer has been busy, and I didn't think I'd be able to get back into Lean Coffee before September, but this session's topic was too good to pass up.

Eugene Woo from Vizualize.Me presented an amazing case study for the group.

Here are a some key notes from the discussion:

• Won StartupWeekend, 2000 signups on the first day
• Thousands of signups per day -- now over 100,000
• After a month, decided to pursue it full-time
• Did a "press push" about winning StatupWeekend, etc. but didn't really take
• Made an Ashton Kutcher sample and pushed to blogs
• Didn't really get much on the blogs
• But major press picked up on it somehow
• Led to articles on FastCompany and Mashable
• "You don't learn when you're building"
• No mockups, built a working prototype quickly
• Important for learning -- wouldn't learn the same things with a mockup
• Customer development can be depressing, but is also exciting
• Priorities are not clear, but at least you know the problems
• 1-3 months away from "true" MVP
• So far 100% equity, seeking a seed round
• 10 or so competitors have emerged
• So far they have a huge branding head start
• 50% conversion rate from signup list, 15-20% fill rate for Wufoo survey
• Lots of wrong assumptions and learning: eg. Thought people wouldn't need to edit inline
• At least 5 phone calls per week, lots of email and surveys
• Use MixPanel for data collection
• Started out collecting everything, but now focusing on a few key metrics at a time
• Biggest potential competition: If LinkedIn builds similar capability
• Jobs market is ripe for disruption
• Best source of leads/signups: LaunchRock, Twitter

Thanks again Eugene for sharing, and looking forward to see Vizualize.me continue to grow and evolve!

Lean Coffee - Entries and Exits

Today we discussed various Lean ways to enter and exit business ventures.

A few points that came up:

• Three main entry methods:
• Seek financial investment/partners
• "Scratch own itch" and finance internally
• Sell a custom solution as a product to first customer, then market to others
• Developing internally:
• Benefits: Strong engineering expertise, Can work on it during "downtime"
• Drawbacks: Tough to focus and allocate enough time, Lack of sales/marketing expertise
• When bootstrapped, makes you highly focused on revenue generation and reaching profitability
• Big difference in attitude in Canada vs. United States with regards to VCs and financing

Thanks to Jeremy at JAR Creative for hosting!

Lean Coffee: Culture

Today at Lean Coffee Toronto, we discussed Culture as a Competitive Advantage.

A few of my key takeaways:

• Culture is: The expression of your values
• Examples: Mediteranian vs.British vs. German
• Can be a big advantage for small companies
• Business was a lifestyle choice
• Enjoyed work and stuff outside of work
• Profit not the only motive -- sustainability too
• Formalized profit-sharing (after setting aside 3 months emerg. money)
• Working Group working retreat: Amazing ideas, great team building
• Marked a commitment to the future and to the team
• Defining the culture was a group effort
• Building a "post-modern" company: happiness and fulfillment as well as profit
• Reference: "Drive" (Dan Pink)
• Even in bad times, continued to do "extra" stuff like team retreats
• Growth spurts can hurt culture
• It takes a lot of time to hire people that meet the culture
• Often creates problems when companies grow quickly
• Ties into organization, process, procedures, scalability
• In small companies, culture is based on your personality
• When you grow, you need to abstract your values
• Successful models: Zappos, Apple, Google
• Employees drive culture in subtle ways -- when they show up, conversations, etc
• Culture defined stronger when founders are very involved in day-to-day ops
• People want ownership of stuff
• Is culture like a brand? Difference between reality and what is said/written

Thanks to Andres and Dom from TWG for hosting and facilitating today!

Lean Coffee: Pricing and Estimation

Today's Lean Coffee was hosted by Matthew Bertulli at the beautiful Mango Studios.

I managed to jot down a few notes from the session:

• What is your market?
• Enterprise pricing very different
• Your pricing determines what type of customers you'll get
• Estimating ties into pricing to determine whether a business is viable
• Estimating your customer acquisition cost if important
• Price as high as the market will bear
• Should you price yourself based on cost?
• Generally not, but should at least be considered a minimum
• Should never offer a B2B app to businesses for free
• B2C generally needs to have a free option
• Estimating is very hard, and you will always underestimate
• Estimating product costs: How long can you survive on no money?
• Pricing: What are the alternatives?
• What is the premium value you're offering?
• Estimating: At least double it -- there are always unknowns

See you at the next!

Lean Coffee: Minimum Desirable Product

Today's Lean Coffee TO discussed the concept of a "Minimum Desirable Product" in relation to the more well-known MVP.

An interesting way to visualize this concept, from @andrewchen's presentation is as follows:

I also took some notes from the discussion:

• Twitter, Facebook, Google all started as MDPs (without a viable business model)
• Viability is measurable, whereas desirability is more difficult to measure
• Desirability is about demand -- does it exist at any price (including free)
• Are you viable initially, or only after X number of users?
• MDPs can give awareness, publicity, etc. to a company to help them launch 2nd, 3rd products
• MySpace -- Still viable, but not as desirable anymore?
• Just starting out: Tradeoffs between desirability and viability
• Desirability is a _component_ of viability
• MVP when spoken about, often really refers to MDP
• Can viability kill desirability? (ie. Facebook early stages)
• With a desirable product, your viability may be tied to different users than you think
• Like "Ladies Night" -- free customers and paying customers
• What should you focus on at what time? Feasibility vs. Desirability vs. Viability
• Feasibility is a lot easier for most type of applications now
• Viability is easier too since costs have gone down
• So the most difficult part now might be Desirability

Thanks to Andrew and Satish at Jet Cooper for hosting this morning's session!

PMRobot Project Management Survey #1 Results

Back in March, I put together a survey with two very simple statements:

1. When managing a project, I often feel like a glorified secretary

The results for this question surprised me. Only about half of the 32 respondents felt this way.

2. Communication between clients and programmers is poor or non-existent

This question turned out more like I expected. Most people agreed that client-programmer communication could be improved.

There were also some great insights from the free form comments:

• Programmers: "Often they are not engaged early enough in the project.  Therefore they are missing information that has already been covered."
• "If your programmers just aren't client-safe, then you are doomed to be, or to rely upon, 'Systems Analysts' of the sort you see in the movie 'Office Space'."
• "It's important to engage with clients and programmers. When you wait for them to come to you and don't engage proactively, then communication suffers."

Thanks again to all who responded!

I've already used this feedback to help prioritize the communication aspect of PMRobot over the automation features.

P.S. I'm running a new survey about existing tools. I'd love to hear your feedback at http://bit.ly/ifX4SV

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: Micro-management

This morning we talked about management, project management, and more specifically, micro-management. A few key points from the discussion:

• What's involved in management?
• Timelines, resources, problems/obstacles
• When to micro-manage?
• Highly selective micro-management
• What are the key things you need?
• Visibility
• Accountability
• Communication
• Need to let people fail and fix things themselves when possible
• But maybe not when it's on a client's critical path
• When to step in? When things aren't going as expected or estimated
• Make sure workers know when to flag things and ask for help
• Manager's job: Find out the impediments and remove them
• Need to give frequent feedback, especially positive
• Don't forget about the positive feedback -- it's easy to only give feedback when there's problems
• Hiring: People observe who stays and who is let go
• Contributes to group culture
• Tools: Pivotal Tracker, Basecamp (good for discussions), Trac (didn't like), PMRobot (coming soon :), Intervals, Bugzilla, Fogbugz, JIRA (bloated, enterprise-y), Redmine (customizable)
• Pivotal Tracker: Velocity / points system works really well

I was really interested by the tools discussion, and on a related note, prepared a quick Google Docs survey. Check it out --> How do you manage? -- I'll post the results at a future session.

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.

Lean Coffee: Customer Segments

Today's Lean Coffee was hosted by Mark at BNOTIONS.

Some great points on customer segments:

• Reference: Geoffrey Moore - Crossing the chasm
• Get your early adopters to become evangelists, help you cross the gap
• They give feedback and a slightly different perspective
• Invest in retention more than acquisition --> referrals
• Early majority requires training/support/documentation than early adopter
• Early adopter term applies across many fields -- projects, organizations, etc.
• Influencer -- Applies to music, cars, etc.
• Identify people that have an active need, ask them questions
• When they have a clearly identified problem, and the pain is high enough, they're much more open to new stuff
• Segment your customers by talking to them and identifying similarities
• How do you identify evangelists?
• If they're supporting other users or otherwise being vocal (in a positive way)
• Stats: Who is the most effective at bringing in users? Often the same people that use it the most
• When you identify evangelists, give them stuff, help them help you
• The biggest skeptics can become the biggest evangelists
• Personal touch helps engagement -- send a note, give a phone call

That's it for today! What were your takeaways from the session?

Lean Coffee: Fast and Focused

Adil at My City Lives hosted today's Lean Coffee about being "fast and focused".

Ironically, the topic drifted a bit, but there was a lot of great insight to be had, including:

• Common Problem: Doing all parts in parallel - not a nice linear flow
• There's a tendency to not do true customer development -- instead only validating the parts you've already built
• Lean makes a startups a science -- takes away some of the romance
• Question: Is Lean a "true science"? Premise: Fail faster
• If you find out an idea is not valid, the learning from the failure is a success
• Big Bang example: For Retrievr -- Spent $5-6K instead of $50-100K
• Repositioning: Can be creative -- example: instagr.am
• Figuring out behaviour is the hardest part
• Example: People don't actually spend time with their photos after they take them
• Medical software: 6-9 months to fail -- 1 customer validated
• Everyone wants to be the next Steve Jobs
• Be careful of being "married to your idea" -- not willing to change
• Do you want one "at bat" -- where you need a home run -- or a full career?
• What is the shortest amount of time you need to get actionable data?
• Lean really helps with you have a "hunch" -- within a few interviews, have a good idea
• Do you focus on one industry? Good to have a "beachhead"
• Too broad of an idea dilutes the MVP
• Focus is key -- don't be afraid to focus on one segment
• Much more compelling message if you reduce the scope
• Messaging and positioning needs to be unique
• Analogy: getting on a busy subway -- make yourself small and squeeze in

Great commentary from everyone today. Looking forward to the next!

Lean Problem Interviewing

Lean Coffee was hosted today by mad scientists in white lab coats (ie. the Big Bang Technology crew).

We talked about the Problem Interview and various tips & techniques, such as:

• Keep a "perimeter" -- don't go too far outside the topic
• Who/Where/What/When/Why questions (from journalism)
• Why validate?
• Are there any customers?
• Assumption: Your plan A won't work
• No validation = no repeatable sales process
• Beware of confirmation bias: Tendency to seek the answers you want to hear
• Problem interview vs. Solution interview (very different)
• Remember: Can pivot around the business model, solve different problems
• Do you need a script? Helps keep things on track - vs. map or outline
• But more open-ended discussion lets you discover a lot more
• Customers are like kids -- easy to lead them, and have them agree with things they don't actually want
• Should be a conversation, not a formal interview
• They'll tell you the symptoms -- you need to determine the problem
• Keep doing the interviews until you know what the answers are going to be
• Problem: Looking for what's "broken"
• Important: What people say vs. what they do is often very different
• Methodology doesn't prevent you from still missing the mark on a "must have" problem
• Failed products lead to the next one -- always learning
• Answers change in different contexts -- anonymously vs in a group (observer effect)
• Maximize the comfort level to get honest answers
• Warm them up: Ask about themselves, make environment safe
• Technique: Parrot back responses
• Lets them confirm, helps them feel more comfortable
• Discover people's motives

Another great session!

Next week I'm going to be in Orlando on business (I know, poor me) so hopefully someone else can take a few notes.

Problems Worth Solving

Today at Lean Coffee Toronto, we discussed the topic of "Problems Worth Solving".

We focused primarily on Customer Development and validation with some great discussion points:

• Relatively few products ever see "the light of day"
• Very few businesses (10%?) make it past the 2-year mark
• There's often a difference between end user and the person who's going to pay, ie. the customer
• Value chain: Need to talk to everyone, but be careful about focusing only on one piece at a time
• Developing a product inside a service business
• Risk of being introverted when you develop in-house
• Risk of entrenching vision and ability to pivot
• Often need to take a step back and talk to people outside
• Customer development
• Validate your problem first
• Then validate your sales process and ecosystem
• Is it acceptable to sell a product that isn't 100% finished yet?
• Yes. Find out if the idea sells. If yes, go to next step.
• Lean: Is there a kisk of killing bad ideas?
• Yes, but very small compared to the risk of building something nobody cares about
• Most devs are not good salespeople naturally
• Need to develop your sales skill set
• Session idea: Lean sales?
• Danger of "sales people" do customer validation -- might get overly optimistic early results
• Using Google ads, etc. to test hypothesis / validate customers
• A few people had tried this
• Kickstarter is essentially the Lean model (but need a US bank account)

Thanks to everyone for their participation, and to Mark at BNOTIONS for hosting and moderating.

Lean Metrics

Chris Eben hosted this morning's Thursday session of Lean Coffee Toronto at The Working Group.

We chatted about Metrics, including:

• What are metrics? Defining the things that are most important to your business
• Don't base decisions on metrics until you know they're the right metrics
• Start at revenue and work backwards to find out the actions that lead to revenue
• Be careful about which numbers you're basing decisions on:
• Does your sales funnel indicate whether your pricing is wrong?
• ...or if you're trying to sell to the wrong people?
• Try to see where the bottleneck is -- eg: What are they key indicators of dropoff?
• Don't make decisions on the "marketing/vanity" metrics
• Another thing aggregate metrics often don't tell you:
• One user might be 10x more valuable than another
• How do you know which ones?
• "Stop listening to" and "start watching" your customers
• Product-market fit: 40% of your users would care if you disappeared
• Can't apply metrics from one customer segment to another
• ie. early adopters vs. majority
• Track at least one key metric in each part of the AARRR model
• Practical example:
• If you notice that conversions suck after 1 month, could be "honeymoon period"
• Trim eval period back to 10 days and improve conversions
• One of the best tools: Another set of eyes, second opinion
• OKCupid demographics data set overviews -- generally useless but entertaining
• Need to change your key metrics you have as you move into new business phases

We also spoke briefly about my recent software project management survey, how survey design is difficult, and how we could spend an entire session talking about surveys. I'd be happy to plan and moderate such a session, but would need a location.

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!

Lean Marketing

I attended the brand shiny new Tuesday session of Lean Coffee Toronto today at the awesome BNOTIONS headquarters at Yonge and Bloor.

My summary follows:

• Thursday's session of "How to spend $5,000" apparently wasn't the right approach to the discussion
• (good thing we got a second try :)
• Different parts: Researching vs. Positioning vs. Building Demand
• Can you describe the product in a few short sentences? (ie. the length of a Google Ad)
• Very important to have consistent messaging
• Creating the UVP (unique value proposition) is the hardest part.
• Technique: "It's like X for Y"
• Example: It's like Dropbox for Development Environments
• Pros: You can use all of the marketing efforts from X for free!
• Cons: Helps describe the What, but not necessarily the Why
• 6 steps: (iterative)
• Problem
• Values
• Market
• Ideal consumer
• Competition
• Positioning (USP)
• Technique: 3rd-party re-explanation:
• Explain to someone, then have that person explain it to someone else new
• Tip: Don't try to deliver too many different concepts in your message
• How far along do you need to get to get proper feedback? Idea? Mockups? Prototype?
• Answer: All of the above. Start with an idea and move up from there as you get validation
• Pivoting: Do you change the market or the product? (or both?)

And some Meetup-related stuff:

• Next meetup: Same topic both days again
• Perhaps some attempt to:
• Post reading material prior to meetup (and have people actually read it)
• Keep the discussion on topic via the moderator (a difficult task, to be sure)
• Look at the San Fran Group for topic ideas and literature
• Check out http://dooo.sh/it/ from Big Bang (blog post)

Please comment on this post or email any corrections, additions or updates.

Until next time!

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!

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!

Annual Planning

My weekly notes from this morning's Lean Coffee Toronto on "annual planning":

• When to plan:
• Before your fiscal year, or
• Before the calendar year
• Strategic vs. Financial -- which one first?
• Goals and Vision:
• Does it include longer term goals?
• Does your team know them?
• Review:
• Monthly?
• Every 3 months?
• Review the previous year's goals and results?
• "Doing" lists:
• What to start doing
• What to stop doing
• What to continue doing
• Employee 1-on-1's
• Know their goals
• Make sure they understand your vision
• Goals and vision need to be aligned with company's

We also talked about some goals and visions for Lean Coffee itself:

• Learning, supporting, networking
• Sharing of specific information (ie. real problems, real numbers)
• All advising each other
• "Group therapy"
• Case studies
• Want honest critique and feedback
• Establish a standard format

Really enjoyed the "Café Americano" and the great discussion. Always such a great way to start the day! :)

If you're interested, check out the HTML5 Meetup tonight. I'll be doing a brief intro presentation, followed by discussion and networking.

Customer Development

Another really interesting Lean Coffee Toronto this morning.

Here are some of the notes I took from the conversation:

• Always have checks and balances in place
• Verification: The best way to determine product-market fit
• Dave McClure metrics for startups (The "AARRR" presentation)
• Four Steps to the Epiphany (book by Steve Blank) (.pdf file)
• Canadian startups tend to skip this step or do it too late
• Use a rapid prototype instead of just an idea
• Don't redesign the whole thing just based on your first customer's feedback
•  Know when to say no
• Customers may not know what they want
• When first starting have the "seven conversations"
• Measure. Validate.
• Look for lovers and haters -- anything that evokes a strong response should be investigated further

Some personal thoughts on the subject:

• You can learn a lot from "negative" feedback
• If someone tells you they won't use your product, ask, "Why not?"
• You may have a good idea or product, but lack the ability to explain it well enough
• The most successful products are the ones people actually understand
• It can take a long time and many iterations to figure out your "pitch"
• Don't stop working on it until you can tell people "get it" -- for better or for worse
• If they are indifferent, you have a problem (mentioned by Andrew near the end of the meetup)

Great conversation again everyone! An hour just isn't long enough. We always seem to be just getting into the good stuff when wrapping up :)

How to fail successfully

Today I attended Lean Coffee Toronto's 15th Meetup. What a great group of people and amazing discussions.

We talked about the concept of "failing successfully". Here are a few notes I took:

• Don't put all your eggs in one basket
• "Parallel prototyping" helps -- better results with the same overall effort
• Make sure you learn lessons for future projects
• Admit your mistakes frankly
• When do you stop?
• Sometimes it's very hard to let go of an idea
• Always get external feedback -- advisory boards, etc.
• Example of successful failure: the production of Iron Giant
• Metrics and measurement:
• Define success and define failure
• Did you make money? Did you build your brand?
• Tie your metrics back to goals
• Always do a port-mortem

... and some thoughts of my own on the topic:

• WGMGD -- What gets measured gets done
• My biggest take from a Services Marketing class I took a while back
• Don't be "stealthy"
• Get your product out there as early as possible and get feedback
• "First to market" and "stolen ideas" are myths
• "Failure is always an option"
• Mythbusters and Adam Savage are awesome :)

Thanks again everyone for a great meetup!