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!

After all these posts on agile process and tools, if you’re interested in hearing live how I’m using Jira and Greenhopper, then sign up for this webinar Wednesday.

After introductions from Atlassian and Pyxis, I’ll be talking for 15 min on how we’re using them here, on our live dataset.  I’m talking about why we choose Jira/Greenhopper, how the entire team uses it, and what some of my favorite features are.

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.