Today’s post is by request. Someone pinged me on IM today and said that they had an idea for a blog post, but wanted to see me write it, not them. It was an interesting enough topic, so I’m obliging. This person may or may not work for Yahoo! and have a hyphenated last name that includes an item you’d find at a hardware store.
Working on applications where you are the intended user is undoubtedly more the exception than the rule. Not all apps and servers are consumer facing, and ultimately they’re probably trying to cater to a much wider audience than just you. On the other hand, niche applications still require a wide range of staffing and support, and so I don’t assume that all of the front end developers at Kayak like to travel or that whoever does sysadmin at Suicide Girls likes busty pinup girls with tats in leather. Ok, wait… maybe that was a bad example… but you get the picture. You’re not always the user, but is it an advantage to be the intended demographic or will it cloud your judgment?
I think the answer isn’t A or B, but C… that it probably doesn’t make nearly as much sense for someone on the team to be your intended demographic as it does for you to be immersed deeply in the community of your potential users. So, if I’m building a social network for bungee jumpers, the fact that I’m afraid of heights shouldn’t really prevent me from being able to build a great app for them—so long as you are constantly getting community feedback on what you’re building. In fact, you’ll probably be better at interpreting the feedback of others than you will be at identifying what will solve your own problems—if for no other reason than it’s easier to identify trends in the feedback of many than a trend of one.
At the same time, when you’re not necessarily solving your own problems, you’re less tempted to “fall in love” with certain features that don’t advance the product towards key milestones. In a certain sense, good product managers need to be a little dispassionate—with a quantifiable, logical, and actionable process for adding or removing features or changing strategy.
That leaves open the question of where the original idea for the business or service comes from in the first place. To some extent, you already need to be immersed in an area to identify a new way to create value—but it would take a lot of passion for that space to really want to build a company in it. So, while I’m probably advocating a dispassionate product development process, at the same time I don’t necessarily relate to the Fabrice Grinda “9 criteria” approach to entrepreneurship—which lands him in ringtones one day, international marketplaces the next, and almost put him in cloud storage. I feel like its more likely the case that you start out with a way to solve a problem that is close to your heart, but that, at some point, you have to put on your surgery scrubs on and operate on this service like its a machine, not someone’s grandma.
Some might argue that this approach makes it less exciting to build an application, since you’re not the intended user, but I don’t really think the best builders are motivated like that anyway. They want to solve interesting technical problems, make services that are more robust, faster, and scalable. To the extent that they’re solving the world’s problems or their own I think is more of the cherry on top—not the main reason to work on that project. It’s certainly not enough to keep you at a place if you don’t have interesting challenges—and at the same time, few people I know with interesting, if not basic, product development challenges got tired because they didn’t care about using any of what they built as a user.