Startup diary: Forget big deadlines and 1.0 versions - just keep developing your product and testing user reaction every week
A new year brings new challenges for our resident startup diarist, who reveals that settling on a minimum viable product is now the fledgling firm's top priority
I started writing this startup diary as a way to make better business decisions. It has clarified my thinking and I hope it has provided you with some insight into the choices that a startup faces. 2018 will be a decisive year for our startup, so let's get back to work!
The big decision of 2017 was to publish a newsletter at first, rather than build a website and software. The primary purpose of this strategy was to validate whether conference speakers would be interested in a website serving their needs. The newsletter focuses on general public speaking skills and the practicalities of conference speaking.
I chose a somewhat arbitrary goal of 500 subscribers by December 31, 2017. This number of subscribers is of sufficient size to tell us that there is a potential community there. The speaker community is the keystone to building a market within the conference industry.
Did we reach the goal? I can't tell you yet. The number I report each week in this column is the number of people that received an email the previous week. We need to let a week go by to collect the open rate (how many people actually read the newsletter). The numbers for the last week of 2017 are 431 recipients, of which 21pc read the newsletter. That's not too shabby for Christmas week.
We put in big push in the last week to hit 500. I've been very lucky to find someone who knows how to do social media promotion far more effectively than I do. When the newsletter goes out later this week we will finally have the answer. It's looking pretty good. You can subscribe at metsitaba.com if you're curious.
I think we can declare an evidence-based victory here. We have definitely shown that there is sufficient interest in a speaker community site.
This data now feeds into the feature set that will form the minimum viable product for the startup. We should not feel too smug.
This was always going to be one of the easier goals to reach. We had lots of supporting evidence. Paradoxically getting to, say, 100 subscribers would have been far more valuable information. This would have shown clearly that the business idea was problematic, and that there was probably no potential market.
It's far more important to know that you're heading over a cliff than that you're driving on an open highway.
We're not on that highway yet. We need to sustain the subscriber numbers and keep them growing at a high rate. We need to tighten up our production process for the newsletter-there have been one or two quality issues, mostly my fault when I rush. There's too much of a dependence on me personally. But these problems are all fixable. In a startup you don't fix anything unless it really hurts.
Let's talk about the minimum viable product (MVP) build process. The key to getting a good MVP is not to build the MVP, but to build the machine that builds the MVP. This is where a lot of people go wrong. It feels natural to plan and budget for a launch date. That is a serious mistake.
You need to go back to the purpose of an MVP: continuous validation of your business hypotheses. Every week you need to deliver a new version of the system, tweaked and adjusted, with new features (small ones!), measure the reaction of your users, and think very hard about what the data is telling you.
Most startups, especially those without technical co-founders, end up treating their MVP as a finite project with a deadline and a list of features. Assuming they can get anything decent built at all, once they are live, they are stuck with something that is only a first guess. But since they have exhausted their resources, they are no longer able to react to the market with feature updates. Don't let this happen to you.
The team that is building our MVP is typical for a startup. We have a small in-house team of two-and-a-half developers (myself included, dangerous as that is), we have two or three external freelancers (such as graphic design), and we have a software consultancy for the mobile apps (as this is specialist work).
This configuration is typical. Too many different skills are needed. Ignore the Silicon Valley myth that you only need three guys (and it is always men) in a shabby rented apartment - you only hear about the success stories, not the 90pc that failed. That's called survivorship bias.
All of these people need to be co-ordinated remotely. This is another reason why I went with a remote model so early.
The key to making this work is to understand that there is no version 1.0. There is no end. Development never finishes.
You have to drop the mind-set of professional project management. It is fatal to startups. You simply don't know what the market really needs, so you shouldn't build anything without getting validation. Detailed specifications are pure guesswork.
The only real validation is from actual users, on the ground, complaining about missing features. Startups don't have the resources to do effective professional market research.
This is a piece of advice you often get from experienced business people who have mostly worked in big companies. You have to be unprofessional and ignore it, because it is one of the most damaging types of advice.
Instead, get a new version out, every week. It will take you a few weeks to put something useful together initially, but after that you can go live. Be embarrassed. It's not going to do very much, but it should be minimally useful for somebody in your target market. This is what we are going to do. Starting next week we'll deliver a new version of our system every week. At first this will be private, but after few weeks we'll make it public.
The trick is to never stop the weekly delivery process. You just keep going. Your team get rhythm and pacing. You avoid burnout and crazy deadlines. Your customers are more confident because they know you can deliver. You do it each week.
Since you have no deadlines, any date can be the deadline. You're always ready for a demo, and you're always flexible enough to take advantage of any marketing opportunities that arrive. One you have enough features accumulated, you can simply declare version 1.0. Since you get a true measure of feature status and development each week, you can actually plan relatively accurately.
I've used this approach to build many MVP systems, and it works. Starting from the premise of weekly delivery, you can define a very effective development process that works for a distributed team of internal staff and external contractors.
We are currently setting up this development process. It will take a few weeks to get right, and we'll do it concurrently with the MVP development. So long as we stick to the weekly delivery discipline, things will coalesce nicely. Next week I will start taking you though the details of this process, starting with the key activity: the weekly demo day.
Richard Rodger is the founder of Metsitaba, a Waterford-based startup. He is a former co-founder of tech consultancy Nearform.