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!

For the past month, during my nights and weekends, I’ve been working on a new fitness web application.  In an experiment on transparency, I’m going to completely over-share on the business plan, design, process, stats and feedback.  Expect to see some code snippits, anguished tirades on money woes, and maybe even a glimmer of hope here and there.

So where to begin?  How about what, and why? As will come as no surprise to any who know me, I’m addicted to gadgets.  Combine that with enjoying biking, running and working out, and I now have at least 3 different “human telemetry” (a term I love, and picked up from a collegue at Sun Microsystems, Tony Kay) devices.  A Garmin Forerunner 405, a Polar RS400, and a Nike+.  I use the Garmin when outdoors, the Polar when inside, and the Nike+ not so much anymore.  The Nike+ was the first device I picked up however, and opened my eyes to what combining human telemetry with a great social experience can do.  

For those who haven’t played with the Nike+ site, it’s quite frankly one of the best uses of social networking I’ve seen.  After each run, you upload your data to the Nike+ site, where you can see how you performed.  More importantly, you can enter into competitions with friends, no matter where they are.  Even strangers.  For example, my sister and I competed to see who could be the first person to run a total of 30 miles.  She could run on one day, me the next, and Nike+ would let us see how it’s going.  It’s motivating, fun, and interesting.

Eventually, my toy addiction meant I outgrew the Nike+.  It’s notorious inaccurate, there’s no HR or other real-time data, and it requires that you have an iPod Mini with you.  As I moved on to my other devices, I missed having the social aspects. There are vendor specific sites, like Garmin Connect, but if you have a Polar, I have a Garmin, and Tara has a Nike+, there’s no way for us to get the competitive juices flowing.  From that simple disconnect, Zed9 was born.

Zed9 is like mint.com for fitness.  The idea is to aggregate data from as many sources as possible, provide you with meaningful analytics, and compare and contrast your performance with others in your network, demographics, and interest groups.  I’m planning on launching a private alpha this week to start getting feedback.  

As I develop and launch this, I’m planning on blogging about the experiences, technical hurdles, marketing and product management challenges.  Next topics specifically will be around balancing hobby vs. job, moving forward (or not?) in the face of overwhelming competition, setting milestones for determining just how much of my damn time I should put into this, and what does success even look like.  If there’s anything you want to know, from trivial to intimate, let me know!  And if you’ve got a Garmin of Polar device, go sign up for Zed9!

You’ve got an application.  Maybe a bunch of applications.  You’ve heard that the “cloud” is the place for these things today, so hooray, that’s done.  Then you read discussions on corporate cost efficacy, or untold other random things, and the buzz is so loud you can’t hear yourself think loud enough to figure out anything.

Step back, just for a second.  At the most basic level, that collection of apps is gonna run on some hardware.  Somewhere.  No matter how fancy, when pushes comes to shove, it’s got some physical folded sheet-metal somewhere.  Basic part II: Folded sheet-metal is all the same.  WHAT! I know, I know.  HP, IBM, Dell, Sun (er, Oracle), are dying to not make this true, but it is.  It’s all the same.  Yes, there are differences, and they are important to the technicians running this stuff, it won’t make a damn bit of difference to your application.  You spend $3K, you get $3K worth of performance.  Spent $30k, you’ll get something better/faster/more reliable.  For the same price backet, all the vendor’s differences are 95% the same.  Some people care about the 5%, some don’t.  Most don’t.  

So it’s all the same, and you only care about your app.  Sadly, between caring about your app and getting it to run, there are some other concerns.  You care about nice things like reliability.  Or response times.  Or # of credit card transactions.  And getting those things requires some complexity.  Maybe more hardware.  Or some fancy programs.  Maybe some additional people time.  None of it’s rocket science, and frankly, it’s all been done a million times before.  Specify what % uptime you want, how many customers you really want, and there’s a solution for that.  Let’s say you decide you want decent uptime, protection from SPOF (single point of failure), and have a small-ish app that has only 5,000 light users.  Easy peasy, let’s get you two servers, setup some kind of failover arrangement, and you’ll probably be fine.  Yeah, it’s a bit tricky to get this setup, but it’s just tricky, not actually hard. 

