The Case for Being Pig Headed

One of my dad's favorite analogies comes from breakfast.  In the classic plate of bacon and eggs the chicken is involved, but the pig is committed.

When applied to entrepreneurship I think about the interplay between investors and entrepreneurs.  Investors have money at stake - usually in the single digit percentages of their net equity.  Entrepreneurs on the other hand are betting it all - all of their time, all of their energy, and often all of their money.

So, I've always been surprised that entrepreneurs evaluate the viability of their company by the input they receive from investors.  The chickens, often with comparatively little at stake, evaluate opportunities and give advice from the perspective of the involved...not the committed.

Entrepreneurs should instead focus on themselves - the committed. Are you all in?  Does every piece of evidence point to this venture being worth the next 1-2 years of your life?  Are customers willing to bet the farm on you?

Be brave.  Be pig-headed.  And stop listening to those chickens.

Rethinking Customer Development

I'm a huge fan of Steve Blank his theory of Customer Development.  I've found his writing always inspirational and insightful.  However, has been a little to dense for me to use as a clear roadmap.  Many in the Lean Startup movement point to the Business Model Canvas as a cure - which, try as I might, I've never been able to actually follow in a real live business.

The issue was that each of these pieces is part of a flow - not a discrete map.  So, here at Contastic we started using a variant that models the business as a process rather than as a map:

This covers same essential areas as the Business Model, but slightly re-arranged to fit the process of validating a startup.  Generally, each stage from left-to-right is dependent on the next and should be evaluated in that order.  At each milestone the company should seek to find a path through.  I like to have at least two stages written out to look at: general themes, and then specific actions/sources to test:

While by no means complete, this model serves as a basic roadmap of our plan.  We also often use  third level for tactical tests to confirm items in level 2 (ie acquire 20 customer per day at Dreamforce).  As they are confirmed the fact bubbles up to the next level.  As we develop the company we continually edit this knowing that the dependencies flow from left to right and then top to bottom.  

Hope this helps you all bring a strong evidence-based approach to your ventures.  We're continually evolving this model, so if you have any ideas for improvements or cases where it fails let me know in the comments below!

Seven Deadly Startup Sins

I've been working full time on Contastic (getcontastic.com) for about three months now fully immersed in the valley culture.  It's amazing to be in a place with so many resources, but each opportunity is also a distraction.  Time is your most precious commodity - if it's not invested wisely, your company will die.  In the spirit of helping founders make better choices here are the seven deadly startup sins to avoid:

1 - Building too many things

It's hard enough to build one feature well.  If you attempt anything more than that you will dilute your resources and will end up with a basket of mediocre features that nobody cares about.  Approach scoping from the prospective of a 10 second demo - only build what can be demoed in 10 seconds or less.  This is all the time you'll get from a customer or investor.  Spend your time making one amazing magical feature that can wow anyone in 10 seconds.

2 - Getting feedback from non-customers

The first thing people do when building a company is to ask the people around them.  This is lazy and leads to bad information that will lead you down the wrong path.  Focus on customers - people willing to pay for your product at some point.  Ignore all other input.

3 - Building features customers won't pay for

When I started using lean methodologies I quickly found myself drowning in divergent customer feedback.  When asked 'what would you use?', customers will ask for everything under the sun.   The real question is 'what would make you pay (more) for this product'?  If adding a feature doesn't change their willingness to pay drop it.   Only build what changes willingness to pay for a large segment of your customers.

4 - Following advice

Almost all advice is well intentioned, but bad.  Nobody knows your business like you do.  Ask people for their stories, their experience, and their opinion within their scope of expertise.  Do not ask for or listen to anything else.  The worst advice comes from experts outside their field of expertise.  It sounds deceptively credible, but will lead you down the wrong path.

5 - Telling customers what they need

Coming from a sales background I'm naturally inclined to get to 'yes'.  While good sales, this drive is a terrible way to gather data.  When interviewing customers adopt the socratic method - ask questions and avoid making any declarative statements all together.

6 - Not asking for the introduction

Every good conversation you have should send with an ask for introductions to others.  At any stage if you have one person that likes you, your idea, or your product, use them to find similarly minded people.  Birds of a feather flock together, so one fan can usually lead you to more.

7 - Not having a plan

Engineers are often guilty of the 'build first ask questions later' mentality.  Building is the most expensive way to validate an idea.  Create a step-by-step plan which ends with coding - require a high barrier of proof before building anything other than mockups.  We use the rule of 10 - 10 customers must say yes before we move on.  In this model we'll talk to at least 30 customers before coding.  Here's what we follow:

Customer Development Pipeline

Note: after the first couple interviews we lump the first three steps together.  Just be careful to ask them in order so you don't influence the user's perception of the problem with your solution.  Also, drop customers from your funnel if their needs start to diverge from the pack.  You don't need to make everyone happy - just 10.

F-ing up Feedback

Through some really challenging conversations with advisors I’ve gotten the kick in the pants to re-evaluate my management style. The conclusion I came to was the biggest area for growth was in feedback (irony knows no bounds!).  Giving feedback is hard and temporarily uncomfortable, so it’s something I often postponed to big mile stones.

However, through much reading, adjustment, trial and error I’ve settled on three Fs for feedback:

Fast – Give the feedback in the moment.  Immediately after the action everything is fresh in the recipient’s mind.  This is the best time to trigger reflection and growth.

Frank – Be brutally honest.  Any beating around the bush or ‘cushioning’ to save someone’s feelings only obfuscates your messages and robs the recipient of a valuable learning opportunity.  That is not to say you need to humiliate the person with mean or public feedback.  Just deliver an objective statement in private, answer clarifying questions, and leave to let the recipient reflect.

Frequent – Do this often.  My biggest failing was to wait for big milestones. It’s important the feedback is separated from performance/compensation review.  Frequent feedback builds the trust that the information is simply there to help – nothing else.  This will take the pressure off and enable the person to respond positively.  Also frequent feedback cuts up changes into small chunks – making it easier for the recipient to internalize and adopt.

If you’d like to read some more on this topic from a truly great mind – one of the most pithy descriptions of good feedback comes from Ben Horowitz: http://bhorowitz.com/2012/10/17/making-yourself-a-ceo/

So go forth and F up your feedback so you don’t f**k up your team.