Liam Gooding

Yesterday we launched Virally at Fruitbowl Media, an online tool to allow content marketers to capture leads using social networks as opposed to webforms, and then creating a viral promotion effect once a lead engages with the content.

As a product, we think Virally is awesome. But thats not what im here to blog about. What’s more significant about virally is that we launched it following a “lean startup” methodology we’ve been adapting for future Fruitbowl products (and client products too).

We launched a product, from idea to public Beta, with payment processing, inside 3 weeks. Here’s how we did it.

Step 1: Beer

The first step in our process was pen and paper strategy meeting, and we managed to do this a lot more effectively with Beer. We had already been given the problem (or customer pain) from an existing client, and so we knew there was some degree of demand, however the definition of the MVP (Minimum Viable Product) was a long way away from certain, and so we needed a strategy meeting away from code IDE’s and Google, lubricated by Beer.

I’m not saying that every senior consultant meeting should include alcohol, but I am saying that discussing the problem witout the constraints of software limitations or competitors, and with just a “slight” catalyst to pull us into the realm of fantasy, we were able to come up with the idea of a hosted app that sat silently in the background, inbetween the end customer (the “lead”) and the website (the “marketer”).

Originally we’d opted for a library that the client could include on their server, maybe selling it as a licensed download, but by making a few sacrifices in vanity URLs and a little app branding, a remotely hosted app would be the best solution.

This session provided us with:

• A product format - hosted web app
• A name - Virally
• A requirement for MVP
• An agreement on timeframe - our target was always under 3 weeks
• A rough list of other apps we thought we should look at, only from what we already knew (no googling yet!)

Step 2: Complete A Trello Board

At Fruitbowl, we’ve “evolved” a loose implementation of lean software development that relies quite heavily on an amazing app called Trello. With a matrix of priorities, possible task status’ and task types, we end up with something that loosely resembles an Agile spec for MVP.

No written documentation. No 8 page written “Functional Specification” (how much money gets wasted on those things scares me…). Just half a day of the product owner and developer sitting side by side around a Trello board.

One important consideration about working with this board is that you should always assume that it can change on any day (and it does most days!). Because of this, it’s important for the product owner to break down every user benefit as much as possible to keep the whole development truly agile.

Also, as with all agile processes, you need someone who is removed from the development (ideally marketing background) to be critically strict about determining the MVP. It’s not absolutely essential that the full board is prioritised, as it’s a continual process. But in true agile sense, you need at least 1 days worth of effort (for each developer) prioritised at least so that they can get started while the product owner continues to prioritise the rest of the board.

It sounds a little complicated, but essentially all you’re doing is asking the hard questions. Questions such as:

• Does this feature add to proving our core value proposition to the user?
• Will that feature get used now, or can it wait for a week?
• Will anyone see this feature yet?
• How will they use that feature if they aren’t yet using this feature?
• What will attract them towards this feature?
• Can we deliver this feature by integrating someone elses API?
• Do we need a developer API yet?
• What’s the expected load on this bottleneck, and do we expect to need speed optimisations yet?

After a morning of sitting down and completing a trello board and adding initial effort estimates, we now have the following:

• An ETA of the first prototype to send to our first private Beta testers
• A rough priority of functionality towards a strict MVP
• A real-time management snapshot which can be review at any time

Step 3: Build a Prototype on Staging

Because we were extremely critical of our MVP, we should be able to get a prototype for *almost any product* in around a week. And that was true for Virally, and that’s exactly the target we had in our methodology plan.

We launched this behind a password protected staging environment because it was important to walk any private beta testers through this product, either in person or over a Skype call. This is important for a few reasons:

• A prototype to an MVP doesn’t consider UI and there certainly isn’t any “hand holding” walkthroughs
• There may be known bugs and we don’t want to taint the Beta tester’s opinion by accidentally exposing them to these. A product owner will know these quirks, and how to avoid them
• The product owner knows the specific User stories or scenarios that this prototype solves, and can “hand hold” the tester through these
• Again just to iterate, prototypes *should* look embarrassing. If not, you’ve done something wrong. So keeping that embarrassment inside a known group of private testers is a good idea!