Now you want to do this in the cloud.  You look at moving it to Amazon EC2.  You’re team runs the numbers, and SHOCK and HORROR, it’s MORE EXPENSIVE than your in-house team.  OF COURSE IT IS.  They’ve got the same computers.  They’ve got the some damn fancy software, but if you’re doing the same thing on someone else’s equipment, it’s going to cost more.  This shouldn’t surprise anyone.  And if that’s what you’re looking at, you’re an idiot.

The point of the “cloud” (and for this example, while I’m using EC2, please don’t limit your thoughts to them.  This could be any provider, in-house or outside.  It could be higher level like Google App, plain old IaaS, or something new we haven’t thought of) isn’t doing the same thing the same way.  It’s about the flexibility it offers.  The new way you can do things.

So first thing first.  Were those two servers 100% loaded the whole time before?  No?  Great, so why not go with a smaller resource pool.  Either in house with Virtualization, or just use some smaller instance in the cloud.  What’s that, you don’t like “sharing” your resources with others?  Get over it.  Whatever excuse you have, you’re wrong, you just don’t realize it yet.  I’ve spoken with companies who don’t trust VLANs (a way of putting two networks onto a single cable, VERY useful in any real datacenter) for no good reason.  They’re doomed.  The technical constraints are getting taken down daily.

Great, so now we’ve got better utilization.  That’s step #1.  Now my app is doing well.  Really well.  The latest stupid congressional bill is requiring everyone in the company to use this thing 10x as much, and I can’t handle the load!  Oh, you’re in the cloud?  You can provision new resources in 2 seconds instead of 2 weeks or months?  Hey, that’s worth something!  Even if I was on my old dedicated machines (so much cheaper, remember!) they couldn’t handle this load.  I’d be dead if I had to wait for new HW to show up and get provisioned and…

Wait, the app is getting so much attention, my trivial failover mechanism isn’t sufficient.  I need a real disaster recovery plan.  Maybe something in two datacenters, in case California really does fall off into the ocean.  How much would it cost you to spin up a new datacenter again?  Why not let someone else do it for you, and pay a bit more per CPU hour?  

And this is all just in an IaaS world.  Why are you even bothering with virtual computers.  Chances are all you really care about is the application.  Why not just use some PaaS provider, who can do all the sysadmin work for you.  Rails has a great ecosystem here already, with some truly amazing companies like Heroku out there.  Google has python covered.  Even java now.  Now you’ve just cut out a whole huge chunk of management cost in house.  And it turns out it’s even cheaper per app since you’re sharing even more now.

This isn’t rocket science.  Hardware costs are fixed.  Everyone is adding their own technology costs on top.  The more fancy goo, the more it costs on a per CPU cycle basis.  You save money through efficiency, be it using less resources or getting quicker agility.  That’s it.  There is no magic in the cloud.  It’s just another way of making your life easier.  If you actually try and use it as it’s intended, and not just shove your existing inefficient ways of doing things up into someone else’s outsourced HW farm.

A topic very near and dear to my heart has picked up some steam recently: Enterprise software pricing. Kicked off by ReadWriteWeb, and picked up elsewhere, the basic point is that value is not correlated strongly with per-user pricing.  All these “Enterprise 2.0″ companies are out charging on a per-user model, but that’s at odds with the value derived by the customer.

Let’s first take a step back and look at the big picture.  Business model and pricing is a means to an end.  Ultimately, as software producers, we are in a VERY strange world in which our incremental cost is $0.  As with any intellectual property sale, since their is no intrinsic cost to our product, all pricing is simply a matter of playing with funny models to make the customer feel like they’re not getting ripped off, and the vendor able to generate enough revenue to survive, and in rare cases maybe even thrive (rarer every day it seems).  As a previous boss of mine used to say – software pricing is all insane, it’s just a matter of agreeing on the insanity.

At the end of the day, all that really matters is what $ amount changes hands.  A total $ vs. value graph for these Enterprise 2.0 companies looks very different:

In this graph, value still goes up quasi-exponentially with the users.  Total cost also scales, but it’s quasi-logarithmic. Instead of being inversely proportional, we’re now just looking at a gap in the middle. Further, it’s a gap that companies are used to paying.  Yes, I’m ignoring all the capped deployments and models that are “packaged” vs. per user, but in general the vast majority of scaling 2.0 business models net out to the above graph. 

