Have you ever worked on a product that never seemed ready to launch?
I'm talking about the trap of "perfect over progress." This refers to a product that has been downscoped, MVP tightened, and product delivery lifecycle defined but continues to miss delivery milestones.
There's always one new feature "we need to implement" before going live that keeps delaying the general availability (GA) date.
We encountered a similar scenario with our product, Nimi Kash.
Now that I had spent several months Taking back Control of my Company, I felt confident enough about the core business to scale it safely.
As I was writing this article, I started collating information about the most common ways product leaders trip over themselves when trying to launch a product. It was a well-written and comprehensive piece.
But god, it was boring to read. It was full of generic advice, hypothetical problems, and a "toolkit" for finding creative solutions. It made me feel good as a writer, but it was just useless.
It would be more helpful to share a specific circumstantial situation.
As any good product leader, I joined the Nimi Kash team's daily standups.
It turned out to be a waste of time.
As CEO of the company, the team's threat level was max. So, they were on their best behavior and ensured that each standup and communication focused only on the positive.
Assuming I could build trust within the team reasonably quickly about the shared goals of getting the product live, waiting for insights to deliver themselves from the standups would take several weeks.
I wanted quicker results, so I put my attention elsewhere, into the dozens of pages of detailed requirements written by the product and design team.
Nimi Kash is a payroll platform that pays remote workers how they want to get paid. As payroll is a critical function of any organization, it is easy for such products to touch a broad range of personas.
Reading the thorough documentation, I realized that as the team was defining the MVP for this product, the scope slowly crept to include a growing list of personas.
The immediate conclusion was that I needed to short-circuit the product development process. Here's a look at five short-circuits that got Nimi Kash back on track.
Based on my direction, persona #5 was added later to the MVP list. I hypothesized that Abundance would attract users who wanted to improve their financial health. The free financial product comparison tools would attract users to the platform and ask their employers to pay them through Nimi Kash.
Abundance would be a powerful source of leads for the Enterprise product. Since it was a simple web application, I assumed it was something the team could deliver reasonably quickly.
But, when I looked at the sprint data in JIRA, I found that Abundance's defect ratio was surprisingly large. The team dedicated over half of the story points of each sprint to fixing bugs incurred in the previous sprint. And when I looked at the trend, it was getting worse with time.
The burden of building Abundance was delaying the production release of Nimi Kash while delivering hurting quality and speed.
I had to pull the plug.
Descoping Abundance team visibly energized the team.
Why didn't they give me this feedback before?
As leaders, we challenge our teams by raising the bar. I often need to find the threshold where the group meets diminishing returns and starts to feel pain. In a healthy organization, "pain receptors" fire and help recalibrate.
In outlier scenarios, when the CEO is the Product Manager, these "pain receptors" fail to fire.
We needed to cut more.
Looking back at the list of personas, we could cut more to focus on the efforts of the first product launch.
The immediate action was to descope #1 and #2 (Nimi Super Admin and Employer Super Admin). While it would be ideal to have the Employer customer or a Nimi account manager proxy for the customer, given the sales volume for our first year, I felt confident that we could do these operations manually in the backend when onboarding a new Employer customer.
Additionally, on the Contractor side, we had sufficient data that most prospective users in Sri Lanka have an Android device, and it would be good enough to support a single onboarding mechanism.
Early estimations suggested that I could cut the body of work by as much as 50% by making this change.
I was ecstatic that we could go live with the MVP for Nimi Kash as fast as 45 days.
Despite being energized at first, the more I cut from the scope, the greater the anxiety grew within the team.
They felt that the scope reduction would create significant gaps, resulting in operational overhead and making Nimi Kash unusable.
Intuitively, the warning was reasonable but not absolute. We had no way of confirming the true MVP of the product. Yes, we'd spoken to many prospective customers and cobbled together the roadmap from countless notes - a task our product managers did not take lightly.
I wanted to try a novel approach. Since we were planning on dogfooding Nimi Kash ourselves, why not also dogfood onboarding?
Hishani Perera is the Talent and Human Resource Executive at Nimi. If there's anyone whose life gets significantly better post-Nimi Kash, it's Hishani. She's also not a seasoned product manager with a litany of best practices, constantly lecturing the engineering team (like myself).
Instead, she is an average internet user and, most importantly, the target persona for the product. Why haven't we made Hishani the primary persona to drive the product direction?
We included her in our daily standups, and I drafted a customer onboarding plan that she would beta test for Nimi Kash.
It was late Wednesday evening, and I blocked my calendar for the next three days. I started with a half-page Word document that listed all the things Hishani would need to do to operate payroll with Nimi Kash. At a high level, the document covered these steps:
This document gave me (and the team) a lot of clarity about what features were essential to build and what were not. Anything that made our (Nimi) life easier was on the chopping block, especially if there was a good enough solution we could cobble together with off-the-shelf tools.
A great example was customer billing. The product team had debated and researched this heavily and landed on a slick recurring billing solution built on Stripe. I looked at it and determined that QuickBooks Invoicing would be good enough. With a handful of customers, our volume was low enough that we could get away with manual work.
Another example was the HRIS integration project. The product team had recommended that we build a one-click experience to import all current employers and salary data. We could reduce the implementation time by over 80% through aggregator tools.
That said, developing an Excel template and having someone on the team map it to their HRIS data export CSV was incredibly trivial.
So, we opted for these two changes, including several other creative solutions.
Over the weekend, I rewrote the MVP in a single confluence page and created a list of jobs that different personas had to do. These jobs were the development tasks we had to complete to achieve MVP status.
Not only did this give the team clarity, but it also gave them the confidence that we would be able to achieve a go-live date 30 days into the future - beating our previous 45-day estimate.
When I founded Nimi, we created three divisions in the business. One of the divisions was called Nimi X. This was our accelerator, where we put interns and new hires to work on consumer and enterprise products. We aimed to train our team with the latest technologies and teach them product thinking.
As the company matured, these products had a life of their own, and team members advocated to test them on the market.
I reserve Nimi's sales and marketing resources for the Nimi Core business, where we bring product ideas to life through mobile and web applications through staff augmentation and fixed-bid product delivery.
But I heard the team loud and clear. At the 2023 Shark Tank Event, the Nimi X teams competed fervently to make Nimi Kash the winning product - with the best business model and product-market fit for the Sri Lankan IT ecosystem.
As promised, I reallocated all the engineers from various NimiX initiatives solely to Nimi Kash to streamline our operations.
The intention was to provide fuel for the team so they could deliver more products faster.
In reality, we consolidated too fast.
With the first three short-circuits in place (product scope, personas, customer onboarding MVP), we needed more team members.
It also surfaced a clear leadership bottleneck in engineering. The engineering manager could not review PRs fast enough, and the burden of training and directing junior engineers debilitated him.
The diagnosis of this symptom was the "requirements were not clear enough," causing us to invest more in building out the product team and making requirements more detailed.
However, this added to the development overhead, creating busy work for the engineers rather than optimizing for efficiency.
In essence, we had a team of engineers running into each other, some with insufficient work to do, a lack of understanding of the product requirements, and a leader who was so deep in the nitty gritty lost sight of the primary goal of the product.
There was no choice but to make changes to the team. Here's what we did.
Finally, we created goals for each engineer that tied to the product's success.
When engineers have goals tied to specific components of the product working, we can align their efforts to a completion target.
This was certainly better than we had before (number of tickets closed), but it created a mercenary attitude within the organization.
Specifically, things like this are said, "Hey, dev, I made the backend return the right response, and it works perfectly; the app broke because your Android code is buggy."
Off the bat, I wanted goals based on something other than ticket completion speed, outstanding ticket volumes, or even % completion of modules and features.
Instead, the only goal was, "Does the damn thing work?"
How do you measure this?
The answer was simple, and it is raising the visibility of the QA engineering team. They're doing tests weekly of individual components, but it only matters if all the modules work together to create an experience for the end user - our HR manager, Hishani.
In partnership with the QA engineer, I wrote a test plan of everything that must work for us to be considered "done." She would perform the test, record it as a Loom video, and share it with the team every Friday.
The first few weeks were rough because she had little to show, and the team absorbed this frustration. We were working on the backend in the early weeks, and that's typically hard to demo in a video.
But as the front end came to life, the end-to-end testing became the heartbeat of the Nimi Kash product. These videos did so much for the team:
On schedule, within 30 days, we launched Nimi Kash to the market and were able to elaborate on the product based on feedback.
As you think about a product you have in the queue that just isn't able to get on the shelf, here are some symptoms to watch out for that might warrant your effort to consider short-circuiting your process:
See at least one or more of those symptoms? You have some work to do.
Are you looking to pay your remote workers through a reliable, affordable platform that helps them get paid how they want to?
Look no further than Nimi Kash.
.svg)
Dilip Ramachandran has over 15+ years of building teams, shipping delightful and highly successful enterprise software products in MarTech and FinTech at companies like Walmart, Experian, Marqeta and Bond.
Dilip wrote Gangsta Vision to help folks in product management to figure out their path and a plan to break into senior leadership.
At Nimi, Dilip is CEO and Chief Product Therapist helping high-growth FinTech startups with product and payments advisory and matching them with highly reliable and skilled experts in Sri Lanka. Learn more about Nimi at www.nimidev.com
Dilip has a Bachelor’s in Electrical Engineering from the University of Pennsylvania and resides in Oakland, California with his partner Alla, daughter Ariadna and son Wiley (a papillon-sheltie rescue). The family occasionally travels to Colombo, Sri Lanka for his work with Nimi.