Startup Diary: 20:20 hindsight vital to find out where you are on launch mission
Richard Rodger reviews his startup's software successes - and failures - with a candid look back on the decision-making involved so far
Our little startup is nearly a year old. I started development and planning in August 2017, formed the company that September, and hired staff in October. Enough time has now passed to start really examining our decisions with the benefit of distance in time. The whole point of this startup diary is to provide a tool for making better decisions, and we do that by hold a retrospective mirror up to the past.
I'm going to focus on our technology decisions first. Over the next three articles, we'll review our software build out since founding last year. To give this review some structure we need to examine each decision in terms of the strategic and tactical thinking that went into it. How did the decision further the strategic aims of the company as they were at that time? Was the tactical implementation well executed? With hindsight were the strategy and tactics as effective as we though they would be?
Our mission in voxgig is to create an event-management platform for everyone in the technology industry that makes collaboration much easier. We have a lot of competitors that focus on the mundane aspects of event management, or focus on making money by taking a percentage of ticket sales. Our take is that making collaboration easier is the real pain point - everybody is drowning in email.
It's great to have a theory about what will make a good business, but you need to validate your ideas. The best way to do that is to build a so-called Minimum Viable Product (MVP), get it out there, and see if anyone bites. This is a great idea in theory, but it does have one small issue: building an MVP is actually quite expensive. Standards have risen, and even if you have a small set of features, you need decent well-designed website, and you really should have iOS and Android mobile apps if you can manage it. So you're looking at about three months to pull something together. That's three months before you get any real validation. Yes, you'll be talking to a lot people, and doing a lot customer discovery interviews, but actual engagement with your product is a big data point that you really need.
Facing this dilemma, we recognized the strategic importance of building an MVP, but decided to take the tactical approach of publishing a newsletter for public speakers as our MVP. Perhaps you might question whether a newsletter is a product. We think it is. Let me run you through our thinking: the newsletter is targeted at public speakers, specifically those that speak at tech conferences, the sector we are focused on. Speakers will be a key user group for us. To subscribe to a newsletter is not free - you pay a price not with cash, but with your time and attention (which is more valuable than you think!). Convincing people to read a newsletter is therefore requires a marketing and sales effort. A newsletter does not write itself. You have to put together a team and production process.
The net result is that the newsletter validates not only the level of interest in better tools for tech events, but also validates our ability to deliver and market a product. We have done great job on the production side, and a high-quality newsletter goes out every Friday. We're building the subscriber base by about 100 new subscribers a week, using LinkedIn as our primary marketing channel. By all accounts this is pretty good going, and we're now approaching 3000 subscribers. Of course, this is very far from our target of 40000 by year end. The next channel that we're working on is podcasts, but that has taken much longer to launch than anticipated. We have yet to start any kind of Twitter campaign. There's a lot more to do here, and a full review of the newsletter activities from a marketing perspective is something for a later article (I do need to do a retrospective on our marketing too).
From a technology perspective we have had to build some small custom tools to make composition more efficient, but nothing too big. In review, we achieved an important primary goal: validate interest using an MVP, and we did so with very low expenditure on technology. I can't recommend the tactic of using publishing a newsletter as your MVP highly enough. Not only do you get great feedback from readers, but your get a very good early check on the quality of your idea. And you can do it all without needing a CTO or technical co-founder. We use mailchimp.com to write and publish the content, and it's very simple.
What about our website? You need a website, and this can be a significant cost if you get one built by an agency or a freelancer. Your website does need to look professional, so what do you do? These days, things are much easier than they used to be. The first version of your website should be built using squarespace.com or wix.com. These are online website building services that provide you with ready-made templates and content, and provide basic functionality like contact forms. They are so simple and quick you'll be up and running with a day or two. I don't see how you can justify an more effort than this on version one of your website. Our decision to use these services was a real winner, freeing up time to spend make the newsletter higher quality, which ha really paid off in terms of organic subscriptions.
Eventually you will need a little more sophistication. You then face a critical decision point: do you start using WordPress? WordPress is an open-source software system that was originally a blogging platform that now has so many plugins and extensions and themes that you may never need to use any other type of technology. Sounds great. Well there's a gotcha. You'll move very fast in the first year, and it will be easy to find freelancers to help you build stuff, but then you'll start suffering from technical debt.
Technical debt is the crushing complexity that builds up in a human-designed system over time. A good example: tax law. We humans are just great at adding layers and layers of complexity in ever more desperate attempts to solve problems created by the earlier layers. For a technology startup, the effect is that you get slower and slower at building new features, your site just less and less stable, and just at the point where you could be the market leader, another company comes along and executes much faster than you. You can't keep up with feature delivery and you fall behind. You don't make your numbers, and then the venture capitalists won't invest. So much for ringing the bell of the New York Stock Exchange when you IPO.
But things are never that simple. Yes, a WordPress based system will incur serious technical debt over time. But, if you have no technical co-founder, then you probably should go down the WordPress route - it is the fastest way to get a real MVP live.
Since I am my own technical co-founder, I decided not to use WordPress for the first version of the system. But this decision was not without cost - we only launched our MVP in March this year. That's two quarters after starting. Some might say that's pretty good going, but I felt pretty frustrated. WordPress would have got us there sooner. The strategic reason for this decision was that we are building platform, and the cumulative competitive advantages of providing a platform are very significant. So we took a tactical risk: delay the MVP to build the foundations of the platform. Whether that decision was right is still to be determined, but it does mean that the customer trials that we are currently running have gone much more smoothly.
You might think that stressing our over a timing difference of a few months is overkill, but in a startup, you only have a finite number of months before your money runs out, so every month counts. Striking a balance between higher future gains, and near-term death is a choice you face all the time.
(Newsletter update: 2,652 subscribers, open rate 11pc)