The TuitionKit Launch: 10 Lessons Learned

It’s been over a month since we launched TuitionKit. Here’s what I’ve learned thus far

At 2:00pm on Friday 10th April we launched TuitionKit, a GCSE and A-Level qualification elearning website. Fridays are terrible days to do anything, never mind launch a SaaS product, but that’s just how things fell in the end. My business partners Leon and Jonathan were waiting anxiously in their respective homes, waiting for a text message from me. I deployed the first live build just after lunch, and immediately texted them; “We’re live”. Soon afterwards Leon registered an account, to see what he could break.

As expected, things went terribly. I’d ballsed up the sign-in cookies big-time, thus on the server side the authorisation wasn’t working, resulting in Leon being repeatedly booted out of the system. I was stressed but not surprised; from bitter experience I know that launches are always shit – nerve-wrackingly, hand-wringingly, palm-sweatingly, teeth-grindingly shit.

But you always learn some new things. Here’s my takeaways:

Launch days are your most productive ones

Don’t know why this has just dawned on me, but you get more lines of production code written on a release day than any other day, mostly in the form of urgent patches. It’s interesting to know that panic makes me write more concise and solid code than calmness does.

Best practice my arse

The current so-called “best practice” for registration forms is having only one box for users to enter a password. Apparently you shouldn’t be asking them to repeat this password for confirmation; should they make a mistake they’ll use your website’s password recovery facility to retrieve/reset their password, and they’ll be happy. The raison d’être is that the more you streamline the registration process the more likely a prospective customer will complete it and sign-up…

…which is all well and good in principle, but unfortunately this idea turns out to be utter bollocks when put into practise. Over the first weekend we had over 50 sign-ups, and at least 25% of these had to resort to resetting their password. People make mistakes, but people don’t usually assume that it was them who made the mistake; their first instinct is to blame the system. So whilst all of these users have eventually managed to gain access to the system their patience has been ever-so-slightly strained. Take it from me, someone who has seen the evidence; put two password textboxes on your registration forms.

On the topic of confirmation inputs: chuck in a couple for their email address as well

Unfortunately, regular folk don’t seem to proof read. 10% of our registrations type their email address wrong, thus 10% of the user account table is a junkyard of misspelled email addresses. Most of the time users realise what they’ve done and register again immediately with the correct one. But many don’t, and those users are never coming back.

So I recommend you bung a confirmation box for email addresses on your registration form too. In fact, I’d go so far as to advise that if you like neatness and organisation – or have a phobia of clutter – never build anything with a user account table, because end-users don’t give a crap about the tidiness of your apparently wonderful database.

People still double-click stuff on web pages

Originally (before a few tweaks) every day I would receive a barrage of error log emails, telling me that database insert queries have failed, all of which are generated by people double-clicking on the “Register” button, submitting their details multiple times. I don’t currently have a good solution for this, but whilst the burden of website usability is on me this hasn’t stopped me from forming a grudge. With our customer-base heavily centred on 16 year olds I can’t help but feel that the youth of today ought to be savvy to how the web works, but apparently many of them aren’t, so that’s a wake-up call for me. My best weapon (so far) in preventing this double-click nightmare is a piece of JavaScript to lock the UI while the postback is occurring, but it’s hardly an elegant solution.

Have one customer contact email address – for everything – and operate a triage process

This was one thing I insisted on from the get-go, and I’m happy I did. All company correspondence goes to one helpdesk inbox, to which all of us have access. Jonathan is the main operator of this, and he answers what he can without bothering me. Any customer queries that have a technical edge are forwarded on to me, I remedy their problems, and then I implement extra functionality to combat the common technical issues that keep cropping up (proactive fire fighting, if there can be such a thing).

When outsourcing any work always ascertain where the freelancers are actually from – never assume, like I did

Many weeks ago Leon outsourced the creation of the marketing site, and I had to liaise with the freelancer to coordinate the migration of the WordPress assets onto our web host. We communicated via Skype messaging, and his written English was no worse than the average standard of the UK populous, so it never occurred to me that he was a foreigner; I assumed it was just some bloke that Leon already knew.

