Ontic Oren

A nasty bug on ZED9 I’ve been avoiding the past few days was solved with a stupid single line.

In Rails, when you have a has_many relationship, it’s great and easy to be able to iterate through all the items. Assume you have models as such

class Foo < ActiveRecord::Base
    has_many :bars
end

class Bar < ActiveRecord::Base
    belongs_to :foo
end

So you go ahead and iterate through them:

@foo = Foo.find(:last)
@foo.bars.each {|f| f.your.logic.here}

If for anyreason, you’re counting on the ordering of those items, watch out! I was iterating through GPS coordinates, comparing them with the first one. SQL databases make no promise on ordering if you don’t ask for it, and every now and then I was getting totally insane results. Turns out the DB was feeding me the GPS coordinates in reverse order sometimes.

Luckily, rails makes this very easy. Just specify your ordering in the model:

class Foo < ActiveRecord::Base
    has_many :bars, :order => 'time ASC'
end

With that one line, I fixed half a dozen outstanding bugs. Mostly posting so I’m not stupid in the future.

Last night’s VC Taskforce Elevator Pitch Roundtable was quite the eye opener.  

10 CEOs each get up and present their elevator pitch in 90 seconds.  A panel of 5 VCs then spent 5 min in Q&A, followed by a 2 min critique and scoring from 1-5.  The rest of us – around 50 people total – are just fly’s on the wall.  

Two clear groups emerged: the obscure but competent idea, and the arrogant bastards.  In this group, we had  3 to 6.  Twice as many arrogant bastards.  Both the decent and the TERRIBLE pitches were really useful for me, and I pulled out a few points for any elevator pitch.  They may seem obvious, but apparently 66% of people don’t grok em, so here they are:

1. Start off with what you do.  Hi, my company is X, and we do Y.  Right up front.  Don’t set things up.  Don’t make excuses.  Don’t joke.  Don’t try and ask questions to “connect” with your audience.  Just say what you do.  NO ONE did this. Not one. At least 50% of the pitches the VC’s needed to ask during the Q&A, “Just what is it exactly?”. The rest it emerged, but it was like pulling teeth!  
2. Explain what job people hire you to solve.  Put another way, why should we care, and why does the user care?  You probably think this is obvious, and maybe 5% of the time it is, but you’re the expert, no one else is, so dumb it down.  
3. Make no assumptions.  OK, this should possibly be #1.  One guy spent the entire 90 seconds talking about “this”.  He even pointed to a physical device.  I thought it was a cell phone when he flashed it.  So 90 seconds he’s talking about bringing wireless to cell phones, and I’m thinking he’s a complete idiot.  Turns out “this” is actually a video camera.  And no one today has a wifi enabled video camera.  Ohhh….!  A bad idea still, but at least I know what he’s talking about now.  Don’t assume anyone understands the opportunity.  Don’t assume the market is clear.  It’s a hard line to balance, you don’t want to explain the basics that they get.  Understand the audience.
4. Never get defensive.  Ever.  Ever.  Ever.  If you’re getting questions, it’s a good thing!  Answer them.  SOB #1 last night immediatly assumed that the VCs were idiots, didn’t get what he was pitching, and responded to one very valid question about the company name by proudly stating that his previous company sold for $XXX million dollars.  Followed by explaining why he knew things the VCs didn’t, but couldn’t explain them.  He got all 1s. 
5. An elevator pitch doesn’t include financials, sales plan, etc.  The point is get em hooked so they can ask for more info.  What is the idea/product, the opportunity, and the problem you’re solving.  That’s it.  5 of the presenters wasted 30+ seconds talking about various internal details.

Some other random notes of interest:

• One of the VCs was concerned about a 3 year break-even.  Thought it was too long by far.  Someone, please show me what % of VC funded companies break even in 3 years, let alone 2 or less.  I’d guess it’s vanishingly small.
• One presenter dressed in jeans a t-shirt and sneakers.  Turns out, he had one of the best pitches, if not the best.  But in my mind, that initial disconnect on clothing mattered.  He overcame it admirably, but why start at a disadvantage?
• If I were a VC, there wasn’t one single idea that was interesting to invest in.    

