Rocketr Log: Day 37 - Rocketr's Minimum Viable Product is now 20% of it's original spec. How the hell did we end up here?

Everyone’s talking about Minimum Viable Products these days… including me. At least I thought I was, until the Rocketr team ran it’s first group of usability tests at the end of November. Suffice it to say that my perspective has changed.

To date, we have called out every assumption we’ve made with each feature choice and product decision. Now we’re witnessing an entirely new level of assumptions emerging from the foundations of the application – decisions we had not expected would require questioning.

Building On the Web

It’s amazing what we take for granted when building anything on the web. Take sign-up forms for example. How much have the expectations around these forms changed in just a few years? How much more will they change with the adoption of OpenID, or the next social service to make itself portable?

You just don’t see this problem in other professions. An architect can assume that if they construct a door, people will walk through it. A bank doesn’t care about what user type you are. They have a teller who can determine your level of access when you walk in. Even though Apple cares about how quickly people will find the PLAY button, if it takes a few extra seconds, that doesn’t have the same consequences as someone who can walk away from your app in that time.

The digital world, quite fittingly, is much more binary.

Even the type of business that most closely resembles SaaS - the telecom – has its safety nets. We’d likely bounce around freely trying several on for size, were it not for the contracts they make us sign.

Where There Are Constraints, There Are Opportunities

The same time and attention pressures that give the user the freedom to explore and move on, also create the space for web services to get-to-market faster and iterate. This is the advantageous end of the equation that we traditionally, haven’t taking full advantage of. Somehow we’ve only subscribed ourselves to the end of the equation that works against us.

In fairness, coming to market even a few years ago was not as fraught with the same volume of services (noise) as there is today. As a result, it wasn’t as imperative to release and iterate. We could (although this is debatable) afford to try our hand at “getting it right the first time”.

What we’re seeing now are brief windows of opportunity where product/market fit *could* exist, provided we discover that fit before someone else does. The easy example at hand, is Groupon. They came to market, read the data, pivoted, and subsequently found the model that scaled and repeated. Any other Groupon-like site that was still in the lab at that discovery point, lost for that reason.

The windows on opportunities are getting smaller and smaller. There is no sense left in trying to fill an opportunity that exists today in one form, because tomorrow it will have another. Get to market, find the fit, and move with the opportunity by gently guiding it along the course of its development. This is how privacy evolved hand-in-hand with Facebook.

What This Means For Rocketr (and others)

Features don’t establish product/market fit – people do. When the cycle of user behaviour repeats itself in a meaningful and profitable way, there is fit. Until then, there is not. The key is not to take any behaviour for granted.

Here are 3 dangerous (and common) assumptions we are very mindful of…

The Network Assumption
(The value kicks in when you add your friends)

If you’re relying on your service to demonstrate value only after people have added all their friends – you have assumed that people are intending to do so. That’s a dangerous assumption and one we are seeing less and less. The uploading of ‘All My Contacts’ as a first step, is not reasonable. Build around what value the user can derive in the absence of anyone. Then consider the marginal utility of adding 1 more person at a time.

As a point of comparison, services that rely on an abundance of user-generated content, have a similar assumption they need to address.

The Permissions Assumption
(We know who, and how, people will use our service)

We are spending an increasing amount of time on permissions at Rocketr. We have theories about the levels of privacy users will demand. Who they will want to invite at different stages. Where it makes sense to “follow” (a non-requested, 1-way dynamic) and where it makes sense to “connect” (a 2-way opt-in by both sides). We are leaving the doors open right now by imposing minimal parameters, with the hope that the right balance reveals itself through each round of tests.

This means no Twitter Connect or Facebook Connect until we know which type of people you want to connect with, and in what way.

The Messaging & Setup Assumption
(People will understand who we are and what we want them to do)

Today we are rolling out a very short survey (have time for 6 questions?) that tests three styles of naming conventions for inside the application. Previously, I wrote about the evolution of the Rocketr Value Proposition - this falls in that same breath. You have to consider your nomenclature if you want people to perform certain actions. “Teams” are different than “Groups”. “Messages” aren’t always “Notifications”… and so on.

People need explicit instructions, but also don’t have the patience to process more than a couple requests. Asking questions the right way can make all the difference between someone setting up their account or shutting down.

