More On Problems You Are Solving

Unless you at least believe that you are solving a specific problem, you are going to be completely directionless.

Yesterday’s post kicked up quite a few responses, including the most common one (as stated by Sriram Krishnan):

“Sometimes you’re inventing a new form of behavior all together-and you may not know how to express in problem-solution terms” — @SriramK

My response to that was that while this may be true for outward-facing communication, it can certainly not be true internally. Unless you at least believe that you are solving a specific problem, you are going to be completely directionless.

This is what happens all too often when geeks design products – we tend to be more enamoured with cool features, and get distracted from the fact that in the end, a product that doesn’t solve a real problem for users is not a product people will use.

This does not mean that you can’t drift along, experimenting, playing with technologies, etc. But understand that you better have enough funds supporting your R&D – unless you come up with something concrete that you can show the world (even if it is just VCs), you are basically treading water.

The important point here is internal clarity about what you are doing. If you do not have that, and have everyone on your team on the same page, you will face demoralisation, and eventual erosion of your team. Unfortunately, I have seen this way too often (at places where I have worked, as well as among startups that I mentor).

As Sriram and others have pointed out – Twitter drifted along without a problem statement, before eventually settling on a business model that they are now beginning to exploit. But Twitter was a special case – successful exits by the team from previous endeavours made sure that internal funding was not an issue. They could afford experimenting (and they sure did).

Whether you can do this (or not) is something you have to decide for yourself. Just make sure that the internal communication and direction is clear, and that you eventually arrive at a real problem statement, and are working towards a solution that defines your product.

No matter which way you spin it – the success of a product isn’t defined by your enthusiasm or internal geek-outs, but by the way external users take to your product.

Which, of course, brings us back to the original contention. :)


If you have any comments, or wish to discuss this post, please do so on Twitter, where I interact under the ID @AtulChitnis