I was lucky enough to get an advanced copy of the Lean Entrepreneur* and have been reading it on my commute for the past few weeks. After having spent time reading many other Lean books and blog posts, I’m excited to see this book released. In the interest of keeping a review MVP, here’s why you should, and shouldn’t read this book:
This book is like an FAQ on Lean. It beats down all the stereotypes (like Lean is only for software) with specific examples and thoughtful explanation.
2. You want to hear real life case studies of Lean in action.
The authors went to great lengths to get great case studies from everything from hardware companies to commercial cleaning products to prove that you can apply lean to *any type of business*.
3. You want help evaluating how you’re really doing at being Lean.
One of the best things about this book is that between the concepts and case studies are a ton of checklists that help you see if you’re really properly evaluating your company at each step of the lean process.
I’ve been doing lean basically full time for 3.5 years now and I still learned a lot. You’re bound to learn a few new things.
2. You like detailed, helpful diagrams and pictures.
Sorry, I know we’re all supposed to love @FakeGrimlock, but I’m underwhelmed by his drawings. I don’t think his drawings added much to the book or were helpful other than to give the book a lighter, more accessible feel.
3. You were hoping for the nitty-gritty details of exactly what to do.
This book won’t help you write your customer development interview script (here’s a post for that) nor help you find the phone numbers of your customers. What it will do is answer the critics’s questions and get you asking the right questions about your business.
Overall, I thought this was a solid book that adds a lot to the conversation of the evolving Lean Startup movement. I read a lot of books and this falls in at a 7.5 on my rating scale.
It goes much further and deeper into how to approach actually doing Lean in your business than Eric Ries’s The Lean Startup book. I hope that some of the people at companies with case studies in the book will share some more tactical advice that didn’t fit in this book.
“You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.” – Steve Jobs, Stanford Commencement Speech, May 2005
One of the most common questions I’ve heard over the past few weeks from younger members of our community, especially students, is how to build a career in startups. Unlike climbing the corporate ladder, it’s not a straight forward, linear process. As I just made a major move in my career to join KISSmetrics, I’d like to share how I ended up going from Boston startup connector to SF Product Manager. This will also help answer questions I know some of you have about how I landed this job.
Connecting the Dots – The unorthodox journey of one startuper
To really begin this story, you have to go back to my days at oneforty. When I joined oneforty, I was given the title of Customer Development Manager and asked to help make oneforty a Lean Startup. Since I had only spent a few months working part time with John Prendergast as his cust dev intern, I really had very little experience. Laura Fitton, oneforty’s founder, took a leap of faith I could learn it, but she also was wise enough to know I could not do it alone. That’s why she set me up to have mentors from day 1.
Immediately upon starting at oneforty, Laura connected me with two Valley Lean experts she got to know while she was out west raising money for oneforty and Pivotal Labs worked to build V1.0 of the site. These people were internet mentor legends, Dan Martell and Hiten Shah. Once a month I seemed to find myself on the phone getting what I would happily call an “ass-kicking” from Dan helping me realize all the things I was doing wrong and most importantly, could do to improve my custdev methods. Roughly every other month I would have a similar discussion with Hiten.
These discussions were priceless in my career development. I would take copious amounts of notes and seriously reflect upon what Hiten and Dan discussed with me each time. I would also share these notes with Laura to make sure I truly understood them and to force myself to teach someone what I learned (a great tool for deepening your understanding).
A Chance Meeting
Fast forward 12 months at oneforty and it is April 2011. I’ve learned a ton about customer development and lean startups, enough that Trevor Owens, founder of Lean Startup Machine (which was just getting off the ground at the time) invited me to be a mentor at the Lean Startup Machine event in New York City. As destiny/fate/karma would have it, Hiten Shah was also one of the mentors for the weekend.
Being a mentor traveling in from another city is very different from mentoring in your home city. When you’re in your city, you likely only stop by for a brief period of time that fits your schedule. But, when you go to another city, you find you spend the vast majority of your time there…which both Hiten and I did in New York City.
After Saturday’s activities wrapped up, all the mentors went out for drinks. This turned into an audition and test for me.
With Hiten Shah to my right and Patrick Vlaskovits (co-author of the awesome Lean book at custdev.com) grilling me on all sorts of topics from lean startups, to lessons learned at my first real startup job to topics on psychology and body language. At the time I was dead set on leaving oneforty to start my own company so all Hiten said was, “if you raise money for your idea, come out west and I’ll give you some intros.” He also encouraged me to quit ASAP to start doing my own thing if that’s what I was passionate about. Coincidentally I did just that on Monday back in Boston.
Out on my own, but on the Radar
After leaving oneforty, I set out to start my company I’ve always dreamed of. After spinning my tires for 6 months though, I found myself pretty empty handed and a bit discouraged. After a meeting with Sim Simeonov, I refocused my efforts on the lean startups movement. After a month of interviews and discussions, I published the results, which caught Hiten’s eye when they were tweeted out.
Hiten DM’d me after my first post and we had a call to discuss my findings, which confirmed his suspicious: Lean as a concept is far ahead of actual solid execution of it in the startup world. At the end of the chat, I mentioned that I was planning a trip out to the Valley in early December and asked if we could meet while I was in town. He agreed.
Meeting in SF and an Offer
When I met with Hiten in December during my Valley trip, we barely talked about KISSmetrics or my potentially working there. The vast majority of our one hour chat was about my strengths and weaknesses and where I was at in my startup career.
Hiten tried to sell me on the idea that coming to the Valley would solve many of my problems, but I presented a series of challenges that I felt prevented it from being the right decision for me. He countered I could come work for him and it would resolve many of them. I noted the offer, and it did intrigue me, but it mostly sat just sat in the back of my mind.
By the end of the trip, I was much more interested, thinking it may be the next logical step in my career. On the flight back, I emailed Hiten expressing great interest in the role, especially as I discovered I could potentially be filling the shoes of the departed Cindy Alvarez (who just weeks before my visit had left KISSmetrics to join Yammer).
With the holidays fast approaching, Hiten and I took things slowly, talking about the the potential first in loose terms then in much more specifics. After one phone call where Hiten lifted the proverbial kimono on everything I wanted to ask regarding KISSmetrics as a business, all that was left was an answer to the question, “When can you come meet more of my team for an interview?”
With that, I booked tickets to take a quiet trip to SF for the interview in early February.
Sealing the Deal
With an interview scheduled and a focus on landing this job, I employed my proven job acquisition system that requires me to produce, insightful, valuable content for KISSmetrics. I happened to be reading a psychology book at the time and so I produced a massive document on different ways KISSmetrics could improve their site based on the principles I found in the book. I also aggregated all my lean learnings in one place so the rest of the team could see the credibility in Lean that Hiten knew I had.
I wasn’t sure what to expect in the interview. All I had were the names of the people I would be talking to and a vague idea that we’d talk about the KISSmetrics product. Most of the interview turned out to be focused on implementation: how would you do this, what’s wrong with that, what would you do in this circumstance.
Despite not really preparing for such questions, I was able to crush the interview for one simple reason: the last startup idea I had worked on was a Lean Product Management tool. While the idea didn’t pan out, it led to me talking to 40 people who run product at companies. Through this, I picked up on many best practices and common mistakes. I was armed with more than enough fodder for the interview and believe I’m really armed to take on my first full time product role.
Conclusion – You Never Know…
Whether it’s lessons learned in a failed startup idea’s customer development interviews or an event you’re randomly invited to in another city, you never know what will lead to the next great opportunity in your career. Startups are all about embracing serendipity. Embrace the machine and you never know where you’ll end up.
Do you have an example of unrelated events that looking back were instrumental in a step or moment in your career?
For the past couple of months I’ve been working on ideas in the lean startup space. As explained in previousposts, it seemed logical: I have a solid background in it from my days at oneforty as well as consulting before and after and the subject is hot now with Eric Ries’s book out, Steve Blank’s book coming soon and a seeming never-ending discussion about the principles in our community.
After initially exploring the opportunity to provide tools for performing customer development, I pivoted to the broader idea of providing a tool to help with Lean Product Management. Initially, the response was great; I wrote a blog post on the concept of Lean Product Management and it was universally loved. It’s the most read blog post on my blog ever and it generated significant inbound interest. At the same time, I talked to quite a few people that had interesting feedback on the process and where they were coming up short. I also met a number of people and companies that needed help in the areas I was looking for the product to work. However, in the end, a few major issues are leading me to place this idea on the scrap heap with the other previous 8 ideas I’ve evaluated over the past year.
The Concept – Product Chasm
The biggest problem in developing this idea was a major gap between the buy-in to the concept I wrote about and the actual execution of the concept.
In the product management world, it seems everyone has a different way of implementing it. Some people are absolutely hardcore and have impeccable wikis and project management tools (like a 1-2 punch of Jira and Confluence). Others keep it loose with simply a Google Spreadsheet and a Kanban board (both real and virtual). Finally others have utter chaos and have absolutely destroyed their project management tool by jamming everything in there (usually Pivotal Tracker or BaseCamp). It seems individuality is greatly valued in the world of product management…
This presents a series of problems:
1) There is no silver bullet
The difference between a Kanban board and a wiki based product management tool is significant. This would mean any tool that was valuable for one is unlikely to be interesting to the other.
2) Marketing is a nightmare
With everyone having their own ideas on how to implement product management principles, targeting and acquiring a customer would be extremely difficult. Even those that I confidently believed had problems in their process often either A) did not perceive there was a problem or B) even if they knew they had a problem, they weren’t actively seeking a solution.
3) There was no MVP
As I talked to over 40 people who owned product at their company, I found no consensus on what part of the process was broken for them; without this consensus, there was no way to build an MVP. More importantly, the lack of consensus showed no agreement on a core problem which could be used as the tip of the spear towards acquiring customers and building out a platform over time; building a Lean Product Management tool would take significant time to become a complete, full life cycle solution, but there was no clear path for doing so.
A Greater Problem – Passion?
One of the most fascinating things about my trip to Silicon Valley in December was seeing how entrepreneurs interact with one another there versus here in Boston. Specifically, I’m talking about the first questions an entrepreneur is asked about their startup/idea. There is no right or wrong here, just different.
In Boston, common questions are:
What stage are you at?
How will you make money?
Do you have any customers?
In the Valley, common questions are:
Why are you passionate about this idea?
How will you acquire customers?
What is the big vision for your idea?
Of all the questions, the one I found most jarring was, “Why are you passionate about this idea?”
Over the past 9 months of questing for an idea, I’ve been attacking ideas with laser focus and rigid customer development methodology. While this has likely saved me a lot of time on any of the ideas, it also was devoid of the thought of passion; was I ever really passionate about an idea in the moving industry or restaurant services? Being completely honest with myself, I don’t believe I was.
Jason Baptiste wrote a blog post back before Cloudomatic (which came right before he and his cofounder discovered the OnSwipe opportunity) which covered a series of ideas he was thinking about. He got a great response from people showing who also cared about the ideas. I may do the same soon.
I had a great conversation with Eric Paley after a Dart Dinner early this past fall about my struggles to find an idea. He told me, “I think founders have to believe in a little fate; the right idea will find you at the right time.”
Those words have stuck with me and ring true with my first real venture: Greenhorn Connect. I could not have had that idea come to me at a better time both personally (it was the only way for me to build credibility in the Boston startup ecosystem and land a job 4 months later at oneforty) and for the ecosystem (October 2009 was the very beginning of our ecosystem’s awesome resurgence…the perfect time for a uniting site).
More importantly, I wasn’t even looking to start something when Greenhorn Connect happened. It just grabbed me and I couldn’t not do it. As many of you who knew me then may remember, I was a man possessed to make it work. Despite all the obvious reasons not to do it, I still did it (Lean Startups principles would have definitely it shot down). I will never forget my first Mass Innovation Night after launch and Adam Marchick and Michael Cohen both giving me the proverbial “You’re crazy. Why are you doing this?” speech. Both are great converts now, but it was only the passion and a touch of fate/destiny/luck that really possessed me to so blindingly go after the idea.
After 9 months of trying to force ideas, I’m trying to get back to basics. I need to find my passions and try to let the right idea find me instead of desperately grasping in the dark for ideas or trying to force an idea through the grinder. A quote from Drew Huston has stuck with me in this process. He said that of all the 5 or 6 companies he’s started, only Dropbox felt like, “the wind was at our back.” That feels telling and reminds me of the commonly discussed need of Skill, Luck and Timing to build a truly great company.
It’s been 9 very long months since I left oneforty. While even today I have a runway left that most young entrepreneurs would envy, I’m realistic about my endeavor to start something; how long should you stick with it before you realize the timing isn’t right?
The great entrepreneurs say it takes Skill, Luck and Timing to build a great company. I believe I have the skill to build a great company, which is why I left oneforty. I was also inspired by this oft-tweeted blog post encouraging you to quit your job and start a company even if you don’t have an idea. However, as time continues to slip by, I ask myself if I’m making the most of my time.
That’s why I’m beginning to evaluate working opportunities for the first time since I started this process.
I’ve thought a lot about the framework of what I’m looking for; not needing the money gives me the luxury of weighting all my other priorities over compensation. I’ve realized the most important things to me are:
Working on a really big idea
Working with a truly great leader I can learn from
Having the opportunity to further develop skills that are assets to a business founder
I have ZERO regrets of how I’ve spent my time since leaving oneforty. I’ve learned a tremendous amount about myself, what I need in a technical cofounder and thanks to this most recent idea, how to manage product. I’ve also continued to build my network which is filled with mentors I know I can count on for help when I need it and people I can’t wait to invite to join me in working on that great ideaI know I’m going to find.
Like Steve Jobs said in his Stanford Graduation speech, “you can’t connect the dots looking forward; you can only connect them looking backwards.” If you found me 3 years ago and told me I’d have done the things I’ve accomplished thus far, I wouldn’t believe you. However, looking back I can see how critical each step was in this crazy journey. Frankly, the less logical the next step, the more it seems to have worked out for the best.
I can’t wait to see what’s next and hope you’ll stay tuned; my beliefs are unshaken: I will build a great anchor company one day.
It happens to us all. Your startup is cruising along, or at least you’re really busy running in a million directions. Maybe you’ve also got pulled away with some personal issues like selling your home, caring for children or relationship challenges. No matter what the cause, you get away from the most important thing: Getting outside the building and talking to customers.
So knowing that you have dropped the ball and need to pick it up again, what do you do? How do you get back on the customer development horse?
How Do You Get Back on the Customer Development Horse?
Step 1: Review your previous notes
The first thing you should do is go over all of your past customer development work. Look at how you’ve already progressed and jog your memory on what you have already learned. This should include previous raw interview notes, any summaries of those notes and progress from your Lean Canvas.
This is a good time to find out if you’re taking good enough notes! If you can’t efficiently figure out what you learned, than anyone else using your notes, canvas and summaries can’t either. A great Lean Startup should be keeping their team and their advisors up to date on customer development progress and most of what they’ll have to go on are these notes.
Step 2: Schedule new customer development interviews
Once your memory is set (this should hopefully only take an hour or two if you’re organized) then go back and see if you had any outstanding interviews to shedule. This is your low hanging fruit to schedule meetings. Reconnect with these people immediately and schedule new meetings with them as soon as possible.
Customer development is a numbers game, so regardless of if you had oustanding interviews, you need to get more feelers out for additional people to talk to; not everyone you reach out to will respond.
Here are a few ways I’ve found work to get more customers to talk to:
1) Your Early Adopters: Ask any of your early adopter users to talk if you haven’t talked to them (also get product feedback if you haven’t connected with them lately).
2) Ask Past Interviewees for Intros: Ask any past customer development interviewees that fit the problem you’re solving if they know anyone they could intro you to. (You should ask this at the end of any interview…it has a 4x success rate of responses compared to cold emailing.) In general, people want to be helpful and if you really are working on solving one of their problems, they’ll be happy to connect you with someone they know that also has the same problem.
3) Cold Email: Cold email, call or walk into the buildings of your potential customers. Unfortunately, this mode has a particularly low success rate (expect a 10-20% response rate on cold emails at best, but 5% isn’t unusual) so be prepared to have to do a lot to get results. I usually email 10-20 people at a time expecting a few responses.
If you know a good blog post on tips for cold emails for customer development, let me know and I’ll link to it here.
4) Use the Reverse Lead Model: I’ve recently fell in love with the reverse lead model: if your startup serves a group their has their own customers that your tech supports (such as a real estate agent software that helps them interact with homeowners or moving company software for booking moving deals), then pretend to be a lead for your target customer (ie- pretend to be a homeowner or someone about to move). Then turn the tables when they call you.
The trick I’ve found is when they call play along at first but be chatty. Pretend you’re still selling your house or moving, but then ask them about the software they use as you talk. As this first friendly conversation goes their way…then switch it up to talk about the problems you think they have and see if they confirm. If they do then pitch your product and try to get a face to face meeting (or separate phone call with a decision maker) to talk more.
Trust me, this works. I’ve actually had people complain to me about their software in these conversations…talk about a self-identified problem!
Note:This will take time. I’ve found that it generally takes a week to week and a half to get back into scheduled interviews; if you start emailing on Monday, you’re unlikely to have a full plate of interviews until the middle of the following week.
Step 3: Get your customer development questions updated
Now that you’ve started filling up your schedule with more customer development opportunities, you should determine what your goals are to discover in your current round of customer development.
Go back to your Lean Canvas and look at where you stand in testing assumptions. Remember that the goal is to test the riskiest assumptions you’ve made. If you’ve already verified some, then you should begin testing new assumptions.
Great customer development starts with a good script of questions. It will make you more confident and comfortable in the interviews and make sure you don’t forget to ask something important. You can (and should) go off script based on where the discussion takes you, but this is your anchor to bring you back to the key things you want to discover.
Step 4: Set a routine for staying on the horse in the future
In the end, the hope is you won’t fall off the horse again. The best way to do that is to set yourself a plan to keep it in your routine. This can be as simple as carving out a few hours one day a week to review customer development progress and see how many interviews you have upcoming. If you drop below what you find is an acceptable number of pending interviews, go back to Step 2 and try to get a few more in the pipeline.
You can also give yourself an added boost with some external accountability by setting up to regularly update others on your customer development. At oneforty, I sent out bi-monthly reports to the entire team on key takeaways from customer development and updated the management team every 4-5 interviews. This ensured the whole team was up to date and I had extra motivation to try to keep customer development cranking.
Getting outside the building is never easy, but if you’re committed to being a lean startup, you have to stay on top of it. It’s easy to get distracted by other responsibilities. When that happens, now you know what to do.
What advice do you have for Lean Startups trying to maintain a routine of customer development?
“Customers live outside the building.” Every startup is well served to remember this and make sure they’re reaching out to their customers/users to understand them. As customer development manager at oneforty, I’m on the front lines of that effort and our overall goal of implementing Lean Startups methodologies. I’d like to share a few things I’ve learned along the way.
Lessons Learned in Customer Development
1) Ask the right questions the right way.
One of the key tools in customer development is the user interview. At its heart, you’re trying to understand what problems your users have and how your startup may solve some of them. The greatest challenge in these interviews is keeping the discussion focused on user problems and frustrations instead of features and their ideas for solutions; users are notoriously bad at suggesting features they need or would actually use, so you absolutely need to focus on what problems are behind those feature requests.
There are some great contributions in the blogosphere to help guide you in preparing your interview questions:
In addition to interviews, metrics are the other big piece of customer development. You have to understand what’s happening on your site and decide what aspects you will work to improve and in what order.
The best way we’ve found to track this is to consider everything under Dave McClure’s AARRR model. There are all kinds of numbers we can measure on oneforty, but by grouping them into categories of Acquisition, Activation, Retention, Referral and Revenue, a clearer picture of the meaning of all the numbers is formed. We then take those numbers and focus our engineering sprints on improvements in one of those categories at a time. This helps engineering understand what they’re building while also making it easier for us to measure for improvements based on those efforts.
3) Communication is key…inside and out!
While Jeremy and I dive into the metrics on oneforty each week in great detail and I interview many users to understand their problems, that’s just the beginning of the work for customer development. It is essential that what is discovered is shared with the team in a concise and clear fashion; they need the information to act on what we’re seeing and understand the reasoning behind development decisions. At oneforty, we go over key metrics results with the entire team for 5-10 minutes each week and have a monitor on the wall in the office that displays 3 core metrics we’re focused on right now.
In addition to communicating within the team, it’s important to also communicate outside. First, you always want to be tweaking your interview questions based on how your site or product is changing; if you’re considering adding a new feature it is important to understand if it solves a significant problem or is particularly compelling for users before you devote significant engineering time. The best way to do this is through full interviews, but with tools like KissInsights and SurveyMonkey available, you have easy ways to ask large groups of people questions as well.
The other form of outward communication that’s important is with others doing customer development. Often, it is hard to tell what is a good number for a metric and if you don’t know, you may be trying to improve something that’s already well optimized.
Recently, I discovered two key figures from asking others:
A 10% response rate on email requests to do a customer development interview is actually good.
For email newsletters, a 30% open rate and a 20-30% click through are solid and standard across most industries.
To learn these numbers I didn’t do anything special; I simply talked to one of Laura’s mentors, Tweeted a question, tried AskDart and asked some friends. It didn’t take very long, but saved me a lot of time in the long run.
4) Pattern recognition is your most important skill
In the end, I think customer development is all about recognizing patterns. You don’t memorize everything a user says in an interview; you’re merely looking for commonalities across many interviews. You should be asking yourself, “Are similar users mentioning the same frustrations or questions?” These patterns are how you identify your “earlyvangelists” and identify the most important issues to work on.
You can also look at metrics the same way. The goal is not to have to measure every single activity on your site. Rather, you should be searching for a few specific activities that can lead to the needle moving on many things on your site.
Customer development is an essential part of an early startup’s life as they search for product market fit. It’s a challenging job, but fortunately there are tons of great resources out there and an open community sharing their knowledge. If you’re looking to learn more, search for content from Steve Blank and Eric Ries, look for the hashtag #LeanStartups on Twitter and look for Meetups around you on this topic.
What have you learned by doing your startup’s customer development?
In honor of both the Lean Startup Circle Meetup on Thursday and the Lean Startup Machine coming this weekend, I’d like to share a few lessons I’ve learned in the past year as I’ve served as Customer Development Manager at oneforty and been actively learning the Lean Startups methodology.
5 Lessons Learned in a Lean Startup
1) Don’t ask what people would pay for. They lie.
Yes that’s right. Even Honest Abe wouldn’t have told you what he’d really pay for if you showed him a web app and asked what he’d pay for on top of what you showed.
Customers are terrible at explaining their problems and understanding the root issue. As the saying goes, the one certainty for a patient seeing a psychiatrist is that what the patient says is cause of their problems is never the actual problem.
Even I have lied. I was talking with Chris Keller about his awesome tool Followup.cc, which is an email reminder system, and I said, “I would pay to be able export all of my reminders to my Google calendar.” Chris wisely also looked at engagement and based much of his pricing system on number of reminders, but he also put the calendar export in his paid version. I am now a paying customer of Followup.cc but have yet to actually use the Google calendar system.
Did I intend to lie? Of course not. But it just goes to show the mindset you can get in and how far from the truth it can be. Don’t ask people what they’d pay for.
2) Nothing beats getting a customer to actually pay for something.
There is no better validation for your business than getting a user to actually pay for something. Despite the true value of your time, few people actually account for this. That means they are actually quite likely to be willing to use your free product, while having no intention of ever paying for it.
Paying also moves you beyond the realm of being a favor; friends, acquaintances or just nice guys, no one will pay for your product unless it really solves a pain or strongly interests them.
As an added bonus, once someone pays for something, they have expectations. That means that their feedback will be stronger, because they gave you their money and now expect that you will deliver on what they hoped they were buying. This feedback is priceless, as building something that satisfies them can be built into the repeatable process that goes into a sales funnel.
3) You have to learn the customer’s language.
You may call your product anything you want but if it and the language you use to describe it doesn’t resonate with your customer, you’re unlikely to move forward. You need to understand your customer’s language and make your product speak that language.
The best way to do this is to look at what words your customer uses to search for the problem you’re solving and, of course, the customer development interview. Remember, your customers should be doing 70-80% of the talking in your interviews.
4) A customer’s stating a problem is more valuable than a customer agreeing with a problem you present.
One of the key tenants of Lean Startups is that you’re solving a customer’s pain. Often the question is if what you are building is a so called “Vitamin,” which is nice to have, or you’ve created a “Pain Pill,” which they definitely need.
One indicator of which side of the Vitamin/Pain Pill coin your product is on is how the problem that your product solves is surfaced. If in the middle of your interview (before you pitch your solution) the customer talks specifically about the problem you’re trying to solve, you have a much stronger indicator of pain than if you ask them if they are experiencing pain in the area you believe is a problem.
Now, this does not mean that someone who doesn’t come right out and say your problem isn’t a potentially valuable customer. However, when you’re looking for those early adopters (aka- earlyvangelists) you should be thinking about who most desperately needs your solution and that is likely people who have the problem you’re trying to solve on top of mind.
5) Be precise in your Hypotheses.
So you think you have a product solution that is the greatest thing since sliced bread? Great. But who is it for and how does it solve a key pain for them?
One of the risks in creating your lean startup is that you forget to get specific on your hypothesis. Don’t say “this is for doctors”; say “this is for pediatricians in suburban environments that have small, private practices.”
The reason you need to be specific is to avoid false indicators. If you don’t make your hypothesis specific, than you are very likely to talk to a wide range of people. When talking to this wide range, you may not find the interest you would otherwise if you specifically went after a specific group. You could end up talking to a bunch of chiropractors and surgeons and never realize that the reason there was no interest in your product wasn’t that it’s not a great idea solving a problem; no one was interested because you weren’t talking to the right people.
There’s a seemingly endless amount to learn about Lean Startups, so no matter what stage you’re at just remember: Stick with it, Be patient and Don’t be afraid to ask for help.
There’s a great community on Twitter (look for hashtags #LeanStartups and #CustDev), many awesome blogs (Eric Ries, Ash Maruya, Dan Martell, David Cancel and many others) and of course great events (Lean Startups Circle) to help.
Running a startup puts a ton of responsibilities on your plate. From marketing to sales, ghetto-HR to accounting, development to project management, you’re wearing a million hats. We all know that Lean Startups methodology and customer development are important, but *actually practicing* it can be hard (if you’re not familiar run to CustDev.com *right now* and get Brant and Patrick‘s book The Entrepreneur’s Guide to Customer Development ASAP!).
As you commit yourself to “getting outside the building” to talk to your customers and truly quest for Product-Market Fit, it’s essential you make the most of those discussions. One of the hardest things for newcomers to customer development is structuring their questions for customer development, so I’d like share how I structure interviews to maximize their effectiveness.
I structure my custdev interviews in 3 parts – People, Problems, and Your Solution. Depending on the person, this question flow generally takes me 30-45 minutes to go through. (Note:This structure is best suited to B2B customer development, but with a little creativity, you can definitely adapt this for B2C interviews)
1) People – Aka – Who Are You?
Before you get into anything about problems or your solution, you need to figure out who you’re actually talking to. This both warms up your interviewee with some softball questions and gives you an opportunity to build some rapport with them.
Some example questions you could ask:
What is your name and role at your company?
How do you fit into your company’s department structure? Overall in the company?
What is your budget like? Who has to approve your purchases?
How do you discover new products for work? Do you need any approval to try them?
Have you tried anything new recently?
What is a typical day like on your job?
How much time do you spend doing [task X]? (Task X being anything they mentioned in their typical day that stood out)
Do not shortchange this opening section of questions! You don’t need a novel on their daily life, but you *do need* enough to be able to understand their role within their company, who key players are and a general baseline of their sophistication. All of this will help you later pattern match who the user type that is most receptive to the problem you’re solving and the solution you offer.
2) Problems – Aka – What are your greatest pains?
This section is where you try to find out whether the person has the problem you believe you’re solving. Your goal is to not lead them to your problem. The less you lead them while still hearing your problem being mentioned the more validation you have!
Some sample questions you could ask:
What are your top 3 challenges you face in your job?
What are your top 3 challenges you face in your job related to [industry X]? (Industry X being the one your startup is in)
If you could wave a magic wand and instantly have a solution to any of those problems…what would the solution be?
Dig deeper into their typical day on anything that sounds painful or expensive. (You can add some hyperbole here to get them to rant a bit by saying things like “that sounds inefficient…” or “that sounds expensive…”)
How have you dealt with or solved [Problem X]? (You’re looking to find out if they’ve hacked a solution together themselves. If they have…ask for a copy of it!)
People love to talk about themselves, so let them go nuts here and really rant about their problems (i.e.- Shut up and listen!). Generally, people are terrible at proposing solutions, but you want to hear generally what they envision as solutions or see what they’ve cobbled together themselves.
Notice, you haven’t mentioned your solution or problem yet. If they don’t mention your problem specifically, then as you finish this section of questioning, you should directly ask them if what you think is a problem is a problem for them. Whether they agree it’s a problem or not, you want to then probe why it wasn’t one of their top problems.
3) Your Solution – Aka – See if your idea survives customer interaction
If in your discussions in part 2 your problem you think you’re solving comes up naturally from your interviewee you’re on the right track! Bonus points if the way they describe solving it with their “magic wand” remotely resembles what you’re doing.
No matter what happens in part 2 you should discuss with them what you thought the problem was and what your solution is. Getting validation that they wouldn’t be interested in the idea is just as helpful as finding out they love it; either they’re not a customer or you are learning what your customers want instead of it.
Some sample questions you could ask:
Walk them through the problems you believe your solution solves. Do they agree?
Does [your solution] solve any of their problems?
Would you be willing to pay for our solution? How much? (Don’t be afraid to probe for the pricing you know you want…”Would [X] be reasonable?”)
If they’re willing to pay your price and like the idea then…”Would you be willing to start right away?”
If all goes well and you really are solving a pain, then your customer should want access to the product right away. More likely, you’re going to learn a ton about what they do and do not want and your idea will begin evolving.
This basic structure can carry you a long way towards some great validated learning about your idea and the market’s desire for it.
A few last things to remember:
1) Take Good Notes or Record Everything!
– Once you’ve interviewed 8-10 people, you should be going back over all of your notes and look for patterns. This includes especially looking for patterns in the Part 1 section to see what all the people that agree you are solving their problem have in common. You should summarize your notes then and share with your team.
2) Have other team members sit in on some interviews
– A good customer development focused company will have everyone involved in the process. Performable, pre-HubSpot acquisition, had their engineers spending 30% of their time on the phone with customers. Nothing helps someone do their job better like understanding who they’re building/selling/marketing for.
3) Be conversational
– It shouldn’t feel like an interview! They should feel like they’re just having a conversation with a friend about their problems at work. The more comfortable they feel with you, the more they will open up.
4) Go off script
– The best stuff comes when you dig a little deeper on something that strikes a chord in the discussion. The script is there to be your roadmap, but there’s no reason you can’t return to it after a 5 minute digression about a specific pain or discovery about how the company operates.
5) If they’ve made an MVP…ask to see it!
– Nothing gives you more insight to a customer than what they’ve hacked together themselves to solve a problem. The best thing you can do is ask to see it, which will give you an idea of what they’re hoping a solution will provide. These people are also the strongest candidates to be great, helpful early adopters of your product.
6) Always follow up
– It’s just common courtesy to thank people for their time and help, but it also opens the door to follow up with them in the future if your product changes and is a fit for them or to invite them to your beta.
7) End with an ask
– Always end your interviews by thanking them and asking them for something. It may be to get a copy of their MVP or even better, ask for an intro to someone they know that might be interested in what you’re working on. In my experience, these intros have an 80-90% success rate in becoming new customer development interviews, whereas cold emails only have a 10% success rate.
8) Be open to new problems! That’s how great products are born.
– As Steve Blank has said, “No idea survives first interaction with a customer.” Don’t be afraid to shift your focus from your first idea to what you’re actually hearing customers want. If you probe in part 2 and find a burning problem…find out how they currently solve it and what they’d pay to solve it.
In the end, you want to find a “hair on fire” problem, not a “nice to have problem.” Think about it this way: If my hair is on fire (literally), and you’re selling buckets of water, I’m definitely going to buy your product. But if I’m cold and wet, I’m not likely to buy your bucket of water right now, but would consider it in the future.
Find customer pain and a solution they desire and will pay for. Rinse. Repeat.
What advice do you have for entrepreneurs doing customer development interviews?
This post originally appeared on Greenhorn Connect here; I’m housing posts on my blog here as well for easy reference.
Whether you interview customers regularly, watch support requests on HelpScout or use a GetSatisfaction or UserVoice – like tool, your startup is inundated with feature requests from your customers. It’s great to have them engaging, but can lead to the dreaded “feature creep” that leads to a bloated, unusable product. What’s a startup to do? The answer may surprise you in its simplicity: use the 5 Why’s.
Don’t build that feature! How to use the 5 Why’s to learn what your customer really is saying
In case you’re not familiar, the concept of 5 Why’s is that by asking a person a series of “why” questions, you can get to the real root cause of an issue. Commonly, the issue can be used to do analysis of technical failures as outlined in a great post by Eric Ries found here. However, this can be just as powerful when you apply it to discussions with customers about features. The power comes from saving you from building things customers actually don’t want or need and surfacing what is really important.
This concept really crystallized for me when I had an experience talking to Chris Keller, the founder of email reminder tool, Followup.cc. I was an active user, but Chris hadn’t decided how to monetize yet. I told him I’d pay for Followup if he provided a calendar to see all my Followup reminders.
There’s just one problem – despite the fact that Chris built that feature not long after our discussion, I’ve never used the calendar even though I am a paying customer because of the core product.
Chris could have avoided building the feature if he had used the 5 Why’s. Here’s how it may have gone.
Me: I’d pay for Followup if you provided a calendar to see all my Followup reminders.
WHY #1:Chris: Why would that make you pay for it?
Me: Because I could then see all the Reminders I’ve set up.
WHY #2:Chris: Why do you want to see all the reminders you’ve set up?
Me: So that I know when I have reminders coming up.
WHY #3:Chris: Why do you want to know when you have reminders coming up?
Me: So I’m sure I know when I should expect a bunch of reminders.
WHY #4:Chris: Why do you need to know when you should expect reminders?
Me: (long pause) …So I’m sure I get all my reminders.
WHY #5: Chris: Why wouldn’t you get all your reminders?
Me: Good question. I guess I’m worried about it not always working.
Chris: Don’t worry. I’ve built Followup to be robust and reliable. Are you sure you need that calendar?
Me: Maybe not.
Your results may vary, but the point is, customers are terrible at coming up with solutions. What they are good at is sharing their problems, which you can solve. The key is to interact with them in a methodical way to get to the heart of what they really need. Next time you hear from a customer that you need to build a new feature…ask them the 5 Why’s first!
See my previous post to understand how I got here. The hypothesis is that product development is messy except for the most disciplined. After talking to a number of great product people, I have a theory for how great product can be developed while being customer centric (aka lean).
The Virtuous Cycle of Lean Product Development
The Product Management Funnel
I think of product management as a funnel. At the top are all of the ideas your team generates. If you’re a lean startup, that’s hopefully driven by customer interviews, website and landing page behaviors and support interactions and of course the occasional green space wild idea.
As product manager, this is the most dangerous step. Once you have more than a few employees, it’s easy to have these ideas overflowing and interfering with the whole product process. Multiple teams I spoke with have been using their project management tools to capture these ideas which leads to a huge mess (one such company had over 4,000 stories in their icebox!) and a major time suck (one vp of engineering is spending an hour + each day managing these ideas).
The problem is project management != product management. The only thing that should be in your project management tool are key bugs to fix and what you’re building now or in the very near future (ie next sprint). Everything should be clearly defined and in a language and structure preferred by your engineers. All the evolution of the product from idea to customer validation to final prioritization should be done outside the project management tool.
The Rest of the Funnel
The Full Product Funnel
Going back to the beginning, you need discipline at the top of the funnel; the best product people I spoke with are requiring a shred of data tied to an idea to make it into their coveted ideas list. They also often expect a disciplined approach to what goes in by having people state, “Feature X will move Metric Y by Amount Z” so it’s clear why the feature needs added. In earlier stages that may be in a “Hypothesis vs. Metric to Invalidate” format instead.
The key of this step is effectively managing the signal to noise ratio; for every 5-10 ideas that come in, you may only make 1 or 2. Even the less disciplined product managers I spoke with have some type of hot-lukewarm-cold system for trying to rank ideas. To avoid the 4,000 stories in your icebox (or anywhere else) you have to be disciplined on dropping stale ideas and focusing on what matters now. When you’re a growing startup, where you were 3 months ago is dramatically different from where you are now so why keep those stories cluttering your system now?
After wrangling the initial feeder of ideas under control, you need to effectively refine the ideas that make it into your system and allow the most important ones to rise to the top of your list. As planning for your next sprint begins, you need to prioritize these ideas and balance with other existing projects, bugs and other demands.
Once you’ve settled on what you’re going to have engineering build next, you need to engage your team on the ideas you want to implement; you may need copy from marketing, stories from support to describe customer complaints, links or screenshots from analytics to show present activity and relevant customer development notes. All of this feeds into the project management tool you have, but now it’s uncluttered and your engineers are much happier and efficient. Unless you’re github or heroku, chances are your engineers don’t understand the customer they’re building for perfectly so all this structure makes it easier for them to see what’s going on and then adapt it to fit the project management tool they’re using to track building.
As an added bonus, there’s transparency for your other employees as they engage in more than just the initial ideation process. It also means sprint planning no longer needs to have all hands at it as they’re already well aware of what’s going on and have had opportunities to contribute as needed to the stories now being generated in the project management tool.
Completing the Virtuous Cycle
We all know this image so well as the core of what lean startups is all about, but how often is this cycle cleanly implemented? The project management tools out today all do a great job on the build aspect, but what about measure and learn?
The funnel process I described above captures the learn aspect as you engage your team for ideas and validation. All that’s left now is to measure.
After you build something new in your project management tool, your engineers will submit it for some form of approval. Once approved, it universally ends up disappearing into the ether, because the project management tool is built to track what you are building or about to build. After building isn’t part of their process.
To close the lean loop, you need to look back and see if that feature actually moved the needle. This needs to happen within 2-4 weeks of building it; sooner wouldn’t be enough data and longer would be distorted due to other things you’ve likely built by then. This last step of learning should help you refine your instincts and feed back into what you build. This is one of the biggest challenges as Eric discusses his principle of Innovation Accounting in his book.
The amazing thing I discovered in so many of my interviews was how rare it was to do this measure step; how can you improve your accuracy without seeing if you hit the target?
The Product – Lean Opportunity
What started as an investigation of lean startup opportunities has broadened to helping teams close the loop in managing a product lifecycle. I believe there is tremendous opportunity to build a platform to aide on both sides of the project management tool and much wider than those adopting lean concepts officially (as we all know, being customer centric is not a new concept).
Earlier in November, I started out on a journey to see if there was an opportunity to build a product that would help companies in being a lean startup. The thought was that with Eric Ries’s book flying off the shelves and the lean startup community exploding, there would be new problems to be solved. Thanks to a nudge from Sim Simeonov and a few consulting opportunities brought my way, I felt like there was definitely something there. Like any startup, once I got outside the building, I learned some harsh realities:
1) Most people only pay lip service to lean.
Painful, but true. In both casual conversations in our community and full blown custdev interviews I found the full spectrum from strict implementers like John Prendergast and Matt Mamet (coincidentally co organizers of the local Lean Startup Circle Boston) to people who claim to be lean and think it has anything to do with how little money they spend (names withheld to protect the innocent).
2) Lean is a hands on activity.
The key to lean really is the human interaction; knowing when to ask an interviewee “tell me more” or deciding what analytics to deep dive to match up against your anecdotal discussions can’t be productized directly. It’s also risky to outsource since it’s so core to the future of your business; no amount of meetings, notes and summaries can compare to being there and doing it yourself. There’s huge opportunities to teach companies how to become lean, but I’m passionate about building a product, not a services business and I’m not sure most companies are ready to invest in lean (see 1).
3) Small startups are more likely to be lean and less likely to need process.
Part of the challenge of the adoption curve of lean is that it has most strongly permeated the zero stage entrepreneurs; they’re the ones with time and motivation to watch the videos, read the books and stay up on all the blogs (which has come a long way in the last year or two since all we had was the Four Steps to the Epiphany to go on).
Unfortunately, those people have little to no budget and because of only having a few people on their team, there isn’t much of a need for tools. Everything can be done ad hoc when you’re that small. The most common behavior when you have 5 or less people is to remove your headphones during the work day and share your findings immediately with everyone on your team. This is effective until you grow to the point that everyone doesn’t know everything that everyone is doing (usually around 8-15 people).
So all that meant to me wastime to pivot:
I’ve known all along that customer development feeds into product management. Fittingly, this is where I did find pain:
Managing product while being a growing, lean startup requires significant discipline. Not all companies have product leaders with this strength.
Many companies build up product management debt as they grow and fail to adapt to the demands of a team that passes the “take off your headphones and talk” phase.
Multiple challenges arise in engaging all members of a company at the right times in the right way.