Startup diary: when adding features isn't your best bet in bid for a perfect launch
When you're focusing on a launch, fewer features well executed are better than plenty that don't work well. Richard Rodger explains how to approach functionality
Our startup is building a social network for conference speakers and organisers. In this weekly diary I write about our decisions, why we make them, and what happens afterwards. The idea from the start has been to write about the startup experience as it happens. Now it's time to talk about the launch of our system. We're going to have a soft launch, and there won't be any outrageous parties, but it's still a big deal for us.
We're going to launch on March 13, a Tuesday. That's four working weeks from now. We started development work with a full team about three weeks ago. The timescale is deliberately short because we are following the basic principles of the lean startup approach: release early and often.
I've written previously about the process we use to make this short development cycle work. The most important element is your weekly demo meeting, where you show your latest work to the whole company. That's been going very well. To survive the weekly demo each week you need to adopt a certain ruthlessness to your work. It's much better to have something to show, something that works on the day, than to try to squeeze in an extra feature, and end up with nothing working, and nothing to show.
My role as founder is to make it safe for people to do this. It's okay to deliver fewer features than planned, so long as what you do deliver actually works properly. Taking this to its logical limit, it is, in fact, OK to deliver nothing. That's far better than delivering broken features that hurt the user.
This ruthlessness is a mentality that has to be actively learnt. It's one of those mistakes people have to make a few times before it really sinks in. It's so tempting to try to squeeze in one last feature. As a founder, if you want to follow this path with your team, you have to reinforce this message. Praise working code, even if features are missing. Remind everybody that the number one priority is a live system. Features come second.
You can apply this principle to your entire system to ensure that you go live on time with minimal stress. You have to cut features. This is a universal law of software development. There's an old project manager's saying: "correct, cheap, or on-time" - pick any two. Unfortunately, in a startup, you need all three. The way you get all three, is to make "correct" very small - cut features!
This is a mistake I have seen all too often. A founder is desperate to have a great launch and get good write-ups in the press, so they try to shove as many features into the launch as possible. Or they have a limited budget, so they push the development team to produce as much as possible. This gives you a bad outcome. You end up with a half-baked system that will lose users quickly, if even you do get good press coverage.
Worse, your development team will suffer from burn out, and you've damaged your relationship with them. This is bad. The only way a startup can be successful is to keep improving the product day by day and week by week. You can't do that it you don't have a healthy team that trusts you not to over-commit. It's much better to launch something that is minimally useful but works well. Everybody can agree that under-promising and over-delivering is a good thing, but it's surprisingly hard to do in practice.
We are deciding to put this into practice. A full professional social network connecting speakers and organisers will have user profile pages, messaging, sharing, discussion forums - all the good stuff you're used to on LinkedIn, Twitter and Facebook. We won't have any of that. In fact, you won't even be able to log in.
In our first plan for the minimum viable product that we're launching in four weeks time, you could log in. You could even upload a profile picture. But that was last year. The more we spoke to people in the industry, the more we realised that search was a key problem. Just finding speakers and conferences turns out to be quite hard. There is no Google for the events industry. So that's going to be our first, and only, feature. We've decided to strip away everything else, and focus on getting search right.
You've used Google, so you know what search is. We're talking about: a free text search bar, and a list of search results. In our case, clicking on a result takes you to a page with more information about that conference or speaker. And from there, you can also list all the conferences that speaker spoke at, or all the speakers at that conference. And that's it. That's the entire system at launch.
But we want this to work really well. We want it to have a great user interface, and provide a smooth experience. And we want the launch to be just another demo day, like all the rest, because we want to be able to keep building out all those other features, sustainably. Eventually, you might even be able to log in. You might think search is simple. But think about all the elements that will go into running a live system. First, we have to deploy a search engine, and build up an initial database of conferences and speakers. We did a lot of exploratory work on this last year. Second, we need a software system that can handle lots of small changes on a weekly basis - this is known in the trade as a microservice architecture, and it needs quite a bit of upfront effort to put in place. Third, we need a cloud platform to run the system. We've chosen the Google cloud for the moment. Fourth, we have to build a web application with a nice user interface. Fifth, we have to build mobile apps that offer the same search functionality, but designed for mobile. Sixth, we need a proper company website (at present we only have a website for the newsletter). And last but not least we need a blog with the beginnings of some decent content.
There's not much time left over for "features" is there?
Some would argue that the list above is too much, and we should just concentrate on the product itself for the MVP. That is a fine strategy for a consumer-focused business. But when your customer is another business, or when you intend to help people with their professional activities, the standard is higher.
Strategically we will be working closely with early adopters, building features just for them, and learning exactly how to solve their business pain points. But if you don't have a credible website, it's harder to build those partnerships. If you present as a professional business, then you are credible as an organisation that can deliver new features over time, and meet custom requirements.
We're going to find out soon enough if that line of thinking is correct!
Our newsletter for speakers continues to grow. We have 711 subscribers and a 23pc open rate. Our open rate has been pretty consistent so far, coming in between 20pc- 25pc. One interpretation is that our newsletter content has good utility for the general audience of conference speakers. If the content was too narrow, and only interesting to a small audience, we would see the open rate continue to fall. The fact this it has stabilised is good validation.