How knowledge becomes a blocker when you design products for end users

If you are the one having a background of working for big companies in the past, having worked on large projects, having met a variety of customers, written 100s of functional, architecture documents, travelled across the globe, having built small and medium sized products, having handled small to medium sized teams, having worked on numerous state-of-the-art technologies,

does it all help when you build a brand new product for end users like you and me?


I feel they block you from seeing the simplicity you need to reach ultimately in your design.


They block you to the extent that your brain constantly brings in ‘complexity’ of extreme nature ultimately making you roll into your comfort zone of what you were always doing. If you are a techie, you think the ‘How’ to solve it rather than what is needed for that end user or who is that end user. If you are a business guy, you weigh everything with money and business models and break even and so on without understanding how beautiful something can be conceptualised which makes life easy in selling.

The end user is that ordinary person who would like to look at things that are ‘cool’. Things that give them some value no matter how big or small. For example, my 5 year old goes on using the ‘Talking tom’ app pushing the cat, rubbing it and seeing the facial changes and the sounds coming out of the cat in the App. This is such a thrill for him. It is not to say you design everything like a game or entertainment, but you got to find those ‘nice’ and ‘beautiful’ things beyond the mundane even if you are designing a spread sheet.

The small things that are haunting have a big effect than the big things that you have no choice but to use. You want to get back to those as often as possible.

This is why I feel you need to completely unwind and become a ‘empty cup’. This is not a button you press and you are degaussed. This takes time and an enormous amount depending on how much assumptions you have built about yourself over time. If they are too many, unwinding becomes that difficult. It may sound like the philosophy of OSHO.

Dropping what you have done and taking a fresh look at the problem in hand, every day, every moment is all that is needed. Constantly questioning your own assumptions and trying to break free and see you are in an unbiased state is often needed. If you continue to do this you will eventually have unwound with a pair of fresh eyes.

Why is it difficult to understand code?

If you are asked to read and understand a software that spans 10000s of lines of code, it is impossible to do it. Even if you spend months, you may be able to fit some pieces but will not end up getting a hang of what the code does.

This is the real bane of software. In fact this is true even for some one who has had a long gap and end up staring at his own code.

This is true, no matter how much of annotation, commenting, documentation that is there.

Code commenting and documentation is only a small step in the direction of understanding one’s code. The reason is, a code is something that changes so drastically during its early phases. Almost all the parts of the code is volatile like a molten lava. Needs change, perceptions change, how you solve something change. It is hard to keep up the documentation or commenting in line with the code change and it will almost always be erroneous.

Coding a large software is like carrying a model in your head which is having several moving parts. It is like how Einstein would have carried his view of the universe and all the lingo of general relativity and associated visuals, albeit in a small way. No other person can understand it unless they get this model right. No matter how much of a documentation is out there.

Over time, if the product survives, portions of the code gets stabilized. If the design decisions, the perception of customer needs are reasonably accurate, the initial core of the code remains somewhat intact. This is really the time to ‘document’ the code. This is when the model in the head of the programmer can be laid out in diagrams and words and comments and algorithms to make sense to others who may enter to maintain or enhance it.

I would say the initial period of development of anything should be by a team which is sitting next to each other. Until it reaches the ‘inner core’ level of stability there is no need to document anything. Everyone simply codes. Everyone talks and listens to one another and grow the model in their heads.

Teams spread across require specs to be developed and integration etc. to be planned. These are like turning an already muddy water. If there is a choice, never have your initial development spread across teams. This is because, unless two brains are in synch in terms of the language spoken, visualizing the model there is always a gap to be filled up and time to be wasted and mistakes to be made and frustrations to be built up. And two brains to be in synch is not a question of skill, but a question of attitude. Hard to get.

Even if there are documentation after reaching the stability, it is nothing like having the original team around. If you happen to lose the key members, ensure their video lectures are captured that gives the ‘model’ that was visualized, key algorithms used, key decisions, assumptions made all along. This can help the developers to latch on to the context of looking at the code.

What is so difficult in building a successful product?

After spending years on building a product, pivoting, iterating, which is yet to be launched, I can share some of my thoughts about this question.

Idea is the first step

You have a interesting thought of doing something in a way that is elegant, cool and effective over how it is being done today.

This is the starting point.

Exploring the idea

Here you start expanding, imagining the different aspects of the idea itself. It is a very free format thinking that happens throughout the lifetime. This can branch off into other interesting ideas and often you may leave the original idea and find something more meaningful and interesting.

This phase can involve prototyping, talking to customers, finding new use cases, finding customer segments, finding new ways to solve the problem, innovative thoughts, usability aspects, customer delight, engineering challenges, marketing challenges, scale and so on.

This phase can go round and round in iterations. Often people say to get traction, you should start building something with few potential customers in mind and then keep iterating until you can see that the existing set of customers are able to use it easily, find it is useful and move on to increase the base.

It is often a way you iterate your product while listening to its first set of users and adjust / re-adjust to see that it is exactly meeting the real problems of the users. It is quite possible that you find the problems you originally thought or not the real problems and the real problems are way different.

For example, when I built a collaboration tool for businesses and showed it to few business people whom I had in mind while building it,  I realized most of them do not use computers and they just keep track of their biggest orders without worrying about other smaller ones. So the problem of a what I perceived as a collaboration on various orders that are happening simultaneously suddenly fell apart as they just focus on few big ones for which they do not need a tool.