Step 4: Integrate Payments, Either Real Or Fake

We have a rather controversial component to our internal lean startup process. And that’s including a payment processor, or at least simulating one, in our MVP.

This is controversial in many lean startup discussions, but I want to quickly explain our reasoning here.

A MVP exists to test the assumptions, and an assumption is based upon a value proposition of the product.

e.g. “Virally is a tool to collect leads for content marketing campaigns that uses social networks instead of webforms, and marketing managers will pay for this as it helps them to increase conversions and work independently of their IT department”

Now I hate the situation in the UK for credit card handling, and I literally keep begging the Stripe guys to bring their Merchant Account + Gateway + Recurring Payments + PCI Compliance Handling + API stack to Europe faster, but until that time, setting up Credit Card processing for a UK startup is a bitch.

6-8 weeks waiting for the merchant account to be setup, plus a setup fee with the merchant account, plus a % transaction fee on the merchant account, then a monthly fee with the gateway, plus a % transaction fee with the gateway, then a monthly fee with a recurring billing provider, plus sometimes a % transaction fee with the provider. 

And that doesn’t even include the man-hours required to integrate with 2-3 sets of API’s. Paypal offer a slightly better integration, but are extremely pricey and not amazing from a user point of view.

We’ve integrated GoCardless into Virally, which is actually a UK only processor who provides a Direct Debit interface. What’s beautiful about GoCardless is their pricing (1% with a maximum charge of £2.00) and it takes 2 lines of code to integrate!

To give an impression, we integrated all account upgrade/downgrade functionality, including webhooks, and then added GoCardless on top, in 2 days.

Step 5: Create Lean Launch Page

Why is it important to include a launch page in a Lean Startup launch? Let’s assume your product is amazing, and as soon as users give it a bit of time and start using it they’ll be hooked. But that’s irrelevant if you can’t convince them to signup in the first place!

With a blog post about you on Techcrunch (because someone in your team used to work at facebook) this might not be *as* important - but for the rest of us, we need to present some form of landing page, with user benefits, screenshots, a logo, and a sign up button.

Before with our prototype, we didn’t mind embarrassing interfaces. But now, a bit of professionalism will help strangers to feel more confident about investing into your product. And even if you aren’t charging any money (yet), don’t forget you’re still asking for an investment of *time* from a user to sign upto your product.

So invest a little bit of effort into a semi-decent logo and a single splash page. If you’re launching an iPhone app, do the cliche thing of putting a few screenshots in rotation inside an iPhone mockup - go on, you know you want to.

The Virally launch page is a single page with a simple screenshot, 4 user benefits, a pricing table and some FAQs.

It doesn’t convert great, but it converts better than a blank page with a signup button.

In Summary

And so there’s the stripped down process we took to launch Virally. I’ve been writing and rewriting the process for our internal 3 week incubator for around 6 weeks now. Our new CTO and Partner in Fruitbowl, Matt Spence, laughed at me the first time I said we’d aim for a 3 week programme. After a while his mockery became “well we can try” and now I think it’s safe to say he’s well and truly bought in and singing it’s praises far and wide!

3 weeks is significant for many reasons, but most importantly from a business case for Fruitbowl Media:

• We can be reactive to market changes
• We can avoid or reduce huge tender processes as we only need a smaller budget
• We have a known cost package which can be taken “off the shelf” by both clients or investors
• We can deliver the methodology as consultancy to other agencies or internal companies
• We get to start work on the next project sooner, which is important for an agency selling itself on rapid innovation

Anyone interested in finding out more about the methodology, how it can apply to an upcoming project or how we can deliver this as an agile training workshop should drop me an email: hello@liamgooding.com