Why Neeto is building so many products

Typically, companies work on one product and try to make that product a grand success. Only then will they venture into other products.

At Neeto, we are building 20+ products from the get-go. Why are we not following the path followed by other companies?

In 2020, BigBinary, for the first time, hired some students from the college as part of campus placement. We recruited 14 students. Before that, BigBinary had only hired experienced Ruby on Rails engineers.

We needed to teach HTML, CSS, JavaScript, React.js, and Ruby on Rails to these 14 freshers. We did introductory write-ups for these courses at BigBinary Academy.

Teaching people all these technologies was hard work, but we prevailed. We saw the result of our work: All these freshers performed very well.

Buoyed by the success of our campus recruitment, next year, we offered 60 students to join BigBinary. All these freshers took the same course materials published at BigBinary Academy.

A typical consulting company provides some basic training to freshers and then puts them on the client project at a lower rate. We wanted to avoid having freshers learn on the client project.

This meant that these freshers would have to work on some internal projects. We started discussing what dummy projects they should build.

After some deliberation, we decided that working on dummy projects doesn't bring seriousness. We wanted our freshers to work on real projects so that they fully understood how projects are executed in the real world. We should be using these projects in our day-to-day lives so that they can feel the pain of breaking something or the system being down.

We decided to build a product called NitroHelp. Later, NitroHelp was split into three products: NeetooChat, NeetoDesk, and NeetoKB. 9 freshers worked on NitroHelp, and we still had many more engineers who needed projects to work on.

At this time, we had to make a call: Should we add more products or more engineers to a single product?

If we add more engineers to a product, they all will need features to work on. We would have to hire many product managers quickly to create the tickets and build the pipeline of the features they would work on. We would also have to employ many UX folks rapidly to work with these product managers to create the interfaces.

BigBinary is a consulting company. Our goal was to hire students from the colleges and teach them programming so that they could do an excellent job with consulting. We didn't want to have many product managers and UX folks, and this helped us decide to build many different products.

And that's what we did. We decided to build NeetoCal, NeetoQuiz, NeetoWireframe, NeetoPlanner, NeetoCI, NeetoDeploy, NeetoSocial, and many more. We decided to put two engineers in each product. Having only two engineers in each product helped reduce the communication overhead.

Another decision was that the engineers working on the products would act as product managers. They would examine the competing products and build the core of the products.

We did hire three UX engineers to support all the development work.

At the end of the whole process, we had close to 20 products.

As we started working on these products, we realized that almost all of them needed some basic standard stuff. For example, tables, sidebars, filters, column info, settings, etc., are required by all of them. We wrapped all these UI elements under the NeetoUI library.

Then we noticed that almost all products need "Slack integration," "Stripe integration," "webhooks," etc. Rather than duplicating the code, we started extracting the common elements as a standard utility tool. We started calling them "nanos." We have written a detailed blog on how we use nanos.

Initially, we were worried that without a product manager, how would we build all these products? Who would decide which feature to create and which to ignore? Building a feature means making many small choices. We empowered our engineers to make all those decisions.

In this work style, the engineers work on everything from requirement gathering to wireframing to development to testing and finally to deployment. However, the engineers' work doesn't end there. They still need to write helpful articles about the features, tweet about the newly launched feature, and write a blog about it. If the customer contacts them, they also need to provide customer support.

The best part of building products at Neeto was that the engineers were involved in every aspect of the product, from the very beginning to customer support. And this is precisely what we wanted. We wanted these freshers to get a feel for building a genuine product, and they built real products used by people worldwide.

Building 20+ products in parallel is quite a challenge. Sometimes, it is overwhelming, but it's also fun.