In April, I did a talk at the Hacker News London meetup. The talk was about a startup we’re working with called BuyaPowa, and I did the talk with its founder, Gideon Lask. We only had about 10 minutes. Gideon explained the concept of social commerce at the start and took the last couple at the end to explain how BuyaPowa was currently doing. In between I talked about a few things I thought the tech audience at HNL would find interesting. These were things we’d learned while creating the BuyaPowa Web site and back office.
We started out with a high-level set of personas, ideas for features and a basic red-route customer journey, and worked with Gideon very closely to build the app while he was going through a funding round with potential investors. Things changed on a daily basis as we collected feedback. The code was kept in a constantly deployable state and we were able to release whenever new demonstrations came up. Everything done and everything we thought we still needed to do was very visible and could easily be rearranged.
The personas enabled a great way for us to talk about customers from very early on – who they are, what they value, why they will use BuyaPowa. We added other personas when we recognized there were other people in the mix we had no representation for, e.g. administrative staff. One persona we originally missed was that of Gideon himself – the founder! Before he got funding and we got closer to launch, Gideon was the only real user of the site, and his goals weren’t the same as those of a customer or an administrator. His goals were more like “Gideon needs a foolproof way to put the site into a known state with prepared data so he can deliver a rehearsed pitch to investors”. So we created a persona and invested time to make his life easier and amplify his pitch. Don’t forget to think about the founder and his or her needs early on – they might be the only user and it could stay that way if funding isn’t successful!
We do test-driven development and a lot of testing with automated integration tests and functional tests. Plus continuous manual ‘eyeball’ testing. We have test suites that test integration with third party services like Facebook in isolation from the other tests. Some people think this is taboo in a startup where you probably don’t even know if you have a market yet. I want to go into this in more detail in another blog post, but for now, if you’re just testing the market for say bird cage demand and don’t actually write any code, then sure, you don’t need to write any tests. If you do write code, then you should want to know that that code absolutely works as expected. So you need to test it, right? Maybe you’ll do it manually. If your automated tests take so long to write that you’re saving time doing manual testing instead, then you need a better test toolkit.
Founders have a limited amount of time. They may periodically be preoccupied by raising money; they have to talk to potential partners and customers; they need to observe customers. The most important commodity in a startup is the time your founders have to think about the problem. They can’t do any of that if that if they’re chasing production issues, or responding to negative publicity about a buggy site, or are wasting time worrying about imminent events because they’re not sure if the site will stay up. Quality matters. They also don’t have the time to do all those things if the site becomes a raging success and they need to concentrate on how to grow their business. There’s a risk that extra development time spent on quality may mean less features. There’s also a risk that you squander the most valuable asset that your startup has – founder time developing the business – if you don’t at least reach a certain quality bar.