Every services company website has at least one product listed that claims to be a world changing product. Nothing wrong with the vision or intent. Just that we don’t hear that product anywhere else after we are done visiting their website. Why does this happen?
It must surprise us that even market leaders of a specific services segment fail to build a successful product in the category. All of them try though. They think they have an IP and that IP has a value to it. There is only a notional value. The true value of such products is a big zero.
As a part of my ground work to publish this piece, I visited many services companies website and made a list of the products they claim is world changing and went to social media to find who is really talking about it. None. In most cases, their own social media accounts fail to talk about it. I thought I will feature a few of those products and share deeper insights about why they failed or certainly will if they are just born.
Why point fingers at others when my own house has enough stories worth sharing. Here is my list of failures and the analysis of it. I am publishing this to help anyone building products by not taking the path we took. Also, sharing how we recovered, pivoted and finally building a product that is clicking.
Moolya’s list of visionary products (and failures)
If you don’t know Moolya, the shortest intro I can give you is, our customers over a decade think our approach to testing is deep and we put together best of the teams for QA and SDET requirements. Our customers are deep tech startups and startup culture like fast growing medium to large scale enterprises. No company with red tape works with us. We reject them upfront or they reject us.
Our approach to testing uses a combination of context driven testing, rapid software testing and automation principles from the likes of Google where we strongly advocate our customers on culture, unit testing and prevention of bugs.
Moolya’s Brainual Testing Tool (MBT) : Born 2014 : Died 2105
We had bootstrapped our company to a million dollars in revenue, profitable year or year growth by 2014 (having started in 2010). Our approach to testing had helped several startups grow rapidly, raise ten to hundred million dollars and help us grow. We thought we could translate the linear growth we were having to non linear with a product.
That’s how MBT was born. MBT had to be built to help Moolya and non Moolya testers do expert style deep and critical thinking testing. To report a bug into the tool, a QA Tester had to report the Heuristic, Oracle, Risk and Impact. This was too much to ask from people who would just want to write a Summary and Description. If that wasn’t a problem – before they started testing – they had to provide plenty of contextual details and in the their mind, this was a blocker.
Even people within Moolya rejected it. It was a huge behavior change. Initially those who felt obligated used it but eventually the metrics and usage dropped. When asked why, they’d tell a list of features missing and like most failed product stories we end up building it but people always got back to some other features missing as the reason why they can’t use it. After burning a lot of money and time, we decided that we will shut it down because there was no light and the tunnel kept getting darker.
Social Media Driven Testing Tool : Born 2015 : Died 2015
I had given a talk on Twitter Driven Exploratory Testing at Oredev Developers Conference in Malmo, Sweden in 2014-2015. It had some insights on how QA Testers can use information coming from tweets about their product and diff to their internal test coverage. The talk and the concept got quite a good response from an expert dev and test audience.
It is indeed a very exciting concept even today. On similar lines, Anand Bagmar has discussed about anlaytics driven testing. Social media driven or analytics driven are very useful concepts. We don’t see a real life implementation of it yet in a tool format that everyone can use. There are good teams who do it as a part of their everyday cadence.
We partnered with Gnip to get a Twitter Feed Pipe that helps us query and retrieve large streams of tweets. Front end of Twitter is a bad idea for Search and Results. GNIP was doing this as a service and we built a layer of analysis on top of this. The tech complexity was huge and we roped in Data and A.I. companies as partners in helping us build it. Bringing in experts means the cost is proportionally higher. A full fledged prototype would cost us 3x our budget and since we were bootstrapped maintaining the cash was more important to us than anything else. We decided to not go ahead and spend that money into what was bringing us money – services.
Startup Test Lab : Born 2016 – Died 2017
One of our IP was our tests and checklists. We had tested plenty of apps and we knew the list of common bugs and we had converted Apple and Google’s UI and App Store Compliance into Checklists and Tests.
We were super helpful to our customers because we would give them a holistic view of their app quality by following our checklists and heuristics. However, our customers had secured a Series A or so. A lot of pre Series A stage start ups really struggle with testing because the Product Owners and Developers test on their own without any help from QA. Now, that is good. I love to see it happen. However, they have no clue of test coverage and also they want to iterate faster to get to a Product Market fit. They also don’t write unit tests so bugs are flying everywhere. We thought we could help them by making our checklist into a product.
The one good thing that happened, we built a very robust single place for our own internal test teams. However, as a Product this had to be marketed. Super early stage startups are all looking to use free products. We did get a few customers to our services business because they were like, “Good that you have this checklist – can we hire your teams to run it”. Fine but we wanted to sell you the product. Not our service. There is a lot of churn with very early stage startups as customers. So, the math didn’t work out either.
This product would work even today if we are okay to not make money from it the first few years. Product is a long game. Services is a today’s game. We see money month on month in Services. Product needs a long term vision than Services. This died a painful death because our teams poured a lot of passion into this.
Bot Driven Test & Automation Platform : Born 2016 : Died 2019
By now, we had become smarter. We knew that product was a long game and to be able fuel long term game we need to raise funds. We did raise about 350K USD seed from Friends and Families who were true angels. The idea was to raise a Pre-Series A immediately. We got a 500K USD Term Sheet from a VC to participate in the Seed. This VC would then bring other VC’s to do our Series A. All looked great till the point our co-founder chickened out. The VC broke our term sheet contract because we had to settle things with the parting co-founder.
The product was the best we had built so far because we overcame plenty of mistakes from our past. We had the funding and we didn’t settle for any low quality alternates to doing things. We scrapped our front end design 3 times to get the right one for our customers. Our campaigns went well and bagged a few paid customers. We had built a super engine that could run 100K bot tests per day. With A.I. the tests would become more useful and powerful. That’s what test.ai and sofy.ai is doing today. They started around the same time as us but raised VC money and went ahead to do a great job.
Having lost the 500K Term Sheet, we were on the lookout of money and that’s when we hit a jackpot. We had a customer interested to fund us to accelerate our roadmap. They offered us 300K USD with one condition – they needed a perpetual license + a copy of any IP they contributed to. We agreed and this kept us going for another year.
Our early stage customers were small to medium businesses. At the end of the accelerated co-building this product with our customer, we had built an enterprise product that was difficult to sell as SaaS. It also required a huge infra which we were not motivated to build. To do that we needed at least 2 M USD of Pre-Series A Funding. We got large enterprises like SAP and Zebra Tech interested at getting an enterprise license of our product but we had to integrate with their systems. Building for enterprises is a different ball game. A lot of customization work. Yes, they were willing to pay for it.
With enterprise customers comes a lot of heavy maintenance of the code. This is not what we wanted to do. Also, it requires a lot of different thought process from what we had and we could not align to it. So, my partner, Avinash and I decided that we will pull the plug on the elephant we had built.
Performance Monitoring Tool : Born 2019 : Died 2020
We had gained tremendous insights into performance profiling of mobile apps and one of our colleague wanted to pursue building a tool around it for developers. Not QA or SDET’s. A proper dev tool. My partner and I decided to just play an investor role in it. We got a Google Developer Evangelist to consult for us and our colleague did a great job to interview users, understand pain point and build the product to get a few early beta users.
We needed the marketing and growth machinery and we didn’t have it. We supported our colleague to hire those folks but it is one thing to be able to build a product and another to be able to find a co-founder to be a part of the vision. Our colleague couldn’t onboard a growth specialist and it fell on our heads to sell. We even got an enterprise customer for it but there was a context change from the customer side and things went south. We lost the motivation to continue to fund it and pulled the plug.
Analysis of failures
With hindsight wisdom, we are all experts. When things are happening, we are not. Like that, I would like to bring hindsight wisdom and another type of wisdom called – being conscious.
#1 Founder market fit is misunderstood
A founder building a product in a market they are unaware of is a bad thing unless they are Elon Musk. This looks fairly obvious. The founder maybe be a category expert within a market but not the market itself. When founders extrapolate their category expertise to market expertise, they end up building products that they should not be building. Some of the above products we built just did not suit the founders one bit.
Although every product we built was under the gamut of testing – there were so many things within testing that needs its own depth of understanding. Regression Testing is a multi billion dollar industry. Building a product for managing regression for web versus mobile are two different markets. We repeatedly failed to understand this.
#2 Services = Inbound Success | Product = Marketing Success
Product is a marketing game. Services is an in-bound game. Most successful founders and services business that are small to medium heavily depend on inbound as their lead gen channel. Outbound does not yield big business growth at early stages of a services company.
In Moolya, even today, after a decade of our existence, we have 90% of our leads inbound. For product success, it is SEO, Adwords, content, community building, and cold emails and drip campaigns that make a difference. Although services companies do require this but this ain’t that much a blocker. So, founders and leadership teams get busy with fulfilment and delivery.
Most services companies like us fail to make the switch from right brain thinking to left brain thinking when required because our muscle memory takes over.
#3 The kind of products we should not build from India
The early stage Indian Venture Capital is not like the Bay Area ones. We founders fail to get that. Unless we have failed enough. When we had some early traction going with our Bot Driven Testing and Automation Platform we could not raise VC money whereas our counterparts in the US who had similar background like me and my co-founder got seed and pre-Series A checks prior to traction.
I am not complaining but helping my fellow founders understand this. If you plant a cactus in a place the cactus won’t grow – the fault is not with the cactus. A good farmer knows which crop to focus on for the upcoming season. Like that, most Indian founders, services background or not continue to make the mistake with the kind of product they are building from India.
First time founders with visionary products don’t attract VC Money
India is, “show me your sales numbers” market – when it comes to attracting Venture Capital for first time founders. Yes, VC’s do pick smart founders and most of their definition of smart is – have you been selling?
Our bot driven platform was selected to be a part of NASSCOM Deep Tech Club Cohort and I know many deep tech products that would have been funded in the US but aren’t funded in India purely because they haven’t shown sales numbers yet. It takes money to build deep tech. The VC’s in the US are aware of this.
A CRM that sells is better than A.I. Driven Camera System when it comes to raising capital in India. Proven market. Indian VC’s love proven markets when it comes to B2B. There are outliers, both in Indian VC’s and Founders. I am just your average Bill Joe.
Products without strong marketing will waste a CTO’s time
Marketing machinery needs to be from day 0. Founders are Marketers and Sales People. The team builds the product. Most of the founders don’t get this. They become too involved with the product just like how I did that blocks anyone from looking into marketing and sales. We do it but as part time. We are worried about the product because for us our product is us. Actually, marketing should be us. There are bad products marketed well that succeed and good products marketed bad that don’t succeed.
As a bottom line, Product Success = Marketing Success + Strong Customer Obsession + Tech Success. My CTO kept saying about our gaps and I thought we were doing it and can do better but never felt it as a gap. Acknowledging Marketing as our gap would have propelled us better.
A top Indian VC Partner told me, “Pradeep, I love your passion and the background but you lack a team member in your team”. I thought he was saying it to say No but he truly meant it. What we notice in the US start-ups is they are very good at bringing in Marketing at an early stage. Their website, UX and First Time User Experience is as good as Cred.
#4 Services Success = Saying More Yes | Products Success = Saying More No
Teams solve problems. Founders don’t. Product or Services, it is the same story. Founders at best play facilitator role. Not the problem solver role. Since it is teams that solve problems, Services is a team building game. If we know to hire good people, have a culture that helps them solve problems without friction, we are done. The team put together will solve problems for customers. So, in Services, it is about saying more Yes (and fulfilling it) that helps the company succeed.
In Products, a variety of customers want a variety of things. Only a good P.O. knows to say Yes to the right thing and No to most things. Founders as early stage P.O.’s with a Services background will end up saying more Yes like what I did and screw up the Product.
#5 Opensource till you find a Product Market fit
With the pressure of revenue from the product to raise capital, most founders start monetization early and that kills the product. With monetization comes support and busy bug fixing times and takes time away from being able to learn a deeper problem context that can being ton of wealth creation.
What Cred might be doing now is purely learning. Bring as many people on board and learn from their spends. If you are not Cred – make your product opensource or free till you find the product market fit. Hasura.io is one such example that began with opensource and it certainly has a bright future because adoption became easier to plenty of CTO’s who love the idea of sustenance.
How we applied our lessons learnt?
Growth team + build team = product success
The acceptance of failure and the enlightenment that followed led me to believe that my partner Avinash and his team is better to lead the product. My job as a CEO though is to raise funds and support him and the team to succeed in fixing the gaps.
Ever since this switch happened, the team has been doing great. We gave two focus areas for the teams. One focus on growth hacks and then another focus on building the backend (the product). We have two sprints that run in parallel. Every feature has a growth hack team deliverables + feature deliverables. Just a feature going out without the growth hack is useless.
Better founder market fit product
We are building a bug tracker. Our services business lives and thrives on using bug trackers. Jira and Zoho are giants in this space but they are two decades old product. We felt there is a need for a modern bug tracker for this world. We could be the right fit to build it because we have been using Jira for two decades and we have plenty of opportunities with our existing and new customer base to help them with a modern bug tracker.
We ran a question in Hacker News on what is missing with existing bug trackers and found a good set of people resonating our thoughts that there is a need for better modern bug tracker.
Marketing and growth team building
We are Engineers and that overtakes a lot of what we do. Content as you have been reading this piece has been our side hustle and we have done reasonably well. All we need to do
Simplicity as our Moat
When we polled people who hangout in Hacker News, people who built Git Issues, there were patterns that emerged on what is missing. People needed speed and simplicity. Jira is a 100 pound gorilla to do a job of a small mouse. There is no better moat in this world than simplicity. Enough products in this world have taught us that. We want to focus on simplicity. Even if our product looks like it has less features, in long term, this will win better.
Saying No as a team culture.
We had an enterprise customer interested for about 35 licenses. They had used our trial version and found plenty of reasons why they need Bugasura and a few things that blocked them. While we want to do better than Jira in Bug Tracking, our Reporter has the capability to sync issues to Jira so someone can use our reporter and Jira as a bug tracker. For instance, they had 100+ Jira projects. We had anticipated 20 as max one could have. They wanted this limitation to be removed as a pre-condition to their payment.
We worked to a point to onboard them but then they came up with another one and another one. We told them if they are going to continue to ask us to build things without paying us we would be forced to say a No. We did say a No and put the ball in their court to use the product as is and we are happy to include things blocking our customers in our roadmap.
Most exciting thing about this episode is the “No” actually came from our team, first. We as leaders then reciprocated it.
Funding the long run of product with our services growth
We built a strong growth machinery in our services. We add new customers month on month. Our growth rate is the highest among bootstrapped services companies. This is helping us fund the growth and marketing needs for our product as well.
Also, many of the customers we onboard who have a free choice to choose a bug tracker are on Bugasura.io and it is packaged into our services as well. That way, we are spreading our wings. Internally we have a good adoption of our product.
Being aware that we are not yet Venture Capital friendly has given us a lot of clarity to focus on how to fuel our growth.
Paid Customers and Virality
A paid customer who signed up online, brought her team and then the other agency they have been working with. The account grew from 1 license in Week 1 to 10 licenses by Week 4. Their teams average 54 minutes per day of activity on our platform.
This is a big win given that this customer don’t know who we are and came through a Google search. I strongly believe that everyone hits success. It is the repeatability of it is where people fail. If we can replicate the above story to a million customers, we would be successful in others definition of success.
The team is doing a great job already to bring great traffic and convert the visits to sign ups and to bring their team. Last 30 days we had 285 signups for a 5.8K visitors and from the 285 who signed up, 30 users brought their team inside.
Persistence
Just like any other founder or start-up story, those who don’t give up after repeated failures win big one day and become an overnight success.
We may or may not hit that overnight success. The reason I wanted to bring this story out is to help founders succeed. It is because of the ecosystem of Founders and Start-ups we are thriving. Even if this article makes it to the “How not to be” list, I’d still consider that a success of having published this.
18