Other Assumptions
(Features we’ve removed from the MVP)

  • The Organization of Content except for a single sort/filter option. Building features to organize content assumes we have a lot of content that needs organizing.
  • Native Mobile Apps in favor of a native-looking mobile app that leverages web standards and existing languages. We are trading true native functionality for the flexibility of maintaining a single code base.
  • Pricing & Monetization - This was a tough pill to swallow and one that will surely raise controversy. While we have 4 or 5 different ways we *think* we can monetize (none of which are advertising), until we see how people actually use the application, it doesn’t make sense for us to assume which parts should be made scarce.

So What’s Left?

Aside from an intense focus on Messaging, Account Setup, Permissions, and the first appearance of Value, we are holding the MVP accountable to certain things we know need to exist regardless: Speed, Simplicity and Enjoyment.

This means we are actively studying, testing and iterating on the little things. We’re obsessing over the size of the writing box, the number of keystrokes needed to construct an object, the implementation of tags, or the occasions where sharing merits consideration.

We are also especially mindful of what metadata we are collecting in the absence of imposing any friction on the user’s account setup, and of the ability for the interface to extend with the product. Keeping with the flexibility theme – on the back-end this means making sure data can be accessed, manipulated, and restructured by external services without having to adjust the architecture. Should we ever need to port the app to another language/framework, we will have a clear and logical process that will allow for swift action to be taken.

As we head into the holidays, our team is still in learning mode with all of this. We probably always will be. There are lots of reasons for building an application, but whatever our reasons, we all need a reminder of what macro trends are at play. From shorter windows of opportunity, to more clutter in the market, or the circumstances for rapid iteration – we can’t ignore the trends. It isn’t our choice whether they exist. We can only choose how to make them work for us.


Addendum
The other factor when considering an MVP, is that it’s very difficult to argue against having some sort of mobile presence and available API. So whatever you think you are building, you’re actually doing triple that to make it available from anywhere and to get it in the hands of your development community. Factor that in when you’re sizing things up.

  • http://www.jonlim.ca Jon Lim

    I think the biggest part of any app is to implement an API – people will want to be able to take their data and mould it into whatever shape they want.

    But I am guessing the implementation of an API should not come before figuring out how people use your app in the first place.

    Thanks for the morning read. :)

  • http://www.endloop.ca Ken Seto

    The switch from a native app to a mobile web app is understandable but don’t fool yourself that it’s going to feel the same to the user.

    Of your 3 factors (speed, simplicity, enjoyment), speed and enjoyment are generally the first to go when choosing mobile web app over native.

    Check out Zynga’s newly released Mafia Wars: Atlantic City. It’s a pure mobile web HTML5 game and frankly it sucks compared to the original iPhone native Mafia Wars game. Every button press brings the spinner, nothing *feels* tactile or responsive, no animations due to lowest common denominator build, and on and on…

    As the hardware catches up (in a few years), the speed problem *might* be resolved but there is still a heavy dependency on the speed of mobile networks. Note that Mafia Wars: Atlantic City still has crap performance over wifi, not just 3G.

    If you want to make a *splash* with your product, native is the best way to guarantee the first adopters will enjoy your product. Fred Wilson notes the importance of speed and delight when using a mobile product.

    This is starting to sound like a blog post (in fact I’m currently working on one on this very topic) so I’ll stop here.

    Best,
    Ken

  • http://twitter.com/drupeek/ Andrew

    @Ken – All good points and none of which I will argue. We are pursuing it this way as a means to conserve resources until we’ve attained product/market fit… at which point I fully expect to re-visit native apps.

  • http://www.endloop.ca Ken Seto

    I guess it really depends if your MVP is for local testing vs. public launch.

    We’re going through the same decision points here at Endloop X. We’ve decided to do native for our test MVP due to available skillset as much as wanting to get as close to the *feel* of a release product as possible.

    As a compromise, you might want to think about using something like PhoneGap or Titanium to see if the performance gap can be minimized. Of course there are complaints about performance on those frameworks as well but I assume it’s still superior to pure mobile web app.

    Good luck with the MVP!

    Best,
    Ken

  • http://twitter.com/drupeek/ Andrew

    @Ken – We are definitely looking at Titanium, Sencha, PhoneGap and others… I might ping you separately for input if you’re cool with that. And thanks!