So you've had a really great technical idea that's going to change the world? Here's a very simple sanity-check.
First, you're going to need some use-cases. Think of the precise situations in which your idea is going to be used. Each use-case should feature a user in a specific situation, using your new technology to reach a plausible goal. (Note: plausible goal. I'm assuming here that you've already determined that this use case is something that people will actually want to do, provided there is a convenient way to do it. If it isn't, stop and think of another one.)
Except... use-cases aren't supposed to dictate the form of the solution. Delete your technology from the story, and ask yourself the big question. "If my new technology didn't exist, how would the user go about reaching their goal?"
Now:
- What are the advantages to the user of doing it your way? (This is important. To the user. Not to you, not to your paying clients if they're not the user.)
- What level of adoption would you need before your way was sufficiently better than the other way for people to want to switch?
- How will you manage to bootstrap your way to that level of adoption?
Make sure you closely examine your "advantages" for hidden assumptions. If one of your advantages is that a user might not know how to do it the existing way, how are they going to learn to do it your way?
If you can't confidently say your way is better, or you can't see a way of bootstrapping your technology to the point that its users see solid returns, then you are a solution in search of a problem. It may be a clever and elegant solution, but without a problem to solve, it's just going to sit on the shelf as an idle curiosity, gathering dust.
Note, I'm not talking about business models. Finding out how to profit from the technology is the next step, and one I'm totally unqualified to pursue. I'm just looking for the answer of whether the technology's existence actually makes the world a better place.
Here's an example: Sun's JXTA P2P architecture.
- Use case: A developer wants to create a P2P application.
- Alternative solution: The developer comes up with a new P2P architecture from scratch, or builds their application on another architecture such as Gnutella.
- Advantage to the user: JXTA allows the developer to write their application on top of an existing P2P framework, saving them time and duplicated effort.
- Necessary level of adoption: The architecture must be considered proven in the real-world, and thus trusted as a basis for new applications. Preferably, some widely-adopted P2P brand should run on top of JXTA.
- Bootstrapping: Evangelise JXTA to the developer community, until such applications exist.
The fourth point seems a bit based on blind hope, doesn't it? You can't know the framework is worthwhile unless someone creates a large-scale, successful application. People won't want to risk a large-scale application on an unproved framework.
Of course, the killer app of P2P is file-sharing, and Sun couldn't really get into that arena themselves without causing some serious Marketing headaches. :)
Sometimes, it's not so much of a problem with frameworks, because they're written for the developers to use themselves. How about WebWork (I'm not a WW developer, so the 'we' here actually refers to people other than myself)
- Use case: a developer wants to write a web application in Java
- Alternative: use Struts
- Advantage to user: we find Struts annoying
- Necessary level of adoption: very low. So long as it's better than Struts, it's already made our lives easier
- Bootstrapping: we use it ourselves and tell our friends
Sometimes, the test can fail very early. A lot of the dot-com flops could have done with this sort of self-examination.
- Use case: A user wants to find a particular company on the web
- Alternative: They try the obvious URLs, copy the URL from advertising material, or failing that they look it up on Google
- Advantage to user: Erm... er...
