Talking to strangers
Last weekend I attended Lean Startup Machine, a weekend workshop to test your startup idea through audience interviews, low-tech demos, and rapid iteration.
My main client does agile software development, and I’ve been trying to get my volunteer groups to move a little quicker, so I went to experience the official process.
On Friday night, about 40 people pitched ideas to a crowd of 100. We each got 3 votes to narrow things down, and then split into teams of no more than 5. I joined a team interested in crowdfunding neighborhood development projects in NYC, and we went through the LSM process.
Step 1. Identify your audience and their problem.
Our team thought that NYC co-op owners with children would care most about their neighborhoods. We would measure this by action taken (calling 311, attending town halls, etc). We thought they were dissatisfied with current channels of action. We would measure this by ratings.
To confirm a problem, the recommended tactic is exploration. Interviewing your audience. No leading them, no selling, no “yes/no” questions, no hypotheticals. Better to ask what? why? how? about actual past actions.
We headed down to Trader Joe’s, since we’d find the most residents (vs tourists) at a grocery store. We interviewed six people before we got kicked out, and then another ten outside. It turns out that home ownership and parenthood were NOT a strong indicator of action. Length of time in one neighborhood was. So we did a customer pivot, to say NYC residents for >5 years (in the same neighborhood) are dissatisfied with current channels of action.
At this point we should have done another exploration trip, to verify our users and problem, but the team wanted to move on to a possible solution: a crowdfunding platform for neighborhood development.
Step 2. List all your assumptions. Test the riskiest.
We were assuming that crowdfunding real estate was legal, that developers would be interested in the funds, that projects would actually come to light, and many other things. Some could be validated via research; we decided to test an assumption that our audience members want info on development in their neighborhood.
To test a solution, the recommended tactics are either pitch (acquire currency: attention, contact info, money) or concierge (deliver on your users’ expectations in the simplest, most lo-fi manner possible). Then follow up: are users ELATED by your solution? If not, rework.
We went out to pitch at Chelsea Market, which has a lot of conflict over rezoning at the moment. We asked if people were aware of the plans for the market, and if they would be interested in that type of info about their own neighborhood. We said 50% interest was our definition of success. 7 of 11 said yes, and gave us their email address, which validated our assumption.
Ideally, you’d have continued metrics on these kind of stats, so the definition of “validated” would have a reference point.
3. Keep validating your assumptions, one by one.
There were quite a few hidden assumptions that came up when we really made a list. This was one of the most helpful exercises, both at the workshop and when I later went through the process with a client. It was illuminating to outline our risks, and realize we could test each one, instead of just bundling them all into a product ;)
For the workshop, we could have developed a low-tech newsletter, and sent it out to the email addresses we’d collected, but our team didn’t all agree on the solution we’d pitched. So, we did another round of pitching, testing the assumption that our audience prefers local developers to chains. We were getting ready for the presentation, and needed some good photos, so we did a gimmick with coffee cups and signs. I don’t think our data was valid, but we had fun waving a sign and asking for dollars. And we learned (of course) you get very different answers at Penn Station and Whole Foods.
The hardest thing was remembering to make sure people were part of our audience before interviewing them. You’re never going to make everyone happy, you have to find your people and design for them.
Top takeaways
Risks can be tested. The sooner, the better. Fail faster.
One thing at a time. Then, when you connect the dots, you have an actual path instead of a fog.
Ask the right people. Data’s only valid if you’ve qualified your subjects.
Keep the team together. We split up when the mentors were rushing us, and ended up w/useless data b/c we’d diverged on the idea. Clarity is key.
Just launch already. You’ve got at least one clear idea (I hope). Get the very first test up, and go from there.
I would never have attempted anything like this in normal life, so the process was really valuable. And eventually fun.
Over the course of the workshop, we saw some great ideas get polished into legit startup work within 48 hours.
Get their Validation Board if you want to try it yourself.