When my outsourcing buddy commented that the web host “wasn’t too good” I was baffled. He was referring to the speed of the FTP connection, which for me was blazingly fast; it’s an Irish web host, so in internet terms right on my doorstep. It was at this point that I spotted the tiny writing at the top of the Skype window: the freelancer, Waheed, was talking to me from Islamabad in Pakistan…and upon this discovery several things fell into place in my mind.

In an earlier conversation I had used the phrase “okey dokey” – which replaces “yes, that’s fine” in my vocabulary. Since I’d typed those words Waheed had begun using them at the start of every exchange we had, and other than being a little whimsical I hadn’t found this especially unusual. It was only after I discovered where he was situated that I realised he had assumed “okey dokey” was some kind of English salutation, and he had immediately started using it in place of “hello” in our conversations: “Okey dokey Drew, how are things?”

From that point on I heavily sanitised my messages; anything that was in the least bid idiomatic I replaced with the most vanilla English I could muster, which was painful. At one point I almost sent a message containing the phrase “done and dusted”, which I swiftly spotted and removed: I can’t begin to imagine how a non-native English speaker would interpret that expression. As for the connection speed thing: it turns out Pakistan has fatter internet pipes to the United States than Europe, meaning all the Pakistani freelancers I’ve come across use GoDaddy, which I do not.

Most publicity is good publicity

Haters are, inevitably, gonna hate. We were initially removing disparaging comments from the company’s Facebook and YouTube presences, expunging the usual melodramatic nonsense, such as: “Why aren’t you giving this away for free!?” and “Money greedy bastards”.

But after our first week we had a change of tack, and started to heed the advice of a colleague who’s also in the elearning biz; now we’re leaving the comments well alone. Every last remark, every tweet and retweet, no matter how insulting, is a discussion of our product: the more you have, the more people see, and the more people see, the more customers come to us. If people are going to hate the product they’ll hate it regardless of what other people are saying, and conversely if people are going to like it then the haters won’t convince them otherwise. By leaving all comments in play, both negative and positive, we’re slowly filling the internet with discussions about us.

Free-loaders never pay. Forget them

People who make a habit of consuming web content for free will never pay for stuff, period. Don’t try too hard to market to them in an attempt to encourage upgrades to paid plans, because 99% of them will never pay for stuff (I know this because I’m one of those free-loaders, and it’s difficult to make money off tightwads like me).

Sherlock your analytics

By following the flow of the acquisition funnel through the marketing site we discovered that a typical visitor’s journey began on the home page, followed by a swift navigation to the pricing page, then finally to the registration page or away from the site. We had a massive drop-out rate from the pricing page, higher than should be expected, so we deduced that we’d priced far too high. After one week we took a gamble and reduced our prices, making sure to refund our prior sign-ups in line with the changes. Since then we’ve had an upsurge in registrations.

Test your traction channels

In our case:

  • Google Adwords isn’t effective for us at all, with an 80% bounce rate
  • Radio adverts have been utterly pointless, with zero referrals
  • Flyers have been reasonably useless
  • Newspaper adverts have gone practically unseen
  • Facebook advertising is working a treat

Following these broader methods we’re now purely targeting the Facebook ads and social sharing, and I’d like to give a spot of Twitter advertising a try. We continue to burrow into our Facebook referral demographics, but so far our conclusions are: children Like stuff, parents Share it. For us, targeting a mix of the two is the answer.

A Big Cog in a Small Machine

Or a big fish in a little pond. If your business grew to an unimaginable size, would you be happy?

I work for myself because I have an authority problem.

I have a problem with other people in authority. I have a problem being a part of someone else’s dream. I intend to never work directly for anyone else again, because I’d sooner be a big cog in a small machine than the other way round. Repeat clients are fine and dandy, but when building things for them starts to feel like a job I know our working relationship needs to be adjusted, or it will surely be doomed. This is all just context.

