Archive

Business model design

Favorite Lessons Learned from Lean at ITP Speakers

We just wrapped up our second Lean experiment at ITP last night with a Lessons Learned dinner party.

We had extraordinarily candid speakers this semester who humbly told us of their successes and failures, pivots and turnarounds, origin stories and the truth behind their funding and scale.

A few of my favorite wisdom pickings from the line up of guest speakers:

Britta Riley: Know the contours and flows of the dominant business model in your industry. Know the limits of direct e-commerce sales if you are selling hardware and how retail happens. Don’t deliberately limit your business by not understanding these parameters going in.

Albert Lee, All Tomorrows Lab who recently launched Emoji App:

Zero mental calories: users should have to learn nothing when they use your app. Nothing.

Toothbrush test: can you find a reason why they would use your app 2x a day, to create those reasons to engage.

Trojan Horse it: you can’t always give people what you think they need, especially if you are meeting a need they are uncomfortable talking about. So find out what their discrete top level painpoint is, and create the front door that meets that need. You can solve for deeper emotional needs not at the value proposition level, but in the product design. **** (This one gets extra stars)

Julie Berkun Fajgenbaum, Tweed Wolf. Come up with the 10 reasons why it won’t work and then develop tests to prove the contrary.

Chris Milne, IDEO: Design it so it looks unfinished – and people will give you more honest and useful feedback because they will not feel like they are hurting your feelings. They will truly co-create with you.

John Bachir, Medstro: Kill Features!

Christine Lemke, Evidation Health: Be comfortable with pivoting between consumer and B:B, and don’t get too attached to what the actual product is on either side – your strengths in one will benefit you for the other.

Angad Singh, Lolly Wolly Doodle: When you are in scale mode and hiring developers, learn to work together before hiring. Determine a project that you estimate to be about 20 hours over 2-3 weeks, and then assess not just coding skills but problem solving, decision making, and communication skills.

Scott Miller, Dragon Innovation and Bolt Ventures: Learn how to pick a factory, and validate that your project could succeed through crowdfunding or preording before you begin.