We launched the blist service in beta in late January of this year. Since then we’ve been managing what I think of as the five tensions competing for our limited software development resources. They are allocating development budget between:
1) fixing bugs thereby making the application more stable
2) improving performance
3) adding new features
4) instrumenting the application
5) automating operations
You can’t ignore any one category for too long. Focus only on new features and users grow impatient waiting for bugs to be fixed and performance to be improved. Ignore instrumentation and it’s harder to know what areas of the application need more work and it takes more effort pulling together metrics to run the business. Ignore automating ops and your valuable software engineers end up spending too much time performing manual system administration tasks.
The right solution is to invest in each category. The difficulty is in figuring out the right ratio. Candidly, we haven’t figured it out either, otherwise I’d tell you. What’s most important is to constantly reevaluate the service and asking what area needs the most investment and have a development methodology that allows you to be nimble and change priorities often. Analyze the data. Ask your users. Read the entries in the community forums. Adjust. Apply. Measure. Adjust. Apply. Measure.
We’d love to hear from you. What must-have features are missing? What’s working? What’s not? What’s too slow. How can we make blist better for you?
If you enjoyed this article, please consider sharing it!
Good set of categories, but, it’s not “beta software” or a startup – any software product has the same five kinds or work.
It’s not “software product” either – any engineered product has the same five kinds of work.
If you ever think you are done with one of these categories, you’re confused. If you ever stop being constrained by resources vs. your ideas for what you might build with them, you’ve checked out.
There is no fixed optimum, either. Living in that balance as it changes is the game.
[...] 17, 2008 Business , Software , Startups , Web Tags: blist, prioritization I wish I had read this post by Kevin Merritt before I gave my talk last night at STS. This is good stuff, and the general concepts Kevin [...]
And also, getting the documentation right, and up to date. It’s nearly as hard as getting the software to do what you want, and there are so many different ways readers can misunderstand the documentation.
Nice post Kevin, I concur. All I can think to add, is “connecting with customers”. This is pretty easy via forums and email support; it’s important for developers to spend at least some time doing it. Start-ups have a great opportunity to establish a customer-oriented culture early on because it’s just so easy to direct connect with users.