Today, Acies is also a full-fledged product development firm with an internally funded VC program that helps other non-tech founders launch their product startups using their proprietary no-code solution.
Impressive right? We thought so too. In a chat with Team ProdWrks, Muzammil Patel, the co-founder and head of strategy, finance, and operations at Acies, gives us insights into how he cracked the glass ceiling of building and scaling a tech product company as a non-tech founder.
Insight #1: It all starts with founder-market fit
All founding members of Acies have decades of experience in the BFSI sector, and have worked together for many years in the Big Four firms where they advised large corporations. Muzammil, for instance, has 10 years experience working with Ernst and Young and five years with Deloitte before starting Acies.
Insight #2: The hardest part of building a tech company
As we all know product development is no cakewalk and when people think of tech products, they think that the hardest part is coding. But, it is actually not.
Some of the biggest challenges when you startup are “identifying what is good tech, what fits your scenario, making it scalable, and architecting it right.” According to Muzammil, this is hard to get right because “picking a tech stack that is number one today may not always be the right choice for you.”
Muzammil says that the right way to do this is by first having a clear roadmap for your product.
“Selecting a tech architecture depends on how you want to build your vision and your roadmap. You can spend days or months evaluating tech, and then the final decision is a snap if you have your product roadmap clear.”
Insight #3: The second hardest part of building a tech company
For Muzammil, the challenge was to switch from a consulting mindset to a product mindset. This is true for most first-time product founders who come from different non-technical backgrounds.
Contrary to what people think, a lack of technical knowledge is not the only challenge faced by non-tech founders starting a product company. The hard part is to find the switch to make decisions from a product mindset.
Insight #4: Think twice before hiring a CTO
There are typically two approaches that non-tech product founders take to build tech products. The first approach is to either onboard a CTO as a co-founder or hire an internal technical resource. The second approach is to outsource product development to an external product development firm.
The reason behind the decision was a fairly simple one for Muzammil. It’s because he wanted everyone Acies hired to be first strong in the BFSI domain “with the expectation that they’ll be hands-on and learn the tech needed to solve their purpose.”
Insight #5: Bootstrapping
This is where the domain expertise of the founders in the BFSI sector came in handy. The founders of Acies did not jump into products headfirst and did not expect a return on investments immediately. They decided to wet their feet first with their consulting business by capitalizing on their domain expertise.
Their efforts paid off months later when they got their first client who signed up exclusively to buy their product exclusively and not their consultation service. Today, their efforts are validated as there are about 14 large insurance firms that use the first product that Acies developed – an interest rate derivative lifecycle management system that today processes over $8 billion worth of derivatives!
The key takeaway for product founders here is ‘delayed gratification’ and how Acies effectively used free cash flow from consulting and put it all into product development, taking feedback and improving it by applying real-world use cases to develop a successful product. This again is a result of having strong domain expertise and a great founder-market fit.
Insight #6: MVPs don't work in BFSI
From not hiring a CTO or a tech team to bootstrapping product development, we saw that Acies is no stranger to bucking trends and taking the road less traveled. In a similar vein, another key decision they took early on was to NOT take the MVP route to product development.
Though the risks of failure is high in this approach where you may have to trash a product if it doesn’t work, so are the rewards as the organizations that Acies deals with, “scale quickly” and bring higher revenue in a shorter span.
Insight #7: Minimize risk with no-code development
But Muzammil and his team at Acies figured out a way to minimize this risk of failure by being one of the early adopters of no-code product development in the BFSI sector. This led to the birth of their no-code product builder, Revolutio, which Acies now also offers as a SaaS solution.
Insight #8: No-Code in B2B - A bet for the future
Muzammil believes that the next spurt of growth in no-code adoption will be led by B2B businesses rather than in the B2C space.
Muzammil predicts that while B2C will continue to adopt and innovate in no-code product development, a lot of these innovations will transpose down to the B2B sector. And due to the phasing out of legacy systems in B2B space, “from a scale perspective, adoption on the B2B side will be much quicker and much larger till it becomes the standard across the industry.”
The Acies Ventures-Revolutio Program
Having walked the hard miles as non-tech founders in the tech domain, the founders of Acies have now decided to help other non-tech founders by offering funding and strategical and technical assistance through their Ventures-Revolutio program.
Muzammil says, “The participants so far in the Ventures program have all been in the format of JVs, where we invest into the JV, provide the platform, hand-hold them through the entire product development to market process.”
Key Takeaway: Stop Fearing Tech
Muzammil says that the most important thing for product founders is to learn the tech, understand the tech, and don’t rely entirely on a third party to build your tech.
He says, “Don’t rely on only your CTO or one of the co-founders to do it. It’s very easy for most of us to kind of get overwhelmed with the quantum of information and uncertainty that comes with having too many technology options. But I think that’s the fear you should overcome first.”