Figuring out product development
Tags: startup, management, productivity, sideprojects
Published: 2020-05-02 09:04:54

![](https://cdn-images-1.medium.com/max/2000/1*C0ASzGUy1P-Mx1qjBJW3Jg.png)

A product is a result of an old saying — **necessity is the mother of invention**. I have been working on a product called [NotesHub — A study material sharing platform](https://noteshub.co.in/) and still, there are things which leave me perplexed.

I have been developing NotesHub, along with my team from the last 3 years and have been working in a service-based company for the last 1 year. There are a lot of revelations that came forward during my ~4 years of product development. I have worked with custom-designed products and have also worked with a black and white bare minimum designed product. The following are some of the lessons I learned along the way:

## 1. Functional > Aesthetics

![*Sneek-peek to the new platform*](https://cdn-images-1.medium.com/max/2560/1*uLV_146Egbe7fZ9U6AVQZQ.png)

When starting out with an idea, try to get version 1 of the product out as soon as possible. Do not fuss about the colors, design or visual beauty of the product. Yes, the design does play an important role but it is not something because of which you hold the product launch.

What I am trying to convey here is, go for minimal but functional design rather than aesthetic design. The functional design is the correct placement of a button and a filter while the aesthetic design is the color of the button and the other button styling elements.

Going forward with “red” color for danger and “green” for success will serve your purpose for version 1. To be honest, that is all of the design you’ll ever need for phase 1 launch.

***

## 2. Freeze requirements

![*Credits: [http://johnbellart.com/](http://johnbellart.com/)*](https://cdn-images-1.medium.com/max/2000/1*NChSSlMO75xpgkn9prdrpQ.jpeg)

There are instances when as a product developer/founder you’ll be urged to add **1 MORE FEATURE** to the product which will guarantee success (at least that’s what you think). It is a bad idea to keep iterating over the feature list.

Differentiate between **MUST-HAVE** and **GOOD-TO-HAVE **features and stop right there. The best way to differentiate between the two is to ask yourself this question:
>  *If I remove this feature, will the product be able to do what it’s main motive is?*

If the answer to the above question is a resounding “YES”, then that is a GOOD-TO-HAVE feature.

For example, version 1 for a product like Uber/Ola (basically a cab-hailing app), the provision for rating drivers is a GOOD-TO-HAVE feature, but booking a taxi is a MUST-HAVE because the latter will complete the very purpose of the application.

Freezing the requirements also helps you and your team to visualize the finish line, else everything is a mirage!

While developing [NotesHub](https://noteshub.co.in/), we added one additional filter. We froze the requirement per-module basis. We finished that particular module (to never touch it again before release) and then moved to the next freeze requirements for the next module. This helped us to not have 2-hour meetings where we just talk/discuss and try to make guesses about the timelines, usually drifting away from the very topic.

We reduced the meeting time to 30 min, wrote down all the requirements of 1 module and started working on it. Only after we finished the development of the module and unit tested the same, we started with the next. This helped us to finish the product within 3 weeks (and we were procrastinating for a year).

***

## 3. Team

One cannot finish the product without the right people working in the right roles. First and the foremost thing is communication. The majority of the delays in a product development cycle are caused by poor communication. Communication plays an even more crucial role when the entire team is working remotely. Things get fucked up pretty fast if you are unable to solve the communication problem. Be it missed requirements or confusion in understanding it, it will hamper work.

The real challenge is when you are trying to push the product out of the gates as soon as possible because then the development team works round the clock with interdependency. Thanks to [David Heinemeier Hansson](https://twitter.com/dhh) and [Jason Fried](https://twitter.com/jasonfried) for making a product like [Basecamp](https://basecamp.com/) and making it [free](https://m.signalvnoise.com/launch-basecamp-gets-personal/).

We tried [Trello](https://trello.com/en) like project management tools but couldn’t get results. I was personally on [JIRA](https://www.atlassian.com/software/jira?) for quite some time but we are way too small to use a product like that. So Basecamp became free just when we needed it the most.

![](https://cdn-images-1.medium.com/max/2000/1*DxPrBR4RpdxBAiLK22EDPQ.jpeg)

We are developing NotesHub — A study material sharing platform for India while we are working full-time jobs. Now that is a big N0-NO in the startup world but to be honest, not every product needs to have your full day throughout the year. Yes, I agree that we could have finished the product sooner, but we are okay with the way things folded.

All you need is a dedicated team that is self-motivated and managed and understand the true potential of the product for which they are sacrificing their weekends.  

***

## 4. Still figuring it out . . .

I am still figuring out the entire process. There are no guides or 10 steps/commandments to make a successful product. This is me just sharing my and my team’s findings as we are developing India’s study material sharing platform — [NotesHub](https://noteshub.co.in/).

***

Originally published at [adityatyagi.com](https://adityatyagi.com/)