These are rough thoughts and I’d be interested in your comments. Some of the discussion last night got me thinking (again) about product development and why sometimes it works really well and sometimes it doesn’t.
For me, the key question is: When developing products, how might users specify what they want? It’s well-known that users don’t actually know what they want, and if you build what they say they want it won’t sell. Innovation doesn’t come from focus groups, though optimiztion might. So, when developing a fast-changing product like anything built in software, how can the developers figure out what to do?
One example of a technology that was designed, built and integrated quickly was Really Simple Discovery, by Daniel Berlinger. This is a scheme to make it easier for client software correctly configure itself for server-side apps. It was designed with consideration, a demo was built quickly, and then other people integrated it into their apps. Dave Winer built it into Radio. Ben Hammersley made a module for Moveable Type. Jake Savin added it to Manilla. Brent put it in NewNewsWire.
Why did this happen so fast?
One reason is that in the world of weblogs both client-side and server-side product companies are small and can move quickly. The owners of the companies involved are engineers (or perhaps designers) – they _get_ the web, weblogs, and know a good idea when they see one. Further, the idea was easy to implement so it was a no-brainer to build. They weren’t building a space shuttle.
In this example, the users are the developers. That’s the key. The users can specify what they want by building a prototype and showing it to colleagues. The idea is then improved until it’s “good enough” and it ships.
Regular users can’t build anything themselves. All they can really do is complain about why Word does something in a stupid way. Even if you could write a specification for an improvement, where would you send it? “comments@microsoft.com”? I don’t think so. Even when there are feedback forms or email links it’s hard to know whether it’s worth the time. Will anybody really read it? Will the Right Person read it? Will I just get another corporate thank you note? What’s the point, let’s move on.
For developers, it’s often faster to write code than to write a spec. Users can relate to the screen, and developers get feedback. It’s especially cool with weblogs because the community is building the publishing tools (Radio, Moveable Type, etc) the syndication technologies (RSS, RSD) and the news aggregators (Radio, NetNewsWire, Synderella). Developers can advance each piece together and rapidly make progress in an entire realm. This is _a lot_ different than traditional packaged software applications. The “killer app” becomes a “killer set” or “killer platform.”
This places a burden, perhaps even a responsibility, on the developer to help regular users along the curve. I know this is sometimes controversial, but for the sake of argument let’s say that in at least some cases, developers want users to use their products. Maybe even buy them so they can build more products.
I propose that well-designed, well-documented and well-supported applications do better than apps that have no sense of design, are poorly documented, and are not supported. This is a base level of user support. Going further, a community may develop around a product providing user-to-user support. This is a developers dream because it lighten’s their load while providing better support. You still have to have the basics though, to jump-start the community.
The next level, pioneered by Novell and perfected (like all 2.0 implementations) by Microsoft: The certification program. This creates classes of people with credentials that regular users can call on with a better sense of knowing what they are getting from their support visit. It’s a branding thing, good for both the vendor and the customer. But it’s especially good for the vendor becuase it can be a profit center. Customer support is hard to turn into a profit center, but this is one way.
I’m interested in your ideas about how users can be better involved in requesting and designing software, and products in general.
February 12, 2003