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!

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.

We’re at that stage right now where the whole team is clicking.  Every 24 hours I’m seeing improvements that blow my mind away.  The more we get done, the fewer items left for us to do, the more I’m looking back and realize how TOTALLY INSANE my expectations were when we started.

When I first joined Replicate, our founders had already spent a bunch of time on the core databae and inference engine that drives everything we do.  Their up-front investment is what has enabled us to get to where we are today.  The rest beyond the core engine was good, but not what I was hoping for.  After a month of getting to know what’s going on, we emabarked on a massive push to completly overhaul our UI, the workflows, and everything about the product experience.

User experience is incredibly important to me, and I wasn’t happy with our state.  I confidently laid a plan for ripping the entire thing up, changing everything to the very core.  I committed to my boss that we could get this, “no problem”.  I signed up for all sorts of improvements, from new visualizations, new interface paradigms, new toolkits, and more.   Now, as we’re just two weeks away from release, I know I was totally nuts.  Not because we didn’t deliver everything I hoped we would – we did/have/are!  No, I was nuts because looking back, if each and every little thing hadn’t gone just right, we would never have made it here.  If we hadn’t hired an AWESOME UI engineer.  If our lead engineer wasn’t a rock star.  If we hadn’t managed to get an automation engineer and harness to remove the friction.  If the entire team wasn’t flexible enough to deal with massive change daily.  But we did, he is, we did and they are.  And so now, on time and on schedule,  we’re two weeks away from launching a product that I’m really excited about.

We’re a startup.  Odds say, we’re going to fail.  It’s only by having unrealistic expectations in the first place that any of us even can get into this job.  If we don’t keep having unrealistic expectations every day, we’ll get trapped by what we can’t do, and deliver just another piece of software.  IF we can keep being unrealistic, signing up for insane deliveribles every day, then I think we just might make it.

Over at my job, we’re just two weeks away from our first release!  I thought this would be a great time to look back a little at our tools and process.

Process

From the day I joined, we’ve been developing via a scrum process.  For those not familiar, the highlights are:

• Everything you want to do goes onto a prioritized list called the backlog.
• Write requirements in the form of user stories.  (As a <USER> I can <FUNCTION> so that <REASON>)
• Anyone can add, only product owner can prioritize.
• Team agrees on what backlog items they are going to work on during a planning meeting.
• Create todo list from user stories.
• Track progress through iteration.
• Repeat!

Tools

Say what you want about pen and paper, but I’m a geek, and love the toys. We use a bunch of tools here:

• Jira as the single source of truth
• Greenhopper as the plugin that makes Jira usable in an agile enviornment
• Confluence for all our wiki needs
• Bamboo as our build server
• Subversion for version control
• Balsamiq to mock up our front end.

Overall, this set of tools has been fantastic.  We’ve spent right around $5,000 for all the software.  That’s a significant chunk for a small company like us, especially when there are such great free tools all around, and I’d spend it again in a heartbeat.  The quality of these products is just outstanding.  The support is great from everyone, and Atlassian in particular needs to called out.  I’ve had 4 issues worth submitting as tickets, 3 of which they handled in < 2 hours, and 1 was my fault.

Over at my day job, we’re conducting a quick little survey to help us get a better handle on the configuration problems that people are running into setting up and managing a virtualized datacenter.  We are looking for feedback on the challenges that frustrate administrators in a virtualized world, and then some specifics on areas that may be of particular pain such as IP management, network configuration, etc.

The survey should take < 5 minutes, so if you’re reasonably technical, have played with or administered virtualization (citrix, vmware, microsoft, KVM, whatever), please help us out and take the survey.  Feel free to pass the link to anyone else. 

I’ll be posting the full results of the survey (barring personal information) next month, no filtering or editing.  If I get more than 50 useful results, I promise to even post the raw XLS for anyone else (competition or otherwise) to use as well.

Survey: http://bit.ly/4vhktO

Although it took some time, I’ve decided on the tools.  As the title says, I’m going with Atlassian’s suite, plus a really nifty plugin I’ve come across called Greenhopper.  Here’s the overview:

• Create user stories in Jira.
• Create wiki page for each release (not iteration, but release).  Link up to Jira dashboard.  Provide details, necessary information, any supporting stuff available.
• Planning poker to estimate user story size.
• Prioritize user stories with drag and drop via Greenhopper.
• Drag user stories into iteration releases via Greenhopper.
• Create sub-tasks for each user story to track hours.
• Drag tasks on planning board for open, in progress and done via Greenhopper.
• Use Greenhopper to generate burn down, velocity, and other fun graphs.

Now, all that said, there are times when paper is just the way to go.  We currently have ~85 user stories, and trying to figure out the ranking really is easier when you can have paper in front of you.  Luckily, it’s easy to do both!  By exporting the issues into excel, and then using mail merge from word, finally printing to Avery postcards, I’ve got a great way to create cards.  You can use my attached user-story-cards word file if you want to create your own.

Ah, the corporate overview.  The staple of every web site, and the key piece of many presentations.

We’re in the proess of putting such collateral together here at Replicate.  Not wanting to reinvent the wheel, I consulted the oracle for any keen insight or best practices.  After 45 minutes of searching, I’m surprised to find nothing on what makes a good/bad overview, or thoughts in general.  I did find some amazingly, painfully, searingly bad examples (I’ll be kind, and not link, but a quick google search for “corporate overview” will send you crying for some good clean smut).

Obviously, the goal is to convey answers to the standard 6 questions as applicable – Who, what, when, where, how, why.  I think we’ve all been trained a bit too well on these in that order.  Is who really the most important part of any pitch?  Unless it’s to your mom, I don’t think so.  Keeping in mind who we’re trying to convey this information too, most people who haven’t heard of us don’t want to know about the company, the want to know why they should even care in the first place.  To steal from Jerry Weissman, WIIFY (what’s in it for you)?  The WIIFY will vary depending on your target audience.  In our case, we have a few, all rather obvious:

• The customer: “If you buy our product, you’ll solve a ton of problems and get to go home and spend time with your family”.
• The partner: “If you work with us, you will keep and gain many happy customers”
• The investor: “If you invest in our company, you’ll get a great return on your money”

In all these cases, talking about our company seems like the last step, not the first.  Identify their problem, talk about solution, then explain why you’re the one to solve it.  I’d take those favorite six questions and reorder them:

• Why: What’s the market problem
• When: I’m gonna care about this when?
• What: What is the solution?
• How: How will you help solve it?
• Where: where can I find the solution?
• Who: And who are you to actually do it?

Any other thoughts on outlines or best practices?  What’s key in a good corporate overview doc or presentation?