My Journey So Far
My new year's resolution for 2020 was to launch my own tech product. In my career as a software developer, and later a manager, I have constantly been faced with the problem of not knowing exactly how my team are feeling day to day. I do of course conduct regular 121 meetings with the people I manage and I don't think I'm terrible at getting people to speak candidly with me - however, time and time again I would have an employee hand in their notice for reasons I had not heard before. I think there is a certain pattern of reserved personalities among software developers that make them shy to discuss their feelings in a work environment, no matter how much effort I put into building trust and rapport, some people are just naturally shy with their feelings and that is fine. What I needed was a way for my team to give regular anonymous feedback so I could address their concerns before they escalated.
The existing solutions for this were either too basic and didn't give me a view of trends (Google Forms, Slack polls), they were too involved and time consuming (annual engagement surveys) or too expensive (looking at you CultureAmp). What I wanted was something cheap, simple and mobile friendly. I wanted a "pulse survey" platform for small teams so in January 2020 I finally decided to bite the bullet and build it myself.
Logging Every Second
I've always been obsessed with data and making data-driven decisions, so I knew if I was going to plough hours of my spare time into a project I was going to log every second in a time tracking tool. That way in the highly likely event of it being a failure I would be able to look at my time tracking data and figure out where I could have focussed my efforts differently.
For the time tracking tool I chose Toggl and every evening I would come home from my day job, brew a nice strong cup of tea and begin my Toggl timer for that evening's activity.
A Timeline For Product Development
To visualise the time-tracking data I grouped similar activities into 7 main categories and, as you can see, they do flow nicely into each other. I didn't have to be overly strict about restricting my activity to just one stream, it just sort of fell into place.
So based on the data I collected here is my timeline for building a software product.
This is not necessarily the "right" way to spend your time, this is just the journey I took, your mileage may vary.
Step 1 - Research
80% of startups fail in their first year. I've worked at a startup that failed. We spent 6 months building an excellent SaaS product, launched it to the industry and were faced with the sound of market silence. I've learned the hard way why you can't expect to just build something you think is cool then hope other people want to use it. When embarking on this project I made one simple promise to myself: not a single line of code is to be written until I know how and why people use (and pay for) my product. Researching the product-market fit was perhaps the most important step of this entire process and I changed track several times from my initial idea.
Features got dropped. More features got dropped. The idea of a "Minimum Viable Product" really came into focus for me. I'd rather have one core feature that works perfectly and fits a niche in the market, than 10 features that don't.
In total, I spent 35 solid hours over one month researching the market and designing what my MVP would look like. I signed up and paid for several existing solutions just so I could test them out, pick them apart, and identify their shortcomings. I spoke to friends, colleagues and ex-colleagues to find out how they deal with the problem I was trying to solve. By the end of my "research" phase I had a set of hand-drawn wireframes and a whole spreadsheet full of suggested features I had collected from people I spoke to (most of these "suggested" features, however, went into the trash).
If anybody is considering this journey for themselves then there are two books that are basically compulsory reading: The Mom Test and The Lean Startup. Maybe you've read them already, but no shame if not. Both are extremely popular and available in several languages.
Step 2 - Coding
If you are a software developer this part comes naturally and is, by far, the most fun part. I always consider writing code like painting a picture. You get your easel and palette set up, lock the door, put on some banging tunes and zone in.
In the end, I racked up over 100 hours of raw typing into VSCode. I stopped Toggl when I was taking breaks or walking away from my desk, so this was time all spend coding and I really did try to move as fast as possible. This meant no tests, no documentation, no continuous integration, nothing. The code was, and still is, deployed straight from my laptop and tested manually.
This is probably absolute sacrilege to anyone reading this who works as a software developer - and believe me in my normal day job I would completely agree! But this project was about creating an MVP as quickly as possible and testing it on the market. A fully automated continuous delivery pipeline is just wasted time that I might never be able to justify if the product fails.
Step 3 - Testing
After the fun of step 2, the testing phase was a crash back down to earth. You can see from my timeline that the number of hours I was putting into this every day dropped right off.
Nobody likes testing software. You spend forever building something that you know probably has a few bugs, and you'd much rather just pretend it is perfect and get on with your life. But testing is crucial and within ten minutes of giving my friends a link to my beta I was getting complaints that "it doesn't show up right on my phone".
Being a solo operation on a limited budget I really couldn't afford the luxury of tools such as BrowserStack, so I had to rely on ringing random friends and family, asking what phone they had, then staying on the line while they tested out my web app. This was painful for everyone involved. In retrospect, I should have swallowed my pride and bought an iPhone to test with!
Step 4 - IT Tasks
Boy have I come out of this with a newfound respect for people who work in IT operations. I had no idea how much work there is involved with simple things like IAM roles. In my previous section I talked about all the corners I cut in the Coding phase, but nothing in this "IT Ops" phase could be rushed. You only get one shot at storing your users' data securely! The same can be said for error logging, analytics and outbound email. The platform relies on sending transactional emails, so if I did something stupid and sent out too many marketing emails there was a risk I could get my domain blacklisted, which would end the ability of the platform to function. I had to set up a separate domain for sending marketing emails and "warm up" an email account to send from.
Not gonna lie, this was a slog.
Step 5 - Content Creation
When building my product I had TODO all over the place for content I would come back and write later. Now, after 3 months it was that "later".
The content creation stage was also where I made my first big mistake. I had read on sites like IndieHackers.com about how you should play to your strengths and get help from other people where you are weak. So for content creation I did go onto both Fiverr and Upwork and pay some people to write blog posts and marketing copy. This was a mistake. If somebody is charging £50 (or less) to write you a "well-researched blog post" this is a lie. I paid four people online to write me some marketing copy and some blog posts and it was all garbage. Nothing these people wrote me ended up on my precious website. Therefore, I strongly recommend if you need to outsource content creation you either pay a proper market rate for a proper agency (not an option with my limited budget), or you find someone you know who will help you do it yourself.
Step 6 - Marketing
This category was an amalgamation of a bunch of smaller tasks I grouped together to make the graph in this post look nicer. "Marketing" covers everything from creating screenshots, CPC adverts, landing pages, to setting up and growing my Twitter account. I spent a bit of time on content curation for Twitter and signed up for Twittimer to schedule about 3 posts a week for the next couple of months. I also roped in a few friends to share and promote my new twitter account. None of this gave me much website traffic but I supposed it's a long game to be playing.
I also counted SEO as part of step 6, both on-site and off-site. I built up a list of useful contacts in the industry and reached out to ask them to share, review or even just check out my product page.
Step 7 - B2B Sales
If content creation was outside of my comfort zone, then B2B sales had left my comfort zone as a tiny spec in the distance behind it. But without this step, I would never have brought in that first paying user.
In the past I have built websites and made online tools for free that I simply shared around forums and people began flocking to them, but this was different. This is a paid product that people will have to actually invest time and money into adopting, in an already competitive marketplace. Nobody was going to sign up for Acorde if I simply uploaded my sitemap to Google and waited. So I had to reach out. I watched a lot of Alex Berman on YouTube and tried my hand at highly-personalised cold email campaigns. These are actually fun after a while because I got into some great conversations with prospective users and because my emails were polite and completely personalised (no mail merge here, at least not at this stage) I actually got some really inciteful feedback and learned a lot about the kinds of hurdles I would face going forwards trying to sell B2B software.
Part of my B2B sales plan was actually to give my product away to companies that were doing positive things to help with the global pandemic that is currently ongoing, so although not technically "sales" since it was free, I logged time helping some organisations get set up with free employee engagement for their newly remote workforce. I have no objections to giving away what I've built for free, I just need to make sure I can keep the servers running.
As I mentioned before this journey I took is not the gold standard, it is not the definition of "Agile Product Development", nor is it even the most efficient way to build and launch a product. But it is the way I did it and I'd do it again in a heartbeat.