Saturday 21 September 2019

Startup diary: Why functionality beats polish all day long

It is very easy to make an interface look impressive, but your focus should first be on the infrastructure of your software system – forget about the user interface for now. Stock image
It is very easy to make an interface look impressive, but your focus should first be on the infrastructure of your software system – forget about the user interface for now. Stock image

Richard Rodger

My startup is building our Minimum Viable Product (MVP) and this startup diary will give you a ringside seat as we go from broken pieces on the floor to a live web site with mobile apps. I've written previously in this diary about the process we are using to build the MVP. We have a weekly demo meeting, where everybody shows their work. This keeps the process honest and gives everybody a feel for the true state of the software system.

But the system itself still has to be constructed. As a technical founder, and as a practising software developer (yes, CEOs that code are a thing), I do have an advantage here. Building software is my trade after all. Still, I certainly won't be building much of this MVP, since there is a company to run in the meantime.

What I have done is put in place a few construction rules to ensure we end up with a high-velocity software delivery engine. That means going pretty slow at the start.

Every industry has tricks for managing difficult customers. Sometimes these tricks are even in the customer's best interests. Software is no different. One trick that I learnt the hard way, is that you never show a professional user interface until the end of the project. If the customer sees an app or website that looks finished, that has good graphics, and whose page transitions and interactive elements are smoothly and professionally animated, then the customer will very quickly reach the conclusion that the work is all done. There must only be a few tweaks left, a bit of topping and tailing.

That is completely the wrong conclusion. Take careful heed if you are not technical, and your development team or consultant shows you a pretty interface early in the project.

It is very easy to make an interface look impressive. It is predictable work with fixed rules, and competent designers and front-end developers can deliver great interfaces to specification and on time without too many late nights.

It is precisely this predictability that leads you astray. It's all sizzle, and no sausage, as a former colleague used to say. Building the business logic that sells your product and delivers real value is very hard, and takes time to get right.

Figuring out what your users actually want, and how you can make money from that need or pain, is difficult high-risk work that is inherently unpredictable. And yet this is where the real value lies, and the work that is life or death for a startup.

This diary records my decision making for the business. You get to see how my decisions play out, and I get to pay for them.

But here's an easy decision that is worth the money. Focus first on the infrastructure of your software system. Forget about the user interface. Don't fixate on where buttons should go and what should be written on them. Throw your icons in the bin. There will time enough to iterate on these things later, and you can do so in the context of testing user reactions, rather than guessing.

The first weeks of an MVP development project should focus on technical infrastructure. You need to get to a live system as quickly as possible. After week one you should have a live website up and running (password-protected, of course). It doesn't matter if it looks crap and does nothing. You now know that your team can put something live. Then you get them to do it every week. Now you know it can be done predictably. You've just removed a huge amount of risk.

This tactic is complementary to the advice to build small features every week. If you just focus on the features, the developers will keep everything on their laptops. You'll end up with a fine system that cannot run in production. So you will have to wait many more weeks while they sort out all the deployment issues, only to discover that the system can only handle 10 users at a time when it finally goes live.

That is the life story of far too many software projects, and is while career-limiting in a big company, it is fatal for a startup.

Let's remind ourselves: the business strategy is to use rapid iteration to ensure you build the right product. One tactic to execute this strategy is to deliver small features in each iteration. Another tactic is to make sure your foundations are properly laid.

First get the site up and running, then worry about what to put on the home page. How does this work in practice for our little startup? Our target for the first public version is a search engine for events and conferences. So we put together a single page with a search box, a search button, and a list of categorised results. That's it for the website. The mobile apps are just copies of this layout. We did this late last year, and we have not added anything to it since.

Instead, we have spent the last few iterations building a deployment system. We can now go from local development to production, predictably, every week.

We have validated the tools and cloud services that let us do this efficiently. We have an external contractor building mobile apps, and we've got them to demonstrate that they can deliver on a weekly schedule.

We've trialled and deployed an open source search engine, and figured out how to integrate some simple machine learning into it (for a recommendation engine).

All of these elements are up and running on live servers. We're already paying Google and Amazon for (small) servers to run all this stuff.

But if I showed you my interface today, you'd laugh at me. It does pretty much nothing. It's not slick or polished. And yet we know we are now ready to start building features. The entire team, not just the technical people, can see, viscerally, exactly what the state of play is. It's clear that we still have a lot of work to do. But each improvement that we make is real, because it's live. Progress is cumulative, and won't collapse near the end of the project.

If you're doing a startup, and you're not technical, you will still have to manage a software project. That's the way the world is these days. Insist from day one that the thing is live and running on a server somewhere.

Never let developers use their own machines for demos. Don't be impressed by, and don't look for, visual polish. Don't ask for user interface features. Pick some small kernel of core functionality that demonstrates business value, and get that built, end-to-end. Now you have something you can use for customer discovery work. You'll save a lot of money by not building, and polishing, the wrong things.

Newsletter update: 668 subscribers, 23pc open rate. This is much slower than we need for our goal of 40,000 by year end. We're cooking up some schemes to accelerate growth, but that means we need to reduce the level of effort on the existing promotion work to give ourselves time to think!

Richard Rodger is the founder of Metsitaba, a Waterford-based startup. He is a former co-founder of tech consultancy Nearform.

Indo Business

Also in Business