Anand Bora is a one of my most valuable friends. He has helped the San Diego Visual Arts Network make extensive improvements to our website and was involved in the DNA of Creativity project in both the SDVAN View Art Now App and PAMM Polyaethetics: Mapping the Muses project. The View Art Now app allows all of our events on SDVAN to be located on a google map. PAMM makes visual the understanding of the mechanics of aesthetics and its interplay within Art, Culture & Science. When you read this article, I think you can see that the do's and don'ts can apply to much more that those founding a tech project.
Patricia Frischer
Since I started my firm Determinant Studios way back in 2014-15, I have been involved with different kinds of startup founders who have tried to give their all to their ideas, concepts and eventually their technological vision. This small write up is based on my experiences working with a lot of non-technical founders trying to build technological machinery in the digital world. This is just a pure assessment based on my experiences and enumerates the do’s and don’ts.
DO’s - Technology is a secondary tool, focus is first
Let me start with a couple of successful stories as we need the mood to be light before gobbling the bitter medicine. Sometime back, my firm was involved in building a small platform for a NGO whose target was to build a small web application which could accept donations for their cause. This NGO was very specific on what they wanted to do. The founder himself was a retired army personnel and had been funding the NGO from his own pocket for a few years. His sole idea was to bring an online presence for the NGO and make sure that the visibility is good enough for agencies which will be funding him. His work was predominantly in the field and his requirement wasn’t completely dependent on online donations. He worked to his strengths and slowly his online platform started generating revenues which helped him grow. The crux is that technology in this case is a secondary tool. Online donations and donation platforms are the present and the future. But the founder has to work to the strength and fundamentals of the business. The technology and upgrades to it need not drive home the advantages.
DO’s - Keep the UI simple and plan upgrades
Another one of our projects involved building a platform for a Fintech company which wanted to build a ‘Google’ of Wealth Management platform. Of course, ‘Google’ is not a Noun anymore which explains a lot. Google started with a simple search engine concept and grew to the enterprise we know of. A lot of non techie founders don’t realize how technology works and try to push in a short timeframe. Eventually, they have a product which is good but has a lot of holes. The maintenance of such a product keeps consuming time and money both and hurts in the long run. In today’s world, the UX/UI plays an important role in selling a product and increasing the customer base. Most founders I have met want their product to create a ‘WOW’. Sometimes, trying to achieve this Wow, turns out to be ‘wise of wreckland’ instead of ‘wise of wonderland’. A lot of this is because most founders think that doing simpler changes in the UI shouldn’t wreck the software and they keep asking for changes without following a process. The simplest approach to solve a problem is to break it down into small problems and solve one at a time. Similarly, a founder should always target a functional software with minimal working wireframes. This would ensure a good product plan and delivery. The product can be improved over iterations and with time
DO’s - Understand the process of building a software product
This must be the first lesson for someone who wants to get their hands dirty in creating a software product and coming from a ‘unsoftware’ background. It is really important to understand the process which will eventually lead to millions of lines of code and preferably dollars too. That said, there are hundreds of processes defined in the books for building a quality software product. The industry follows Agile methodology for a reason and that is what a founder should understand. Goals will be achieved only after understanding the process in a seamless way. In my experience, most founders have wanted results as soon as the developers started working on the product. One should realize that the Taj Mahal was built in 22 years and that is why it is a marvel we still cherish.
DO’s - Be involved in the process
A founder understands clearly what the eventual goal has to be. The vision and the clarity of thought is necessary to materialize an efficient and robust software product. A constant input channel to the dev team needs to be maintained to bring out the best. Most founders multitask in their day to day responsibilities. But their main focus should always be the product and the product itself until it reaches a stage where he is the last person to say ‘wow’. That pure dedication to the building process culminates into the results. Of course, I know that the founder has too many things on plate, but the product should always be the focus. I have worked with founders who have been focused more on other things than the product. Needless to say, the eventual product took a hit.
DON’T - ASSUME
The biggest menace I have experienced working with so many non techies is ASSUMPTIONS. It is important to understand that any action or change done to a pre-decided goal will always alter the timeline of delivery of work. Most bigger companies have a set process because they want to mitigate the risk of changes and alteration of deadlines. The process takes control of building the software and eventual delivery of the product. But in reality, when a new platform or software is built, the founder is too focused on creating the best product as the first version. In turn, a lot of changes are being done without any plan. This leads to a lot of technical debt inside the product code and eventually a low quality software. Ideally, even addition of a small horizontal line should be discussed with the dev team to avoid any impact on deadline or quality of the software.
DON’T - Undervalue or undercut your development team
With the current situation of WFH, it has become so easy for software developers to jump companies. If you think that this is a job bubble, then I think you are mistaken. Anyways, I am trying to refer to the problem of rising engineering costs and maintaining a good engineering team. It is important to keep the dev team in confidence and create a win-win situation in such a way that the ecosystem of mutual growth is realized. It is a harsh reality that a founder is always short on funds until an investor comes on board. Running the business until that time with keeping everyone in confidence is a huge challenge but it should never result at the expense of the dev team. A happy team can do wonders in the long run.
DON’T - Hire high cost supplementary work resources
A mistake I have seen many founders get into is to hire high cost personnel to get the job done in quick time. One should know that gastritis can happen from food in a food stall or from food in a five star hotel. It is all about the sanity of the body to digest the food. Sometimes we think that hiring a dev team with support staff might get us the product quickly and help us scale quickly. This notion is an invocation of ‘harakiri’ for a lean startup looking to build the product in the right way. Keeping the costs low has to be one of the most strategic decisions so that the firm survives the long run. Management has to be the onus of the founder and the founder should only identify and hire people who can support the venture in an economical and efficient way.
DON’T - Create WOW with just Design
It is important to understand the use-case of the product and realize the end customers of the product. Before Macintosh OS was released back in ‘84, the world was engineering and functional in it’s own way. Apple revolutionized the concept of user interface design and brought in a new spectrum of creativity in the field of software engineering. Every now and then you look at an iphone and appreciate the technological marvel and the ease of use it has. But little do we realize that the best of designers and billions of iterations and loads of time would have been required to achieve that feat. Most founders of startups are short on time and money and in today’s world both are precious.
DO’s - Technology is a secondary tool, focus is first
Let me start with a couple of successful stories as we need the mood to be light before gobbling the bitter medicine. Sometime back, my firm was involved in building a small platform for a NGO whose target was to build a small web application which could accept donations for their cause. This NGO was very specific on what they wanted to do. The founder himself was a retired army personnel and had been funding the NGO from his own pocket for a few years. His sole idea was to bring an online presence for the NGO and make sure that the visibility is good enough for agencies which will be funding him. His work was predominantly in the field and his requirement wasn’t completely dependent on online donations. He worked to his strengths and slowly his online platform started generating revenues which helped him grow. The crux is that technology in this case is a secondary tool. Online donations and donation platforms are the present and the future. But the founder has to work to the strength and fundamentals of the business. The technology and upgrades to it need not drive home the advantages.
DO’s - Keep the UI simple and plan upgrades
Another one of our projects involved building a platform for a Fintech company which wanted to build a ‘Google’ of Wealth Management platform. Of course, ‘Google’ is not a Noun anymore which explains a lot. Google started with a simple search engine concept and grew to the enterprise we know of. A lot of non techie founders don’t realize how technology works and try to push in a short timeframe. Eventually, they have a product which is good but has a lot of holes. The maintenance of such a product keeps consuming time and money both and hurts in the long run. In today’s world, the UX/UI plays an important role in selling a product and increasing the customer base. Most founders I have met want their product to create a ‘WOW’. Sometimes, trying to achieve this Wow, turns out to be ‘wise of wreckland’ instead of ‘wise of wonderland’. A lot of this is because most founders think that doing simpler changes in the UI shouldn’t wreck the software and they keep asking for changes without following a process. The simplest approach to solve a problem is to break it down into small problems and solve one at a time. Similarly, a founder should always target a functional software with minimal working wireframes. This would ensure a good product plan and delivery. The product can be improved over iterations and with time
DO’s - Understand the process of building a software product
This must be the first lesson for someone who wants to get their hands dirty in creating a software product and coming from a ‘unsoftware’ background. It is really important to understand the process which will eventually lead to millions of lines of code and preferably dollars too. That said, there are hundreds of processes defined in the books for building a quality software product. The industry follows Agile methodology for a reason and that is what a founder should understand. Goals will be achieved only after understanding the process in a seamless way. In my experience, most founders have wanted results as soon as the developers started working on the product. One should realize that the Taj Mahal was built in 22 years and that is why it is a marvel we still cherish.
DO’s - Be involved in the process
A founder understands clearly what the eventual goal has to be. The vision and the clarity of thought is necessary to materialize an efficient and robust software product. A constant input channel to the dev team needs to be maintained to bring out the best. Most founders multitask in their day to day responsibilities. But their main focus should always be the product and the product itself until it reaches a stage where he is the last person to say ‘wow’. That pure dedication to the building process culminates into the results. Of course, I know that the founder has too many things on plate, but the product should always be the focus. I have worked with founders who have been focused more on other things than the product. Needless to say, the eventual product took a hit.
DON’T - ASSUME
The biggest menace I have experienced working with so many non techies is ASSUMPTIONS. It is important to understand that any action or change done to a pre-decided goal will always alter the timeline of delivery of work. Most bigger companies have a set process because they want to mitigate the risk of changes and alteration of deadlines. The process takes control of building the software and eventual delivery of the product. But in reality, when a new platform or software is built, the founder is too focused on creating the best product as the first version. In turn, a lot of changes are being done without any plan. This leads to a lot of technical debt inside the product code and eventually a low quality software. Ideally, even addition of a small horizontal line should be discussed with the dev team to avoid any impact on deadline or quality of the software.
DON’T - Undervalue or undercut your development team
With the current situation of WFH, it has become so easy for software developers to jump companies. If you think that this is a job bubble, then I think you are mistaken. Anyways, I am trying to refer to the problem of rising engineering costs and maintaining a good engineering team. It is important to keep the dev team in confidence and create a win-win situation in such a way that the ecosystem of mutual growth is realized. It is a harsh reality that a founder is always short on funds until an investor comes on board. Running the business until that time with keeping everyone in confidence is a huge challenge but it should never result at the expense of the dev team. A happy team can do wonders in the long run.
DON’T - Hire high cost supplementary work resources
A mistake I have seen many founders get into is to hire high cost personnel to get the job done in quick time. One should know that gastritis can happen from food in a food stall or from food in a five star hotel. It is all about the sanity of the body to digest the food. Sometimes we think that hiring a dev team with support staff might get us the product quickly and help us scale quickly. This notion is an invocation of ‘harakiri’ for a lean startup looking to build the product in the right way. Keeping the costs low has to be one of the most strategic decisions so that the firm survives the long run. Management has to be the onus of the founder and the founder should only identify and hire people who can support the venture in an economical and efficient way.
DON’T - Create WOW with just Design
It is important to understand the use-case of the product and realize the end customers of the product. Before Macintosh OS was released back in ‘84, the world was engineering and functional in it’s own way. Apple revolutionized the concept of user interface design and brought in a new spectrum of creativity in the field of software engineering. Every now and then you look at an iphone and appreciate the technological marvel and the ease of use it has. But little do we realize that the best of designers and billions of iterations and loads of time would have been required to achieve that feat. Most founders of startups are short on time and money and in today’s world both are precious.
Image: Anu Cheeran |
I would like to compare building software with a piece of clay being molded into a beautiful pot. Every line of code needs care to build the perfect product. If you keep adding materials and keep changing the shape, it will result in something undesirable. The founder is the sculptor who is directing the show and needs to be careful at each step.
Happy founding and best wishes.
Anand Bora, Determinant Studios
No comments:
Post a Comment
Thank you for writing. We read every comment and review it.
Unfortunately, if your comment is anonymous it will not be made public.