My most pressing side-project is a fledgling e-learning system that’s been in the works since June 2012. It was my friend Leon’s idea, his baby. He roped me in during the neonatal stages, needing someone to turn his Excel spreadsheet prototype into a web application. I became the technical cofounder.

Now, after almost three year and a couple of minor pivots, we’re approaching a release date. We aim to go live on 1st April 2015, and I’m nowhere near ready; still plenty of slog work to do. I’ve got some busy weekends ahead of me.

Three weeks ago, on the night of Wednesday the 14th at a coffee shop in Nottingham, Leon introduced me to Jonathan. Jonathan is new to me, and we’re vetting him to see if he’ll make the ideal third cog in our small machine. He’s a maths teacher and YouTuber, adept at producing polished and professional instructional videos that look like they weren’t just hacked together at a moment’s notice. Leon, for all his abilities, isn’t a details guy – he drags projects forward by weight of charisma, and isn’t afraid to throw money at something when his own capacities fall short. Our second meeting with Jonathan is tonight, and whilst we haven’t come to a decision yet I expect that he will join Leon and me as shareholders as we push to get this thing off the ground. Jonathan possesses the three things that I was specifically looking for: (1) he’s good at what he does, (2) he’s ambitious, but (3) his temperament is closer to mine than Leon’s. That last one was an important feature for me; I need all the help I can get when wrangling Leon’s focus. I need someone who isn’t easily distracted.

Over the years I’ve grown used to Leon’s ways. His ability to pitch ideas and recruit acolytes to his cause has to be seen to be believed. He possesses a nucleus of eager energy akin to a force of nature, and because it isn’t an act – it’s just him – he can’t help but use these skills to full affect. In turn, when in his presence my subconscious automatically adjusts my own enthusiasm levels, compensating for the overload in the room, and thus I become more cautious, more naysaying. In my head I instantly halve the number of any target subscribers/revenues/profits/growth percentages he quotes at me, not because I don’t believe they can be achieved, but because I’ve been bitten by other people’s excited estimates before, thus I now refuse to let myself join in anyone else’s excitement. I’m constantly primed for a horrible fall.

On the Wednesday, towards the end of our two-and-a-half hour discussion, the clock edging towards 9.00 p.m., Leon fervently stated his expectations:

I’m certain that, by the end of our first year, we can have 10,000 sign-ups, at £100 per time for a 12 month subscription, giving us a £1 million revenue.

In my head I halved this to 5000 sign-ups. I then halved this again to 2500. I then halved it again.

Call me dispassionate, but I set my sights much lower. If we get one thousand sign-ups I’ll be over the bloody moon; that’s my target, for the first year – ten times that seems ravenous. If we do reach that number I’ll happily admit that I doubted its achievability all along.

Toying with the notion – if the business did turn £1 million within its first year we’d have to expand operations. The three of us would need to bring on staff immediately, to produce improved video content, to translate learning materials into multiple languages, to write website copy, to manage social media interaction, to evolve the web application…so from the topic of Leon’s ambitious targets the discussion turned to our longer term aspirations for the enterprise. If, against the power of my pessimism, it’s a roaring success, how would each of us expect our roles to morph as the business grew? Leon, as The Big Boss, would still be at the helm. It was his idea, and whilst he may lack overall business acumen I’ll take his hustle any day of the week. If Leon is the marketing cofounder, and I am the technical one, then Jonathan is the content guy, and if we’re to grow successfully then we’ll need him managing the creation of videos and documents that can prise open the enormous foreign markets that both him and Leon have an eye on. Leon plans on having a business ultimately worth £100s of millions…if we execute things right. I told him that I’d happily sell up if we reached a £10 million valuation.

