The only way to figure out what your users want from your software is to release it and get feedback. As an engineer, this is something I constantly struggle with, because at any given time the actual product is only a pale shadow of what I know it could be if I had just one more week! How can I possibly release it in this state?!
Having a release deadline forces you to prioritize and fix the boring problems you know the user will hit, rather than doing something more fun and arcane. Once it's released, you'll also rapidly discover that users don't care about the things you expect, and drive the product in completely unexpected directions.
A couple of articles this week were good reminders to keep focused on getting releases into the wild. Tom Evslin blogged his advice for entrepreneurs, drawing on Jeff Jarvis's new book What Would Google Do? When Google News was about to be released, the programmers were warring over whether to put their resources into sorting by date, or location. They couldn't decide, so it was released with neither, and 300 of 305 emails from users asked for date.
In a darker scenario, Eric Ries talks about a project he'd been involved with that waited too long to release. It was a well-funded, multi-year project, staffed with smart people with a clear plan that they executed on. I've seen a lot of these at engineering-driven companies, where a powerful figure with a technical background will spin tales of the wonderful software he can build, if he's only given enough resources. They always feel like the Apollo program, full of idealism and shooting for audacious goals. The trouble is, you don't find out if your goals match the customer's needs until the end. No matter how many market surveys and focus groups you run, you'll never get a clear idea of what people will actually pay for. Building it in one shot like that also means you've got a massive foundation of instant legacy code that makes it hard to adapt once you do hear from real users. That's exactly what happened to Eric's project, after pouring years and millions of dollars into the software it flopped on release and the company failed.
Have a strong vision of what you wanted to achieve and big hairy audacious goals, but stay on course by releasing early and often.
I completely agree with this point. Exercise the app, label it whatever you want (alpha, beta) but get it in the hands of users and setup the necessary feedback framework to collect input and take action. On a similar note, exercise your business model as soon as reasonable too. Too often, startup companies keep the first day of revenue collection on the horizon. Until you really start collecting dollars, you wont know whether that business plan with the hockey stick growth really does have a basis in reality. Being successful as a startup has everything to do with building a product that people USE. Building a business has everything to do with being nimble, adjusting and striving to hit your goals in the real world, not in excel.
Posted by: Steve Newman | February 04, 2009 at 11:47 AM