What is a "product"?

LAME ON

This isn’t specifically about Web 2.0, but I don’t have any other place to put it. But it does apply to Web 2.0 products just as well as it does to any other products, so, strictly speaking, it is on-topic.

LAME OFF

(Okay, that was a joke I just made up. It refers to the “Flame on” / “Flame off” phrases often found in the “newsgroups” that have largely fallen out of use. I apologize to those not familiar with that old stuff.)

What I do for a living is to create or extend products that are software-based. But what do I mean by a product? There are lots of definitions (e.g. on Wikipedia), but I haven’t seen one that captures some of the key characteristics of software-based products. Software is infinitely malleable and this has a lot of implications. For instance, having more features does not necessarily imply having a better product (which may come as a surprise to most of the programmers at Microsoft, given what they produce).

So here’s my definition: A product is something intended for use by people you don’t know.

I created this definition because of its implications for product builders.

• Because you don’t know the users, you can’t assume too much about them. For instance, you can’t necessarily assume that they understand big words. (When I was editing the Sympatico user’s guide I would sometimes cross out a word and write “too many syllables” and send it back to the writer.) And you can’t necessarily assume that they will remember to save their work occasionally, for instance.


• Because you don’t know the users’ hardware, you can’t count on things like having enough memory to run your product properly. This problem may even apply to a Web-based product, but far less often (one more reason to be Web-based if practical). You may need to build in a check that warns the user if there isn’t sufficient memory, and maybe even exits the product.


• Because the users don’t know you, they’re not all that likely to ask you questions about how to use the product (if it’s not reasonably obvious, they’ll either be annoyed or write off the product). The product must speak for itself. (That includes documentation, but hardly anyone looks at documentation, so it’s not of much help.)


• Because the users aren’t your friends, or even acquaintances, they have no reason to be forgiving if they find something that they dislike. Such as a bug that you consider “minor”.


• Because the product may be in use at 4:30am your time (distant users, or nighthawks), you need to think about what the users might do if they run into critical problems when your team is not normally available. You have a range of options, including “no support outside office hours”, and it’s a good idea to make a considered decision, with appropriate followup actions, before anything bad happens.


• Because you don’t know what the users will do with your product, you should consider what they might do that you don’t expect. Things like extremely high usage levels, and cases of “but nobody would do that — it wouldn’t make any sense!”.

All the implications like the above make building something that’s a true product a lot more work than something that’s a mere “program”. It could be many times as much work. (Sales pitch for myself and others like me: it’s a good idea to have someone on your team who’s experienced with these issues, or things will be much worse than they have to be.)

So what do you think of my definition that a product is something intended for use by people you don’t know? Comments welcome.