In part 5, I described the importance and power of simplicity. In this part (written during my lunch break while visiting webMethods in Sunnyvale, CA) I focus on how we planned product roadmaps.
In general, it’s a good idea to have an up-front game plan for product releases. Here is a list of the constraints and assumptions that we used when formulating such a plan:
- One year or less from the initial prototype to the 1.0 launch.
- At least three beta releases before 1.0.
- At least two point releases between major releases.
- One year or less between major releases.
- Features aren’t included in a release until they’re very simple to use.
- In tradeoff situations, ease of use and quality win over feature count.
- Useful subsets of standards are OK in the short term, but should be fully implemented in the longer term.
- Listen to users more than to analysts when selecting features.
- There will always be a patch release 1-2 weeks after an official release.
- Point releases should be 100% API compatible and easy to upgrade to.
- Major releases can occasionally break APIs, but this is to be avoided.
- On-the-wire compatibility is even more important than API compatibility.
In the case of Glue, it took about 6 months to get to the first beta, and another 6 months to get to 1.0. We released a total of four betas in the build-up to 1.0, which gave the community a good taste of what we were up to as well as providing plenty of opportunity for feedback. And by releasing point releases every 2-3 months, it wasn’t a big deal if a particular feature slipped to a subsequent release, as the delay was just a few months.
I’d like to share an anecdote about one of the items in the above list: listening to users more than analysts when determining feature sets. In the early days of web services, analysts were saying that adoption of web services would not take off until XML-based security standards like WS-security were available. Because of this sentiment, we thought that Glue might not be adopted until we implemented this particular standard. But due to resource constraints, Glue 1.0 only shipped with support for SOAP over HTTP and HTTPS. But to our surprise, most of our customers didn’t really care about WS-Security, and found that HTTPS was sufficient for secure communications. This was an example where users had a significantly different set of needs than those being suggested by the analyst community. Later, of course, we added support for WS-Security, but even to this day it is a feature that is rarely used.
I’ve always been a big fan of engaging the user community in an open and conversational style, and set up a Yahoo Group at my last company to facilitate communications. During the development process, we would sometimes even ask the community for their opinion on alternative designs or API naming schemes, and the feedback was incredibly useful. In addition, it demonstrated that we were truly user-driven and cared very much about making the product as intuitive as possible.
I believe in maintaining an up-to-date 1-2 year product map on the web so that users know what’s in the works. Such a roadmap always came with various legal disclaimers, and features on the roadmap occasionally moved around based on user feedback. If a key feature was missing or scheduled too far in the future, users definitely let us know! One counterargument for doing this is that it lets your competition know what you’re up to, but I think that the pros of a public roadmap outweigh the cons.
At my last company, we also posted a product release history on our web site so that the community could see how the product was evolving, as well as showcasing our productivity. The last point might sound rather immodest, but let’s face it, seeing a company crank out quality releases at a rapid rate is a great way to earn respect!
In the next part, I’ll discuss the process we used for developing product releases.
Comments