Here at Nimi, we have our hands full on a bunch of initiatives.

 

For Nimi Core, we’re placing reliable and highly-skilled software engineers in high-growth FinTech companies. And on Nimi Grow, we’re still hiring our first cohort of interns to help grow and groom so they can learn to build innovative web and API products.

 

We haven’t talked too much about NimiX, and what we’re doing there. Today marks the first step toward revealing our long-term strategy on building software to improve R&D productivity.

 

It all starts with Echelon (echelon.nimi.tech) where in the first version, due to be in private beta in early February, we’re building the software that helps early-stage teams better allocate their capital.

 

By having a clear north star and long-term strategy, early leaders can plan their objectives, allocate resources and review the bottom line so they can bring their executive team and board along the journey.

 

Echelon has been a personal pet project for me, and the approach from day 1 was to bootstrap an entry level team of software engineers – Nimali and Rayan. Together with Achini, we have a small team of three, and the focus hasn’t been on velocity rather than learning.

 

Overall Achini, Karthik and I have been really proud of the progress and accomplishment of this team. They’re learning like crazy and honing their craft as they add useful functionality to the web application.

 

Avoiding Perfection

One of the first things I did with the team was to teach them to avoid perfection. I had asked the team to read Basecamp’s Book Shape Up. One of the chapters I had asked the team to pay close attention to was #11 (Get One Piece Done).

 

In summary, we really wanted the product to work functionally. We didn’t care about the product design or user interface. It was okay that we were using trial accounts to patch things together. We just wanted to get the flow to work so that we can test it.

 

This also helped us make the right decisions on priorities. Earlier on we needed a Gantt chart to present objectives in a highly interactive user interface. But with a single software engineer, we’d have to build this react component from scratch. And the estimate was 3 months.

 

That was too long to test an idea, so we opted to use an out-of-the-box component. It wasn’t perfect and didn’t fit our needs but was able to complete a part of the flow.

 

Adding Expertise

While we were able to get a lot of the major flows working with the database, we just didn’t have the expertise within this team to get the app working on our custom domain.

 

And we didn’t want to pull away any engineers from Nimi Core as we want them to dedicate their efforts to our FinTech clients they are supporting.

 

There’s only that much we could get with weekend favours.

 

In late December we had the opportunity to bring on a senior software engineer into the NimiX team and it was immediately apparent the value of adding senior talent in a team.

 

Within a few days, the senior engineer was able to move our ap to AWS, hosted on our custom domain nimi.tech and introduced mailgun into the services architecture so that email notifications were more real-time.

 

It was a reminder that when you have a team of newbies learning by themselves, they’re not getting the benefits of cross-pollination you get from having experts guide the newer team members.

 

Design Prototyping

Another benefit of having a more senior member on the team is that their skills are more fungible. He decided that there were so many gaps to fill and instead of letting them be, he rolled up his sleeves and got to work.

 

In our early days we had tried to start with polished UX prototypes but just didn’t have skills on the team. We opened up a role for a UI/UX engineer but were not satisfied with the quality of candidates we saw (we’re still hiring btw).

 

So we made do with lucid charts and hand drawings.

 

What resulted was an obvious outcome, that we would build interfaces that didn’t really match the requirements.

 

Achini and I knew this would happen, but at the time it was a worthy tradeoff. We decided it would give the team time and space to learn the technologies and frameworks required to build and test an enterprise web app.

 

And we would continue to build the rest of the business.

 

The senior engineer on the team Krish, decided that it wasn’t good enough. Overnight he became a Figma expert and was able to help visualise the interfaces users would expect from this app.

 

The result has been a real breath of fresh air for the entire team and our velocity seems to have multiplied.

 

Early Stage Building Product

Now we’re really on track to ship our v1 over the next few weeks. Based on our early usage we already have a backlog of features that we’re prioritising and making smart decisions around.

 

As I’ve been spending more than 80% of my career time these days revising my book and building the Nimi business it has been really fun to go back to building product. As an individual contributor product manager I was able to spend close to 90% of my time on pure building: design, requirements and software delivery.

 

In my current position there’s no way I can dedicate my time that way. As the pendulum shifts from priorities I have to invest the time when it shows up on my calendar.

 

It’s all bite-sized, but really high value when it happens. I actually think I’m forced to show up with a very high level of conviction and clarity when we discuss our demos.

 

It’s also really good to see senior engineers like Krish pick up the slack and help shift the culture of the team to be really collaborative.

 

–Dilip Ramachandran

CEO and Chief Product Therapist