Of course, it is quite possible that such a need may be there with a retailer who is dealing with a huge amount of inventory and collaborating with his suppliers. But you suddenly find that the product you envisioned as a broad collaborative tool that can work for any one is narrowing to a segment.

This cannot be figured out easily until you are deeply connected to a domain like healthcare or education or others. If you are a generalist being a software guy, your field of vision does not have those specific problems outside computers. You end up imagining those domains and often get them wrong in terms of the real problems faced by the people who are there.

That is why products that are built for domains do not work for other domains. Or those that are generic in nature like a email which works for everyone does not solve the domain specific problems without adequate customization.

It all depends on which direction you decide to travel. A Google or a Facebook deals with the domain of information and communication which is a horizontal concern. If done well, they can be used in a domain agnostic way. But the catch is, finding such a broad based problem and seeing it work for all requires understanding the most fundamental needs of humans and trying to find the most simplest way of solving it. This can be done but requires a lot of research, lot of experimentation and perseverance.

So this part of exploring the idea and bringing it to a way for end user consumption is a long iterative phase. You cannot call your successful here just by raising funds or bringing in the first 100 customers. It can die even after getting your first 100 customers.

The most important thing to do in this phase is to constantly iterate and validate until you are confident that it works for the small subset and it can scale to a larger set.

Building the product

The actual product comes into existence only when there are customers already using it and demands more and more out of that little thing you originally started with. This is the phase where things start to get bigger. Engineering , customer support comes to the fore. Till this point, you have to be nimble and should not bother about anything else other than getting the product and the market fit right.

This should be the least worrisome phase in my guess if I ever get to this.

Some mistakes we make

We often think that the product should be built with a lot of focus on engineering. While this is not wrong, it is important to see who the hell is going to use this and how big is that ? If this is not addressed the effort put in to make something goes waste. Early on getting the feedback of target users is a great thing to have.

If you are building something very generic, often you will struggle to find this target user. You end up thinking every one can be a user. For example, if you are designing a new email thing, you may think everyone who is using email today can use it. But where you may fail is, if you are not showing something unique and differentiated then existing people would not move into yours. On the other hand, if you build something special , say it is more useful as a CRM type of email solution, then you better focus on businesses who are overloaded by their customer communications and would like to try your thing.

Going for funding initially is also a waste of time. This can distract you a lot from what you want to build. The best is to build something, find some target customers who can try out and correct things, iterate and keep trying to find what is so unique about what you have built and how easy it makes the life of your target users. Because time is a precious commodity, you may want to use it sparingly for stuff which drives you out of the main goal which is stated in the beginning of this paragraph.

Going for patenting is a waste of time. How much ever innovative your idea is, being a software thing, unless you have invented a algorithm that is so fundamental to solve that problem, spending time and money on patenting stuff on the overall idea and the way you solve it is a absolute waste of time. You may find that there are so many variants of your idea already floating in several states of maturity. Patenting is a time sucker. If you have time, then go for it. It helps to understand and broaden your thoughts without a doubt, but it does not help you to validate your idea ever. I also feel being a startup, patenting cannot be enforced even if some one violates because you simply do not have that financial muscle. On the other hand, if you have done something smart and even if you do not have customers, you can be a potential buy out by a corporation that is desperate to get a head start in that direction.

Update 1 on patenting - One of my friends told he had to face a lot of trouble when they designed a internet based backup product from lawyers representing other companies as they did not patent some of them. It was a horrendous experience. So, I would say that if you have a non-obvious way of solving a problem which gives the best result, then it should be considered for patenting.  So, my original statement of 'patenting as a waste of time' should be figured out by you as to how non-obvious/novel or trivial the thing you are trying to do.


Giving up too early - Either you do not keep good health or a good bank balance or you simply do not have the persistence to try out things. It is important to keep yourself steady on health, finance and mental strength to be there , float, try out and see what opens up for you . If you read Papillon or South you will know what I am talking about. It is all about endurance and your ability to float against all odds. You need a large dosage of hope and be able to guide you to see the light at the end of the tunnel. You may be lucky to start seeing it early or can go on forever. That is the reason why you start somewhere , read the pulse of the target customers, pivot, iterate and so on. Often it is possible you may land up with a big idea in the process if you keep at it. Or in the least, you may know the area better than any one else leaving you other possibilities.


I feel if you keep at it, you will get it right some day.

Listening to the wrong folks for advice.

Like the way you figure out the right customers for your product, you also need to figure out the right set of people who can advice you on. You need to keep miles away from people who have never built a product or taken it to customers all by themselves. Every one has a view of the world and it is completely your discretion to identify the noise from the signal. Most of it is noise. Almost all of them. The signal can only be seen by you.

No one can tell that a idea will bring you million bucks or it will fail. It is as hard as finding water on Mars.

Glamour quotient

Building a product that works for a broad set of people in the world is not a glamorous thing. If you came in looking at the glamour of a startup as touted everywhere, you are doing a disservice to yourself and to the world. I feel it is a deep meditative thing. You are absorbed entirely and you cannot be filling your brain with anything else other than getting the best out of your brain for the problem in hand. It is really tough and cannot be anything that you have ever accomplished before.

It is the next toughest thing than all the previous things you did in your life.