The nervous founders and issues with transparency in software development process
In product development the extent to how much you want to be transparent is always a challenge. Specially if you are building the software products as a service.
When you are building “new” stuff you never know exactly how long its gonna take, even if it is somewhat similar to a million things you already built. This time you might venture into a new technology or an evolved version of the same Tech stack. The SDKs you worked with may have totally changed... You send out an estimate and it is treated as a deadline (I earlier wrote a note on that as well). Yes we always fall in that trap. BUT then you hustle to work towards that deadline. Things become complicated if you get the founder involved in your process and make everything transparent. Having daily updates and standups and involving the founder in that is a complicated thing. This becomes even more complicated when the founder is not sitting with you in the same room throughout the day, which is the case most of the times for us. There may be days when you were not able to make ANY (apparent) progress and were stuck in something very very stupid. Yes in software development it could be ANYTHING. This can happen to very experienced programers as well. It may happen that in the next standup you just have to repeat the same thing again. You can either say you got stuck which may be taken up as “you did not know how to do it” OR you say this task needs more time, in which case you are actually not being totally honest or transparent.
So what do we do in these situations?
We say we got stuck. We believe in transparency. There will be times when we will get stuck but that is part of the process. We will only build new stuff if we venture into new domains. This is why founders work with us when they want to build unique products. They get nervous during the product development cycle. At times our team gets quite irritated because of this approach as well. We end up educating the founders about technologies, processes and methodologies, which turns out be an overhead. BUT we still believe in transparency and we love building the products with the people who conceptualized them.
Product owner is an important stake holder of the product development lifecycle. In most of the cases founder is the product owner. By being open and transparent about our processes and work we make sure that we work as close to being an “in-house team” for the founders as possible. We make mistakes as well but we are open to own them and share those mistakes with all stake holders.
The problem comes in when the founders become nervous for (apparently) wrong reasons. Here are some of examples that we encounter in almost every project:
Founder may be giving too much importance to minor UI issues at the stage when the engineering team is focused more on the functionality.
The panic situation when a huge list of bugs come up after first round of testing.
While the dev team understand that these situations are part of the process , the founders generally become very apprehensive about the whole process. Situations like these suggest that we should give partial visibility to the founders but I am against that. I think the founders have the right to learn the process of product development and know about the ups and downs of the complete process. If it were that simple everyone would have built the same product.
The ending matters. It all goes well if it ends well. If the end product is as per expectation the process is considered a success. BUT I have to admit that we do not have a 100% success rate in terms of creating a product that was expected. In those cases questions are raised about the complete process. A postmortem of the complete development cycle results in a number of situations or decisions which should have been handled differently. In these situations the transparency hurts us. Our faults get exposed. The founders at times do not want to work with us again because they know our faults.
We are the experts and we are not allowed to make mistakes. Unfortunately that is very hard to achieve. We continue to make mistakes and continue to share our mistakes boldly. This enables us not to repeat the same mistakes again. This way we have been able to step up our game with every development cycle. We may not be the experts who won’t make any mistakes, but we definitely are the ones who now know of 1001+ mistakes that are NOT to be made during product development cycle.
AND that is why we continue to work with more founders building amazing products that are changing the world :)