Software Journal

Once in a while, I do get this question: “So, what is it that you do do?”.  Now, I could say something like product development, but since my Eclipse IDE stopped working back in 2007, I haven’t gotten around to fixing that (yet), that kind of answers that one.  Perhaps the clearest answer is this – conceptualizing software products that I believe can help people solve their problems.  We can dissect that line word by word:

• conceptualizing: I refer to it as “conceptualizing”, as the design and development is usually done by a different team.
• software products: Yeah, that is the space I am playing in, at least at the moment.
• “I believe”: Any product designed is a gamble, and it is best to acknowledge that as such, upfront.
• help people solve their problems: This is obviously at the core of building a product.  The problem that the product will solve is usually the best indication of the success of this product.  Is this problem worthy of solving?  How much of a problem really is this problem?  How many people may have this problem?

There are 3 well known rules of engagements when creating products:

1. Ask the users (but sometimes not believe them): Since the products don’t exist yet, the users have some ideas, but some of them may be too specific to their unique problems. So while the users’ first few sentences are of huge value in describing the problem, detailed thesis are not.  It is best to engage users in small but frequent sessions so they can react to latest version of the product.  Also, this avoids the pitfall of solving a user’s specific challenge on a specific day.  We want to solve REPEATING problems, not one offs.
2. Not worry about the so called “competition”: This is an important concept.   No matter what you come up with, people will try to box other products and label them as your competition.  This is usually done with the best of intentions, in some cases just so as to explain your product.  But focus on the users with problems, not other products that they could hypothetically use but are not using.
3. Don’t overvalue innovation over execution: As Facebook and many other successes have shown, it is a fallacy to think that every success comes from making something new.  Not necessarily true. Any new product usually has 3 kinds of features: (i) Features that are new, (ii) Features that are old, and (iii) Features that exist in a different form in other products.  Counter intuitively, usually it is the last category – the features that exist in other products, but in less usable or functional form – that is the best reason for the success of the product.  (Second in importance are the features that are old.)