What I didn’t tell him was that I’d actually accept a disposal at much less than that value. On the current face of it, pre-launch with precisely zero paying users, I’d accept a future valuation of £1 million. I say this because, to me, the enterprise isn’t mine. Pre-Jonathan, nominally I have a 40% stake, Leon the other 60%. This business is both Leon’s and mine – his core concept having been developed and brought to life by me – but I still feel that I’m just a cog in his machine. This is fine right now, drifting along as the big cog in the small machine, but if, and it’s a big if, it becomes what we hope it might, will I want to be the big cog in a big machine?

I don’t know if I’m built for big business, even if it is mine.

How to Write a Roll-On Plan

The momentum from an intense product roll-out needs to be harnessed. Here’s how

In my last couple of articles (which can be found here and here) I detailed my sketchy performance at Android mobile phone app development over the last few years. One of the points I raised in the post-mortem piece was that we, as a team, would have benefited from having a “roll-on” plan in place, which would have come into play once we had finished our initial launch – once the roll-out of the initial version of Indoor Cycling Coach was complete. This sparked a small question in my noodle: what the hell is a roll-on plan?

Googling the phrase “roll-out plan” resulted in pages upon pages of results. Not so for “roll-on plan” – I do believe I have accidentally coined a phrase. I thought I’d run with this, as it’s not every day that I come up with something that has relevance to anything, so the concept of the roll-on plan interests me and is worth exploring. Over the last month I’ve been experimenting, and have come up with a format for a roll-on plan that I’m finding very useful. Writing a roll-on plan is certainly not for everyone, and for large organisations it’s probably a waste of time, but in skeleton crews this could prove helpful.

So what the hell is it?

Let’s start with its progenitor; the roll-out plan. A roll-out is a staged series of tasks and activities, leading to the ultimate result of a product or service being released to a customerbase. The roll-out also includes all activities that are part of the bedding-in period that dictates product acceptance. With this as our definition, a “roll-out plan” is a plan for delivering a release of a product or service, including all the elements that must be put in place for acceptance by the customer/marketplace/end user.

As the roll-out itself fully involves the settling down of the bedding-in period the roll-on plan is nothing to do with the current release-in-progress. The roll-on period is that which comes after a product has settled and nestled into place. A synonym for “roll-on plan” could be “what will we be getting up to next?” The roll-on plan’s main purpose is to ensure a swift and painless re-allocation of people and resources to their next project(s), so that everyone has at least an idea of what they are working on next. It also forces the planner to confront the resourcing conundrum early, which will mitigate later bottlenecks. In a large company the notion of a roll-on plan would be ridiculous, but in a tiny outfit the planning process tends to be more freeform and transient, thus even a diminutive one-page document can make an enormous difference to the rebasing of the business. It’s there to provide a brief mission statement to re-ground the team after the intensity of the roll-out has abated. The roll-on plan should be written at the same time as the roll-out plan – the two documents can be considered siblings. It is no use trying to write a roll-on plan after a roll-out has commenced; you won’t have time.

It’s going to be a short document, probably around half an A4 page and certainly no more than one page, taking the form of a series of headings under which you will write one or two sentences. The headings I’m using are as follows:

  1. Project: state the next project the team will be working on.
  2. Purpose: state the business case for doing the project.
  3. Size: state the expected end date of the project, or a simple description of its scale.
  4. People: state who is involved in the next major project, and what their responsibilities are.
  5. Resources: state what additional resources will be required to make this project happen.

If several projects are to be undertaken simultaneously each heading will need several subsections, briefly describing each project under Direction and Purpose, followed by estimates of the overall time burdens required under Size, and assigning various people and resources to them under People and Resources.

Project
The best way to sum up the future direction of the business is to state the next major project or projects that the team will be working on. This could be the subsequent version of the current product, a revamp of the corporate website, a consulting job, or a whole new product line. It could be development, design work, or even feasibility studies for the next version or a separate product. It might include one or two details regarding the further development of the current version.

If the answer to the question “what are we working on next” is “support” then I’d question my business’s momentum. In business I am not an advocate of constant growth, but if I can’t conjure an inkling of an idea for a future project then I am directionless and at the mercy of my competition. It is a given that large quantities of time will be committed to “support”, so this isn’t a valid answer. The smallest fragment of a kernel of an idea for a future product or project is worth writing down, just to get the brain juices flowing, even if the release of the resulting product will be years away.

