You can find Part 1 of my notes from Failcon 2012. Here’s part 2:

#5. Braden Kowitz, Google Ventures, Pianos, Battleships, and Sneakers: Stories about Design and Failure.

He gave an excellent talk, with many real examples of failures he’s had in design. Best talk I’ve seen so far today.

• He told a story from early at Google where he spent 3 months trying to make a perfect design, not showing his sketches to anyone. He finally showed it, and it was so overdesigned no one could figure it out. Waiting to unveil design is a mistake – it’s not art, it’s something that’s supposed to do something.
• Reading books has limited value at skills. He learned tech skills by reading books, and gaining confidence, but this doesn’t work for skill development. You have to practice piano, not read books about it.
• Design is learning through doing. Many young designers believe they are their work, and if their design fails, they fail.
• Best suggestion is to dive into project and find a ‘piano’ tutor. Someone who knows more about design than they do and show them the way.
• Google chat: they had a design for chat they’d developed, but in the first user test it completely failed. They tried again, failed again. The Designers often feel horrible at this point – in fact Braden is on a current project where this is happening.
• Design is subtle – no one could have predicted which final design would work.
• Why is there so much failure? He compares design to the game of Battleship. You are forced to continually guess at what a good design is, and people are moving targets. Example: the pull-down metaphor on iPhones. Apple didn’t invent it, but in just a few years people’s expectations have changed. People are a moving target.
• Design then is really about dealing with failure.
• One day sprint: Schedule user study for end of the day, forced to test something fast. Was working so fast he was afraid it would fail.
• “Even if you are good at design, even at something specific like button placement, you can be wrong many times.”
• When you run away from failure as a designer, you get less and less feedback. Instead you should lean in to failure, because it makes the intervals of ignorance smaller.
• Have a running buddy – someone who helps set you pace for feedback, and helps get you out there in the real world.

#6.  Mike Arsenault, Grasshopper, How Not to manage your product

Finally a solid case study structured talk about one specific startup, with specifics on key decisions, results and lessons. Bravo. Honest, smart and real. Well done. A model for future failcon talks.

• His slides can be found here – they’re very good
• Linear fallacy – most stories about sucess tell a linear story about how they became so successful. He showed a graph of his product trajectory, which was chaotic and far from a ‘hockey-stick’ [hockey sticks are incredibly abnormal and rare despite how much they are talked about]
• Service was to help entrepreneurs find  other entrepreneurs.  Referral rates – earned $100k of referral revenue based on a referral form.
• ‘How can we productized this?’ That was the goal for the spin off product: Spreadables.
• Explainer video explained the purpose and vision.
• Staffed team of 12 experienced people, 40k customers from original business, and $100k of income… which was all done smartly. WE STILL FAILED.
• They launched in summer 2010 and shut down in spring 2011.
• They benchmarked: customer lifeitme value, cost per acquisition, avg revenue per user, Churn. And more.
• Why did it fail?

• Churn was 3X (Not enough matching between customers they got, and the ones they wanted).
• CPA was 3x higher than Grasshopper.
• Organic search was very low (compared to Grasshopper). This meant customer acquisition
• Customers needed high touch

Lessons

• Wasted beta list. Let it sit dormant and cold. Should have kept it ‘warm’ so it was active and ready to be useful when launched.
• Team was too big (Mythical Man Month). Bigger team made more politics and lower velocity. Big team encouraged wrong behavior (build more!) instead of (build the right thing!). He would have kept team smaller.
• Didn’t charge for 6 months. This was a product for businesses, not consumers and who would pay would have been a useful forcing function, and better data on responses to change (If you do something dumb with a free service, they stay anyway).
• When people are paying you, their feedback is more pointed and engaged.
• Product > Marketing. We focused on marketing too much too early.
• “If you are doing more than writing code and talking to users, you are probably wasting your time”
• Sketchnotes of this talk

Sketchnotes from other talks I didn’t attend:

• Eric Reis interview
• Social Proof is not proof