We’re arriving once more at end of another semester.
As many of my friends, who are also studying, I am buckling down and getting ready for the exam period. Everyday brings it closer and with it a sense of nervousness, but also excitement.
In particular, the end of this exam period signals the end of my uni career. And I can’t wait to be able to pour more focus and energy into my goal. So with that in mind, I thought now would be a good time to think back to some of my past failures and see what I can learn from them.
These failures are of, what I refer to as, “side projects.” A side projects are ideas and products that are at the inception stage: before I would call them a startup or a business. Yet, they generally have the potential to gain a lot of traction and grow quickly. Twitter, for example, started out as a side project, and so did Slack.
The vision behind Tobio was to introduce dynamic, algorithmic, financial trading in an easy to use web platform. Currently it’s really easy to get set up with static trading, such as with Acorns, and it’s just as easy to do dynamic trading with a bank or something like RobinHood. But there was no platform, that I knew of, to allow you to to write you’re own algorithms and let them loose, with real money, on the real market.
The plan was to create a web platform that allowed you to write algorithms and back-test them, which means testing them on historical data. This would allow you to determine how good, or bad, the algorithm was and let you tweak them without putting any of your real money on the line.
Then I would market this initial version as “the flight simulator for your personal finances.” Hopefully this would draw an initial, niche user base, and I would grow it from there towards the main vision.
In hindsight this seems like a pretty solid idea, on the surface. Yet, there is fundamental flaw with all this, which I didn’t realise until a few months into the project.
Trading is hard. And algorithmic trading is even harder.
To write an algorithm that makes any money on the stock exchange, yet alone one that does so consistently is extremely hard. It’s a challenge even for a seasoned economist and trader. For a programmer or your average engineer it’s nearly impossible.
It seems obvious when you think about it a bit more. If it were easy to write a trading script and watch the money roll in, then everyone would be doing that.
Understanding this makes obvious a very negative user story. A user would come to the site and give try it out with a little bit of money, which they would likely lose. At this stage most would not return, and the few that stayed and tried again would likely lose even more money leading to a churn approaching 100%.
All theory, no practice
From a more operational point of view, I had no idea what I was doing. This was my first attempt at a venture and so obviously I didn’t have any clear direction or foresight. So I set out to plan everything and did a lot of thinking and writing: business plans, strategies, marketing ideas, and so on.
At the end of the day I came to realise the fundamental flaw I mentioned earlier. But if I hadn’t, I would’ve likely continued to work and plan way too much before actually testing out the product on real users.
In essence, I didn’t set out with the aim of achieving product-market fit, I set out to plan everything the best I could first. That lead to a lot of fumbling with documenting thoughts and strategies.
To add to this, I’m not an economist, and I have very little experience in stock trading. So I’m really the last person that should be trying to build a platform to facilitate stock trading. I had the algorithmic side covered, but not the trading side.
Pylon had the goal of being an automation platform, that gave you access to individual pylons to do work for you. A pylon (lowercase) was a black box with very simplistic inputs and outputs, but usually a complex inner working, and it had the goal of automating some process for you to save time, money, or whatever.
An example, which was the first pylon I created, would summarise text for you. So you provide an article or PDF and it would pick out the important sentences, keywords and the topic of the text.
The larger vision here was to create a massive platform of these automation pylons that users could use to make life a little easier. And while building out this platform I would be creating “Mother of All Pylons” which was a pylon to create pylons.
In opening up pylon creation to users who likely didn’t have a technical background I was hoping to create a new way of thinking about programming. It would be a more accessible way to develop software.
The wrong angle
I took what I learnt from Tobio and dove straight into building something instead of fumbling around with business plans and strategies this early on. And, although I still didn’t much economic knowledge, I definitely knew a lot more about automation and software development.
I ended up building something which was good, but it just wasn’t at the right level to get close to achieving a product-market fit. And this, I think, it partially due to my next point.
Ultimately I came to realise was attacking this problem, of saving time and rethinking software development, in a way that wasn’t really effective. I had to come up with all the pylons but I really didn’t know what the market wanted.
I started working on Pylon about at the start of my final year at university. So the amount of time I had to spent studying was increasing and to juggle that, and a part-time job always meant that Pylon had to take the back seat when I needed to find more time.
Looking back, I’m glad I made that choice. And it’s one many young entrepreneurs have. Paul Graham explained it in one of his essays: A Student’s Guide to Startups. He says that being a founder is a full time job. And being a student is a full time job. To be part time at either one is ineffective, and being full time at both is just not possible.
So I wasn’t working on Pylon enough. And I would go days, and sometimes weeks, without making any progress or iterating on the product. Eventually I realised that, in it’s current form, it just wasn’t going anywhere and so I needed to put it to the side.
The take away
These two ventures weren’t without their positives. I learnt a lot both technically and in the business world, and I gained some great experience and valuable insights.
In fact, Pylon made me realise a great passion of mine and solidified my understanding in why I love technology. You can read about why in this post and here.
Before getting any users, at such an early stage, it’s important to be focused on the product first. The goal should be to build a good (not necessarily great) beta version and release it early. Then iterate until you obtain product market fit and go from there.
Even from a technical point of view, you want to be able to iterate quickly and build a ‘hacky’ version very fast. You don’t want to be spending time engineering the perfect database schemas or designing a complex microservice infrastructure. If you get enough users and start experiencing large amount of technical debt and scalability issues then it’s probably time to rewrite your products. But at that points it’s justified and solid engineering is required. If you do this too early then it’s just wasting time and engineering effort in creating a structure that’s likely too rigid to iterate quickly.
Experience is important
Before I started working on Tobio, during and after as well, I had been reading a lot of articles on starting your own business. I thought I knew a lot, but these experiences made me realise how much of what I thought was essentially regurgitation.
It’s completely different to experience and understand what it feels like to be in these positions. Articles and all the hype on the web is great but it’s not as good as experiencing it and learning for yourself, or even talking to others and learning from their experiences.
In the real world knowing the Top 10 Things To Do for a Successful Startup isn’t going to help you, well at least that’s my opinion.
These insights may seem obvious, and to some they are. In fact I’m sure I could’ve regurgitated them from some articles I read about startups even before working on Tobio. Yet, I found that when actually working on these projects, reading all those articles didn’t help much.
Experience and practice is key. At the very least it’s humbling and puts a few things in perspective.