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