A reasonable answer to the question “what are you working on next” might well be “consolidation”, which seems similar to “support” but is an entirely different beast. It’s not unreasonable to have to dedicate lengthy time to restructuring and reinforcing your business practices after a major product roll-out, especially when working with a skeleton crew. It doesn’t seem to be very forward-thinking, but establishing a foothold is as an important task as any. I’d still recommend that the roll-on plan pays lip service to future product ideas, even if these are to be worked on after a lengthy period of consolidation.

Purpose
The project description you stated in the previous section needs justifying: what is the point of doing it? What benefits will it bring? No need for a massive in-depth analysis, keep it short and to the point.

Size
If possible estimate a completion date for the project. If this can’t be conjured then state the size of the project in the number of weeks of work, or even in just very simple terms (small, medium, large). If using the latter method then ensure you keep the size estimates across different projects consistent, so that one person’s idea of “a small project” doesn’t equate to another’s idea of “a bloody massive project”.

People
Detailed project and product brainstorming/planning has no place in the roll-on plan, but you can begin to plan who will be expected to be involved. Answer the question: “who will be involved in the next project, and what are their roles/responsibilities”. If you’re writing a roll-on plan that highlights several projects, and the same person’s name keeps appearing across all of them, loaded with responsibilities, then you know that you’re going to have capacity problems with their time.

Resources
If you have some clarity over the next project to be undertaken then answer the question: “what resources will be required to make this happen”. Possible answers could include additional hardware, the purchase of a JavaScript framework or a plugin for the integrated development environment. The resources plan might be less about what needs to be bought, and more of a feasibility investigation, an example answer might be:

To build the reporting software we’ll need a JS framework that supports rich graphing capabilities. We currently don’t know anything about this, so we need to research and compare various technologies.

Conclusion

For a little perspective, let’s toss a few quotations out there:

Plans are of little importance, but planning is essential.

— Winston Churchill


Plans are nothing; planning is everything.

— Dwight D. Eisenhower


No battle plan survives contact with the enemy.

— Helmuth von Moltke the Elder

It is not expected that your roll-on plan will come to pass precisely. You might scrap a proposed future project in its entirety, new work might materialise, staff might leave, or you might realise that the new ultra-powerful PCs you thought you needed were never necessary. For me, the purpose of the roll-on plan is twofold:

  1. To focus my mind now: to force myself to have a conversation with myself and my team, to confront decisions that will have to made at some point in the future anyway, and will benefit from the extra time being mulled over.
  2. When the time comes to start something new it forms an instant briefing document for the team, so we can regroup and reorganise quickly. Working in small teams is all about adaptability and speed.

The problem we had at Twelve Gauge Software was that after the roll-out period finished we didn’t have a clue what we were expected to do with ourselves next. The roll-out of the initial version of Indoor Cycling Coach was a protracted affair with no real end – after the app went live on the Google Play store we had a measly few hours of blissful peace before the bug reports and feature requests started to drift in, and we simply bared our teeth and flung ourselves back onto the mounting workload, exactly as we had been doing during the development of the product. With no clear delineation the roll-out drifted and mutated into an ongoing support phase.

We knew there’d probably be a second version at some point, but we never really tried to plan this in advance. The notion of actually planning a follow-up came up when we started to receive feature requests that were clearly beyond the remit of the current version. If we’d sat down together for a brief discussion before the release of version 1 we almost certainly would have raised the question of their being a premium version of the app, and this question would have been quickly answered: “yes, there probably will be”. We would have at least had our expectations primed for the work ahead of us. But we were too busy getting swept up in the excitement of the approaching roll-out to give it much consideration. This discussion should have happened long before the roll-out itself even began. If I’d known the things then that I know now then I’d have arranged things differently, but I suppose that’s the point of hindsight – it’s always 20:20.