Resourceful is my middle name
Previously, I talked about how we discovered the problem statement we wanted to solve with CleverSpend and how we got started. In this part, I am sharing how we thrived despite having limited resources.
We had everything we needed to start a business, and it was not a lot, to be honest. I still sometimes marvel at how a tech business can be started with almost nothing in hand. All we needed was laptops, a website, some odd tools to automate our emails, an internet connection, and of course our skills. COVID brought several bad things into this world, but one good thing it brought was to make people realize that we don’t have to be colocated to do many things.
Both my co-founders were in another country, and it was acceptable to not have an office space. We questioned everything we were doing to assess why are we even doing that. Is it even needed to be done, does it need to happen now? These simple questions allowed us to wisely utilize our resources only where they were required. It kept the team small and maintained the velocity.
We broke down our problem into smaller problems. We mapped how exactly we want to proceed. Ultimately we wanted to have a look into what products these companies are using, but we discovered that the SaaS management products were very commoditized and it was a good-to-have product, not a must-have product, and we did not want to work on a product that didn’t server a critical need. So trying to build that product and then trying to sell it would give us no advantage over anyone else. Plus, it would need capital to build the product. This is where we discovered another business model, which would closely resemble a service, where we could procure these softwares on the company’s behalf, taking away all pains that come with the buying process, and all the tasks we expected our tool to do, i.e. telling which software to buy, at what price, when? we did all that manually to start with. Since we were doing it for more than one company at a time, we could do it much better and more cost-effective than their team, and we could charge a big enough price for that, which would give us steady revenue, so that we can run this experiment, build the traction, learn what to build and build it, and later raise money at our own terms, without a rush.
None of us had ever done B2B sales, but this is where my experience with BrowserStack helped. We started with defining our customer persona. We defined:
We were offering mid-sized companies help with managing their software purchases and helping them procure software at the right price. Our target customers were departments that would buy these products, and people who facilitated these purchases, so department heads, finance heads, and procurement managers became our target customers. We realized that the quickest way to find these people would be on Linkedin and email, so we started learning about what makes a good outbound sales campaign.
Over the months, our sales campaign kept improving because we asked for feedback from each prospect we talked to: ‘What made them speak to us’. This gave us a good idea about what really works, and which copies resonated with them, and kept updating our copies with that feedback. Our sales cycles were long and some of the events surprised us, but discussing with other AEs and founders kept us sane through these challenges.
We didn’t buy any fancy products and did not include any bloat in our processes, didn’t do anything that could be avoided, we prioritized. Instead of going for a full-blown sales CRM, we just started with an Excel sheet and added information as required, such as what was the last action taken with this person and when we need to take the next action, and what action needs to be taken.
We took an important decision we made?once we got paying customers and our run rate hit $60,000.?We noticed that they need something tangible to make sense of the progress with us, which meant we needed to finally make a product that can at least show that. But that was a big investment for our small team, so we pondered whether we should divert our energies and limited resources toward building a product. It wouldn’t help with what we were delivering at the moment, but it would become part of the product that we wanted to build in the future. So, after deciding why do we need the product, we realized we don’t need a lot of features in it. And we also realized that our end product would look widely different from where we would start, so this product might get completely rebuilt. So we decided that we would make this tool using a no-code solution despite having two of the three co-founders who were software engineers. This is one dilemma I see often with non-technical founders. They often get stuck at ‘looking for a technical co-founder’. I think, in most cases, there are tools that you can use to create the basic MVP that would show the concept to your target customers, and in many cases, they don’t even need to build a technical product to prove your concept, so instead of waiting to find that right person who could build your product, ask: what is the minimum I can do that would show what value I offer?
Few of the things we did well along the way:
Few of the things we could have done better:
In my next post, I will walk you through how we applied to YCombinator and another bold decision we faced because of that.
This post is part of five post series that was intended to walk you through our journey of building our startup and shutting it down. Please find all the posts?here.