Our entire life experience, plus all previous experience, tells us that the more you buy, the less you pay per item, but the more overall it costs.  Trying to go against this is probably impossible.  Software pricing is about putting a framework in place that makes your customer feel like they’re not getting ripped off, and enabling you to run your business.  Everything else is just hand waving.  Make sure the general curve of your overall monetary exchanges is correct, and focus on the value in the product.  Pricing is necessary, but not sufficient.  It’s easily possible to setup a pricing model that’s so broken it kills your business, or doesn’t scale to support where you need to go.  On the other hand, you’re not going to make your business through a pricing model (as proven through Sun’s numerous attempts with Project Orion, network.com, etc…).

Come up with a model that scales.  Something that if your assumptions work out, enables you as a business to succeed.  Then focus on the business and value to the customers.

Rich Miller (CEO of Replicate) posted about our search for some larger ESX shops.  If you’ve got >40 ESX servers in one virtual center instance, and are interested in a 1 year free subscription to RDA, please get in touch!

We’ve been encouraged by the response to the announcement of RDA 1.0.  The number of visits, registrations and people downloading the free evaluation version of the product has been terrific.  

But we’re not yet satisfied: We are particularly interested in finding organizations with sizable VI3 virtualized datacenters who would like to evaluate the datacenter analyzer.  The majority of our users have indicated that the number of ESX hosts under management by Virtual Center (or should I say vCenter ?) is 20 or less.  We’d like to find the installations with 40 or more ESX hosts under management.  

To that end, we’re extending to three organizations with more than 40 ESX hosts in their datacenter, the opportunity to become a Replicate Technologies design partner.  In exchange for providing us with modest amount of feedback on your experience, design partners will receive one year’s free subscription for the full compliment of servers in the datacenter.  If you’re interested, give us a call or use the sales inquiry submission form here.

New research report out from EMA today that’s well worth looking into.  SearchCIO-Midmarket.com has a great article on it.

Behind these figures are management challenges that companies are only starting to recognize, let alone address, the surveys found. Only 24% of respondents to an Enterprise Management Associates Inc. survey of 627 corporate IT decision makers published last April said they thought virtualization makes security administration easier — as compared with 42% in 2006. Just 32% said software control and distribution is easier in a virtualized environment, down from 58% two years ago. And configuration management numbers plummeted from 58% to 32%.

That’s exactly one of the problems we set out to solve with RDA.  We recognize that administrators are being thrust into administrative positions that challenge them to broaden their expertise dramatically.  Managing a virtualized datacenter requires deep network, storage, server, and virtualization skills, often in very short supply.  RDA helps, by providing clear guidance and prescriptive remediation to help administrators find and fix problems in their datacenter quickly and easily.

Another favorite quote:

ndeed, everything from performance and capacity management to troubleshooting and security administration becomes more difficult in a volatile, multilayered and often heterogeneous virtualized environment, Mann said. 

And finally:

Unfortunately, there aren’t a lot of software tools that manage virtual and physical environments or multi-platform virtualized installations in an integrated fashion, the EMA report stated. Only 21% of management tools in use can integrate effectively with other enterprise system management tools, according to EMA’s Mann.

If this sounds like you, go check out RDA!

It’s a sign of just how great and busy we’ve been that it took me 4 days to post this!

As of Monday, November 11th, Replicate’s first product – Replicate Datacenter Analyzer – is officially launched.  

What is RDA? From our website:

Over 60% of downtime, security, and performance issues are due to configuration errors, and virtualization is only going to drive that percentage up. To ensure proper virtual datacenter operation, it is critical to have a holistically configured datacenter based on industry best practices.

Combining empirical data from our IP network probes with configuration information obtained from other individual datacenter elements, RDA constructs a unified view of how the entire datacenter works across different administrative domains. Ensuring that administrators can quickly see the relevant information, RDA “knowledge packs” apply industry defined best-practices to highlight latent problems and overt mis-configuration in a virtualized datacenter that can impact security, reliability, or even downtime.

Go check it out!  We’ve got a free trial, screencasts, and all sorts of other goodies on our website.