Towards the end of 2017, I published my start-up diaries in the Irish Independent. At the time, the business name and purpose were different, but some of you have been with me since that time. I am refreshing the newsletter, and here’s why: After five years, it’s timely to review the diaries and reflect on the progress, pivots and positioning since then. I hope you stay with us and get something out of the Voxgig newsletter which will feature a mix of entrepreneur experiences and excerpts from our podcast interviews with interesting people from the developer or speaking communities, as they so often intersect.
Originally, the aim was to start a newsletter to assess interest in a concept I had for a bespoke conference speaker software solution. A quote from the first article shows how social media has well and truly become a place to make a living:
Perhaps the newsletter takes off and that’s the business. I can charge a subscription just for the newsletter. Don’t laugh, it’s more common than you think.
How many of us have paid subscriptions to newsletters or content we didn’t have in 2017? I’m not the only one reviewing my content generation, here the Pragmatic Engineer explains the discipline and revenue potential when you make a newsletter your fulltime job.
Five years, a rename and a pandemic later, Voxgig is a growing software consultancy. We also maintain the Seneca Open Source framework and offer DevRel tools to developer advocates. The review of the these start-up diaries will support and provide “proof of work” (with low emissions - honest!) for insights and learnings I share about building a company in the tech sector.
The two main takeaways from the first few newsletters if you are a business owner - the name is not as important as you think, and test your market without writing code. This second one is a biggie! To explain fully, check out the excerpt below from a Sept 2017 article, and stay tuned as I revisit the diaries to reveal the twists and share the decisions that stood the test of time.
Your MVP does not need code. Yes experienced coder, even yours.
This is the third installment of my weekly column. I’m writing about doing a B2B startup in Ireland, and the catch is I have to do it in real-time, preventing me from sugar-coating my decisions. Hopefully we’ll all learn something from this experiment. This week I’m going to justify my decision not to write a single line of code (yet). Despite being a software developer by trade, which grants me something of an unfair advantage in the startup game, I choose to do a newsletter as my Minimum Viable Product, rather than build a prototype system.
I’m a technology advisor to a number of early-stage companies, and I’ve given all of them the same advice: don’t build software! Find a different way to validate your market. This is what I’m doing with a newsletter, and I’ll take you through my numbers and results in a moment, so you can judge whether it’s working.
The development of a prototype system, a working demonstration of your idea, as a website, or a mobile app, seems like something you just have to do. All the advice out there tells you to be lean and agile. You must build the smallest, simplest version of your idea, and get it into the market to validate your business hypothesis. Then you can iterate and improve, to find that most precious of startup goals, product-market fit. You’ve finally built a better mousetrap, and people will beat a path to your door (it is amusing to note that the poet Ralph Waldo Emerson never did utter those words).
Here’s what actually happens. If you can code, and if your co-founders are also coders, you end up writing a lot of code, building a lot of features, and ignoring your customer needs. You stay in your comfort zone. When things aren’t working and your product has no traction, what do you do? You write more code! More features! This is what happened to me in my very first startup 15 years ago. My product, a processing engine for very large data files, was so perfect and featureful that I had a bug bounty programme – I would pay you a prize if you found a bug. I only paid out three times in two years.
The great advantage that coders have when doing a startup is that they don’t need to worry about finding or paying somebody to build the system. But this is also a great weakness, because it allows you to fool yourself into thinking you a building a business when all you are doing is acting like an employee in your own company.
If you can’t write code, you face a difficult choice. Do you spend most of your seed funding paying contract developers to build your first version, or do you give up a great chunk of equity to an unproven senior developer who wants to have a go at being a CTO?
I’ve spoken to so many teams over the last year that are in this position. My advice is always the same – just don’t write any code. Find a way to prove your business first. A Minimum Viable Product is something that you can do manually if you have to, it does not need to be automated. Put up a simple website with an email link, and take orders by hand. If your product is supposed to make something cheaper using the power of software, do it the manual and expensive way yourself to get the show on the road. Find a way to provide value that eases the pain of your potential customers, even if it makes you life more painful.
The problem of building a software MVP remains, and it is a problem you must solve eventually, but it is a problem you can push down the road. The founding team at Airbnb is a great example. They pretended to be professional photographers and took all the early apartment photos themselves, manually uploading them. The backend software to manage apartment onboarding came later.
My startup is an enterprise tool to help conference speakers and organizers connect with each other. A software MVP would be an app where you can register, sign up for conferences, get lists of speakers, get reminders for upcoming events, integrate with your calendar, and share your trips on twitter. I could be writing the code to do that right now.
Instead, I’m writing a newsletter for conference speakers that helps them become better speakers. That’s all. It’s a lot of manual effort, and takes about a day to put together. I try to source high quality content, and I even pay for some of it. The newsletter lets me connect directly with potential users, and lets me do real market research. Although the content is free, your attention is not. Deciding to subscribe and then read a newsletter is a deliberate expenditure of your precious attention, and your willingness to do that is a real measure of the viability of my business idea.
For all these reasons, I choose to write and publish a simple newsletter as my MVP rather than write an app. So how is it going? I’ve promoted it via personal email, twitter and LinkedIn, and this column helps a little too. I publish every Wednesday at 6PM, and there have been four editions so far (you’ll be about a week behind reading this). Why send out the newsletter at 6PM? This seems like a good balance between the US and Europe. People who like to read in the evenings can do so on Wednesdays, and people who like to read with their morning coffee can do that on Thursday. This is pure speculation on my part – if the newsletter is successful I’ll invest effort in validating my assumptions. I use mailchimp.com to write and send the emails, and they have fancy reporting, but you have to pay for it. I will pay for it when it pays for itself.
I’ve included a chart so you can see subscriber numbers. These are growing at about 20 a week. At the time of writing I have 109 subscribers. I think success will be 500+ subscribers by the end of this quarter (Q4 2017). Although these numbers are pathetically low when compared to an established business, they would mean that there are enough conference speakers out there that care enough about conference speaking that tools to help them get better and more organized make sense (If you are subscriber I promise to keep the newsletter the way it is – just for speakers - I rather enjoy writing it that way as well).
There is one other number that matters – the open rate – how many subscribers read the newsletter when it arrives in their inbox. At the moment I’m at about 35%, which by all accounts is pretty good. It will go down, but that’s to be expected.
From now on, I’ll report the subscriber count and open rate each week, and you can track the success (or failure) of the newsletter MVP as it happens.
Next week, more from the archives and an opportunity to see if five years has changed my view on no-code MVPs.