My motivations for Flashmark were based on this essay. It is a tool aimed at my learning issues. I wanted this for myself. However, recent attempts to market it drew little interest. Nobody tried it. Nobody commented. I'm mostly okay with this! But it did get me thinking of the whole idea of building software people want.
The Four Quadrants Of Want
There are four kinds of "want" when it comes to a software product.
Quadrants Of Want
Quadrant 1.) The developer wants it and the users want it.
This is ideal. The developer is a user and other people use it too. Mark Zuckerberg has a Facebook account as do over a billion other people. There is also the case of the smaller developer who uses her own SaaS product but also has a couple hundred paid subscribers. Whatever the scope of your user base is, this is the best quadrant to be in.
Quadrant 2.) The developer doesn't want it but the users do want it.
This isn't a bad deal either. You have no dog in the fight when it comes to the product. Still, users like it enough to pay which means you get paid too. I've worked on software for archiving airplane part drawings and tracking phone tolls in office telephone systems. I have no personal interest in planes or phones. Still, the process of working on these things was enjoyable and co-workers were awesome. These were good gigs.
Quadrant 3.) The developer wants it but the users do not want it.
This has happened for me twice with Flashmark being my most recent instance of this. In the past, the Uncle Squirrely was a project I did that notified me of videogames that just dropped to "greatest hit" price levels. In neither case did these projects get anything in the way of a user base. But I didn't care. I was scratching my own itch. It didn't matter whether or not others had an itch in that same spot.
Quadrant 4.) The developer does not want it and the users do not want it either.
This is what Paul Graham wants people to avoid. It happens when you don't want the product but you THINK other people will buy into it. When they don't, the end result feels like a waste of time. Pure demoralization. Graham felt it first hand and would rather other startups not be crushed by that same defeat.
Moving Between Quadrants
When you start in quadrant 3, you are guaranteed a user. It is you. You are a worthy customer base to develop a quality product for. Know it. Believe it. Even if the product never leaves this zone, you are at least spared the quadrant 4 nightmare scenario.
Quadrant 3 projects can serve as potential gateways to quadrants 1 and 2 if you allow it. The key thing here is to be open. Share what you are do as early and often as possible. This allows for feedback for improvements. It could lead to a new job. It could make your project profitable. But most importantly, feedback makes projects more fun. You'd be out of your mind to not want to up the fun factor!
Practicing What I Preach
Don't do what I did with Flashmark. There was very little communication with other people during that project's development. Only two release announcements were ever made about it. Both of them were made when the project was close to "done". The end result is still a success. However, I will admit it would have been nice if it were a different kind of success.
Instead, do something like this..... Last week, I started a just-for-fun project to put up a web interface to the apt-cache tool commonly found on Debian and Ubuntu systems. I'm doing it because I'm curious. How easy would it be to build a small AngularJS project using a component-based approach? How would it work out if I put a Flask API on top of a command-line tool? That's what I'm interested in finding out with the AptPackageShow project. It's incomplete but you can go here if you want to check it out. Comments welcome!
See the difference there? With AptPackageShow, the conversation opens up almost right away instead of the "not talking about it much" approach taken with Flashmark. I'm going to go out on a limb in saying that this is a better way.
No comments:
Post a Comment