As I’ve been developing Zed9, and reflecting on what we’re doing at Replicate, I’ve spent a lot of time trying to make sure I’m building the “right” thing.  So what’s right?  One theory is “Build it for yourself”.  As recently discussed by Tim Bray, John Gruber, and 37 Signals, the basic idea is: unless you’re a very strange individual, make a product you use all the time and chances are others will too.  You can focus on what you know, and make something great.  Build for yourself suffers from survivorship bias - it’s a necessary and helpful precondition, but far from sufficient.  There are countless products built for their creator that never made it anywhere.  The very fact that you have the skill set to create a product to solve your needs means that you ARE NOT LIKE the vast majority of your potential user base.  Using yourself as the prototypical customer can lead to dangerous assumptions.  What’s easy for you isn’t for others.  What’s obvious to your user could be totally obscure for you.

In creating any product, there’s always a disconnect.  You, as the product manager, startup founder or whatever, are either trying to solve a product you’ve personally experienced, or one you’ve seen.  Either way, it’s based on your experience.  And as much as we all like to scratch our own itches, selling to yourself is a hard way to make a living.  Many times you’re not creating this product to make a living, it’s an artifact of some other focus.  That’s certainly what happened with Rails, and I believe for Gruber with Markdown as well.  And when that happens, GREAT!  We all love the serendipitous success.  But what happens when you’re setting out from the start to actually make money on your product?  

That’s where the MVP comes in.  MVP stands for “Minimum Viable Product“.  Closely related to agile practices, the idea is put together the real minimum product to get customer feedback, and use that to validate and move forward.  Sometimes, your MVP can be as simple as a slide deck or even just an adword.  If people click and sign up for a waiting list, it’s probably a good sign that they’re interested, and it’s worth pursuing.  Don’t build a 2 month alpha if a prototype will suffice.  Don’t build a prototype if a marketing landing page will suffice.  The key here, of course, is the word “suffice”.  The MVP is all about getting customer feedback.  And apathy is the death of any feedback process.  We know what to do with negative results (try something new!), with positive (do more!), but what about no results?  

Apathy is really the scariest thing that a product owner can experience.  The lack of feedback gives us nothing to hold on to.  We start to breath our own fumes, going in circles.  What are the main causes for apathy? Three stand out: 

• Not a large enough sample size. We’re aiming for early adopters with any MVP based feedback.  If we’re lucky, they make up 5% of our target population.  Depending on your marketing and engagement practices, this means you might need to kiss 1000 frogs just to get 10 qualified responses.  Let’s take the ad-words example.  Your ads have a 2% CTR, and you expect 10% of the visits (a high number) to translate into actual feedback.  To get 10 actions, that’s 100 CTR, and 5000 impressions. Want 100 user feedback base?  Now you’re talking 50,000 impressions!  Dealing with contacts?  Assume you can get a 15% conversion rate and you’ll still need to talk to 66 people just to get 10.  This is probably one of the biggest issues many startups face.  From day 1, you need to be VERY aggressive about talking to as many people as you can to increase the population base.
• Didn’t actually make a minimum product. This is probably the first place any engineer will go.  ”Clearly, if we just add feature X and Y, THEN they’ll understand what we’re doing, and give us feedback”.  This is the most dangerous path to go down.  It’s the one where you eventually throw away the MVP, because you’ve never satisfied with the minimum.  It’s one I’m personally struggling with on Zed9 right now in fact.  We’ve launched a minimal product, that at the least gives the user some interesting rudimentary comparative analytics.  It’s different from other offerings, but not earth shatteringly so.  It hints at where I’m taking it.  I’ve had some interest, but not droves beating down my doors.  I keep thinking “if I just add this feature, then I’ll get 100x more people interested”.  This way madness lies.  You need to set clear metrics, and hear from prospects.  Go back to step 1 – not a large enough sample size.
• Not solving a broad/interesting problem. At some point, you need to call it.  Remember, the point of an MVP is specifically to find out IF IT’S GOING TO WORK.  It MAY NOT.  Hell, it probably won’t.  If you’ve talked to enough people, and still not getting a decent response, it just might be time to move on to the next idea.  If you keep going, you’re not building a product, you’re satisfying a hobby.  A hobby that may well turn into something interesting, but for now a hobby.

For me, I’m redoubling my efforts on increasing the sample size.  Before I spend a few more long nights and weekends adding all these cool features, I’m going to go out into the field, and talk to people.  I’m heading out to some bike and running stores during the weekday, to talk to the sales guys and see what HW is moving, what tools they recommend, and their thoughts on the viability of the product.  I’ll be joining some group rides, checking out the local meetup groups, and just talking to people about their problems today.  I’ll let you know how the next few weeks go!