the perfect product balance makes the user both love and hate the experience. the love comes the way the product solves the user’s problem and the way it makes them feel in the process. the hate stems from the love, because by loving the product so much the user wishes it did even more. any place in between is product ambivalence -- a no man’s land where projects and companies die.
perfect product pacing starts by solving a clear problem and shipping a simple first version of the product, only moving on and building more when the love and hate are sufficient and growing. you start by having a meaningful first product, but as as reid hoffman, co-founder of linkedin and now vc at greylock, says, “if you’re not embarrassed by your first version, you’ve waited too long.”
too often an inexperienced founder will hesitate and struggle to get that alpha or beta out the door because they are tuning and building in fear that the current version isn’t polished or doesn’t do enough. even experienced but undisciplined product managers will make this mistake, bolting on too many features without justification. the key is to have an early thesis of why specific users want what you’re building and set out to prove this with as little code, development, employees, and cash as possible.
this is the tact i took with airbear. for sure early brainstorming and mocks crept towards a bulky v1 product, but i ultimately got it down to providing one clear value prop -- simple breastfeeding logging that lets parents know how that day’s feedings are going. users noticed this and responded.
over 10,000 feedings later, positive reviews, and lots of love were also met with plenty of criticism. what about bottle feeding? why can’t i see the history? seeing x or y data would be useful? can you add alerts? this level of hate and wanting more not only showed me that there was an audience for airbear, but also showed me what i should work on next.
arguably the greatest value this diligent method of product pacing provides is not having to go back and rework or delete old, stale features. probably half of my day job these days is stripping out old features or irrelevant functionality that was built too soon and without justification. des traynor, co-founder at intercom gives a great talk that compares two products. one is a simple product that sees its competitor with tons of features and thinks ‘we need to add those’. meanwhile that bloated product sees the simple one and thinks ‘i wish we didn’t have all these features, which are hard to maintain or that no one uses’.
beware of product envy and build only when the time is right and the love and hate buckets are overflowing. some of the best products today did that, even with millions of venture capital in the bank. nothing shows prudent product pacing quite like the time between launch your iphone app and android.
if people love your product, after around the first few dozens of users you will start hearing requests for android. these four companies clearly had the love factor, but they still waited on average for almost a year and a half to launch on android (and you can be sure that a lot of hate was piling up during that time). if you’re curious how other great companies progressed and paced, there’s a cool site that lets you explore their timelines in more detail -- http://www.startlin.es/timelines/
part of being a release note connoisseur means i also spend a lot of time looking through version history. how, why, and when app updates are pushed tells a lot. granted big mega corps like facebook or twitter are on a bi-weekly cadence of ‘minor improvement’ updates, but the early days of an app show the most drama. big new features come out after a quarter or two of listening and talking with customers. these can be the hardest months as it’s easy to just want to keep shipping new stuff. but it’s when you have hundreds of users (as opposed to millions or billions) that you have the freedom to both wait and be bold.
code cleanup and performance stuff aside, resist the temptation to ship new stuff. wait to see not just how many people are using your product but also how they are using it (which could surprise you), and by all means focus on growth. that’s the road i’ve been on since launching airbear in february, and i’m excited to announce a long awaited update in the itunes app store.
with the last airbear update, we are now just at step #2. if we’re going to get to step #3, that’s going to take even more hard decisions about product pacing. they may have the same number of wheels, but a bicycle is far more complex with far greater potential.
what step is your product on?