Introduction
In 2019 I ventured on a journey to build a sustainable self-funded software business. I went on this journey with a friend of mine called Sumukh. We had no ambitions to build the next billion-dollar company. We just wanted to make something cool that would cover our necessary monthly expenses.
We managed to build six business in a year. None of the products ended up making any money, but we learned a shit load along the way. I'm going to quickly run through what we did, what I would do differently now, and I what I learned from the whole experience
Distribution sprints
https://3.basecamp.com/3092593/buckets/30924/documents/2476946518
https://3.basecamp.com/3092593/buckets/30924/google_documents/1972687482
sprint history
https://3.basecamp.com/3092593/buckets/30924/vaults/2001710960
https://3.basecamp.com/3092593/buckets/30924/documents/2455393713
https://3.basecamp.com/3092593/buckets/30924/vaults/2455393712
Tiny Teams
http://tinyteams.surge.sh
The first business we started with was a project management app. Building a project management tool is a right of passage in startup-land. I'm glad we go this out of our system right away.
Tiny team was a one-page project management platform to reduce the number of tools people need to collaborate on a quick project.
To validate the idea, we reached out to cooperatives and managed to do x interviews.
We thought this meant we had validated the idea. I mean, we read the mom test, so we knew what we were doing. We started building the project and were sure that we could get at least ten pre-orders by the time the product was ready.
We didn't get a single pre-order. We couldn't even get people to use it for free.
We learned that there is a difference between people saying they'll use it and using it. More importantly, when it comes to software for teams, we also learned that the people who use it and the people who pay for it aren't always the same.
Slicing The Pie
Sumukh was reaching out to people, doing interviews and hustling for pre-orders while I was writing the code and building the platform. The problem was that I could only create it at the end of my workday and on weekends. Progress was slow.
After about two months, Sumukh decided to step in pay for me to work on the project full time. He could afford to cover my necessary living expenses. That meant I didn't have to find other work, and we could both focus on the project full time.
Working with friends is a delicate matter. By the end of it, you usually lose a business or a friend. We took a beautiful approach to our partnership and based our split on a book called Slicing Pie by Mike Moyer. Rather than splitting the company 50-50, the basic idea is that the amount you own changes each month, based on how much work you contribute to the company that month. It's clear, and it's fair, which means it was one less thing to worry about, and we could just focus on getting stuff done.
Meetbox
https://meetbox-prod.firebaseapp.com
With all the new energy, we decided to ditch Tiny teams and start afresh. It was clear that people didn't need a project manager.
What we had learned from all the interview we did with teams, was that most co-ordination happens through meetings, not product management tools.
We thought that if we could just make meeting 1% better, it would have a massive impact on project and companies. The general idea sounded great. The problem is that we didn't 1% better meant in practical terms.
We started reading books about meetings.
Interviewed 23 people this time.
[briefly cover how we did marketing]
About tk number of people signed up to the project, but none of them stuck around for more than a few uses.
The question for us at this point was to figure out what the problem was and fix it and go deeper or to treat this as evidence of the fact that people weren't interested in the idea. We only had x time left. We didn't want to waste it on a lukewarm idea, so we decided to move on.
Decisionboard
We started a project called decision board from the realisation that the main reason people have so many meetings is to make decisions.
We thought there was an opportunity to build a product that helped you make long term decisions.
It kept a record of pros and cons around a topic so that you could keep track of your decisions.
We realised that we had spent way too much time writing code for Tiny team and Meetbox, so we took a no-code approach to this project. We got a rough prototype together using Notion. We couldn't get anyone to pre-order the product, and we never ended up using it, so we decided to abandon the idea.
Helm
https://decision-dev.web.app/
The next thing we worked on was called Helm https://beta.usehelm.com/ It was a dashboard to help remote teams keep track of their objectives.
The problem with Help was that it only made sense for larger teams and enterprise companies. We were a small team, and small groups don't need to track KPIs. So we were flying blind because we were building a product for people we didn't understand.
At this point, we seriously considered giving up. We were flailing. We were all over the place. We had four mini-projects that haven't gone anywhere, each for a completely different audience. We had no expertise built up, no experience, no asset to build on, starting over again and again was not the most efficient way to manage team energy and morale.
If we had built four different product for the same audience, we would have had a more precise understanding of their problem each time. So we decided to focus on a single audience moving forward.
Client Tree
https://client-tree-prod.web.app/
So we decided to focus on freelancers.
We went through all the interviews (tk find the total number here) and found a common theme, independent contractors and freelancers find more work.
The pitch was simple; it was a way for freelancers to find new clients that didn't rely on building a brand or gig market places.
For the marketing, we decided to build a content platform around the product
podcast (freelance fish)
blog (freelance fish)
course (freelance field guide)
cold outreach
Twitter hack
http://rhetorical-tendency.surge.sh/
We went all-in on the idea, we even applied to YC with the concept.
We manually onboarded every single user and learned as much as we could about the problem they had signed up to solve. After about three months of work, we got our first paying customer.
https://learninglog.svbtle.com/week6
https://learninglog.svbtle.com/week10
Then came covid...
We were both in India at the time, and the lockdown was abrupt. There were vast communities of people stranded. They didn't have access to food or medicine. Working n a business that helps people around the world when people were starving in our community made no sense. We put the operation on hold and got involved with the local effort to help people affected by the lockdown. We spent two-months doing relief work before things calmed down enough for us to return to Client Tree.
Looking back now on everything, we were more interested in building products than we were in helping people succeed at doing something. When we started doing covid relief work, the only focus was getting food to people. Everything else was just a means to that single, clear end. I wished we had approached our product building in the same way.
As expected retention had dropped to zero, there were zero active users without us continue working to push people through the top of the funnel.
Huddle
We had gained some perspective from the community work and could look at the whole project from a new light. We both felt like we could be working on something more meaningful.
We explored what a more emotional business could look like and came up with an idea for a group call type event. The idea was based on the value that we got from the Pioneer and YC calls.
We put a spreadsheet up on Reddit outlined what we thought happened, and 50 people signed up. We ran the clubs people slowly started dropping off. The moment we introduced the idea of paying for the entire thing fell through.
After about two months decided it's not working.
That was it. We had to draw a line in the sand somewhere.
We had to draw a line in the sand somewhere.
I was exhausted. I couldn't keep on building businesses and watch them crash and burn. There was something I did not understand what we were doing. More of the same was not going to cut it.
I think it is ridiculous that two people could decide to invest all of their time into solving problem, and could find a problem to solve.
Sure we wanted a business idea had to fit into a particular size hole, we weren't going to figure out world peace, but even that. How many people have the money and time to do something like this and the fact that we walked away empty-handed is mind-boggling to me.
I still don't quite understand what happened.
Was the utter product shit?
Didn’t we have a clue how to market?
Is it just a massive element of luck?
Something else entirely?
We spent a total of tk hours by the end of it. On paper, I owned x ad put in the hours. That's not entirely accurate though. I was just a lot more diligent about logging time because I was used to doing it from work. So I don't think Sumukh only put in x hours, I think he also forgot to log a lot of them.
The point is that we spend x hours building six businesses in a year and not a single one of them made any money, not counting the one paying customer we got for client tree.
There were some apparent lessons that were clear by the end of it. For example, if I were to repeat the project over:
I would only focus on B2B businesses because they have a more explicit problem and more money to spend.
I'd Pick a group/target market and stick to it. We shot ourselves in the foot by changing our target market will end up creating no compounding benefits for you.
I wouldn't split marketing and development roles. I regret that, yes divide and conquer and all that but building and marketing is a false dichotomy when you're in discovery mode.
After we wrapped up Huddle, what I was most explicit about I was the fact that something was going on that I didn't understand. We had a little time on the clock. We didn't spend all our money, so I decide to invest it in some professional development before I went back to work.
Diving into Retention
The way we measure success for each of the products is by measuring retention. Retention metrics track how often people come back and use your product after they first sign up. Most people try a product out and then never come back. Sustained use is the best indicator that we are solving a real problem for a group of people.
I wanted to learn more about retention, how to design products with it in mind, what the principles are behind excellent retention. All I knew was that I knew so little.
There were surprisingly few learning materials and courses out there on retention. I read everything I could, started following everyone who even came close to talking about retention. I found a handful of courses and programs on the topic, they were costly, but I did them all, and as soon as I had some bearings over what was going on, I started applying the framework I had learned to project. I started working right away, helping software teams improve their retention rate. I wanted to put as much theory into practice as soon as possible.
Looking back now, almost a year later, I realise that we were in the right ballpark, but we didn't have a clue how to build products that people use.
If I were to build one of the projects from scratch today, there are probably lots of things I would have done differently, but three main areas that I would focus on:
1. Picking a frequent problem that people are already trying to solve.
The natural frequency of the problem you help people solve is essential. I'd rule out any product ideas where the problem doesn't come up at least 2-3 times a month. The idea is to build on top of an existing behaviour people already use to solve a problem. Everything becomes much more challenging when the problem only comes up once or twice a year.
2. Designing around a core engagement loop
Once you have a frequent problem, then you can lay out what people have to do to solve that problem, and what success looks like. These three components make up your product's core engagement loop. If you are trying to build a product that people use, you must have at least one core loop. I don't want to overcomplicate this. I’m just talking about giving people what they came for. People need to have a meeting online, so setting it up should be simple, and success is a clear meeting with no interruptions. Just focus on delivering the core value you promised people on the landing page. If you are trying to build a product that people use, making sure that people get what they came for sounds so obvious. You laugh, but we didn’t measure how many people succeeded with our product. We didn't even know what "succeeding" meant in the context of our development. We weren't measuring how long it took people to succeed after signing up. Weren't measuring changes in these number with each new release. If I were to start over, I would define that core engagement loop and spend every moment optimising it till we had ironed our every kink.
3. Getting Onboarding Just Right
I had no idea how vital onboarding is tp product design. Like most people I thought it just meant slapping on a welcome screen and some prompts after you've finished building the product. Getting onboarding right is the most critical aspect when it comes to improving user retention. Having a wicked effect means nothing if people never make it far enough to enjoy the value it offers. Once you have a clear engagement loop, you can trace people steps and map out every interaction along the way. You can break these down into obvious steps, measure where people get stuck and slowly refactor the process people engage in when pursuing the value your products offers.
Doing this isn't about following a bunch of patterns and best practices. Best practices are a starting point, but real insight comes from product analytics and speaking to customers. Talking to people and instrumenting your product so that you have useful data to work with is hard work, and they are easy things to mess up. Sometimes things are apparent, and the idea is to move fast other times, there is no clear path forward, and you run experiments to see what works before you can make any progress. This process is gratifying, though. Any moderately successful application will inevitably run into user retention issues and having a strategic framework to product development process makes it feel less like throwing spaghetti at a wall to see what sticks. This process is gratifying, that thrill that I got from setting out to build a business, I get to experience every day know, and I get to work on multiple products with exciting people. I have something of real value to offer.
On the surface, this is a story about two people making a bunch of silly mistakes and building a bunch of side projects that didn't go anywhere. Sure, lessons were learned, we didn't end up with a win, there is no victory to flaunt here. But underneath it all, there is another story, at least for me, and it's a story about connection and community and working with people. I don't think it is a coincidence that all six projects we worked on we are about teams, groups, networking and community. I started this project as a very isolated, independent freelancer. I have only had terrible experiences working with people and in large teams. And then I spent a year working with a friend, and although we didn't achieve what we set out to achieve, I think the fact that we are writing this together, at the end of the project is a monumental victory for me. I trust Sumukh and would work with him again in a heartbeat, I have no regrets about what we did, and I am grateful and fortunate to be so privileged to experience a journey like this.