Monday, October 3, 2011

BrandFu: Distilling the lessons learnt

Over the last few months, yours truly has been a little busy. We recently built and launched a product in the US called BrandFu. I'll let you go look at the site for details on what it actually does.

Along the way, I have also been doing a bunch of reading up on different aspects of our Internet economy. Jeff Jarvis' books was one source. What Would Google Do? is actually a fantastic  look at the way the Internet (and not just Google) has changed the face of our economies and how to leverage the same techniques as the big players in that space to excel at what you want to accomplish in your business. I also just recently bought another book of his as soon as I heard it was available on the Kindle; Public Parts. I haven't read it yet, only just started the intro, but again, it seems like a must read for anyone involved in online economies.

Another addition to the reading list is The Lean Startup by IMVU co-founder, Eric Ries. Again, not finished it, but another good read that does echo a lot of the same thoughts as the other two books.

So with the references out of the way up front, I just wanted to highlight some of the big lessons learnt from our own experiment launching BrandFu into an unknown market, as well as what these books point out.

1. Be prepared to move out of your comfort zone

The first thing to be aware of is that the modern age requires that people can multi-task. These days, if you want to be considered a valuable asset to your organisation, you need to be able to do more than just be an engineer. More than just a designer. You need to be able to dip your hand into marketing and customer service as much as you do actual coding.

Sounds like this has been said before but its surprising how many people, including myself, struggle to move out of that comfort zone. I wanted to develop a product. Dealing with customers was someone else's problem. What I didn't realise was that without customers (via marketing), we could get no feedback (via customer service) which meant we could not develop an application that best suited their needs. That customer interaction was vital to the engineering.

2. Release early. Even if you think you're not ready!

This is one of those scary aspects for developers. We want perfection. We don't want to push code out that might be buggy and feature-poor. But as I said above, you need customer input. You could spend 12 months in a silo developing what you believe is an awesome application, only to have customers come to you afterwards and tell you that it doesn't do what they need.

For BrandFu, we did an experiment first. We went from a very simple Proof of Concept just to see what our stumbling blocks would be, to a rapid 3 month development cycle. And then we released the product to a South African customer-base, leveraging off of SYNAQ's existing clientele. Sure, it was buggy, had features missing we thought would be awesome, but by releasing as early as possible to an admittedly smaller audience, we learnt a ton.

First of all, we learnt that the stuff we thought would be the most popular feature, banner campaigns, actually was secondary to the signature management aspect of the product. If we had siloed ourselves we would have made the banner and campaign management portion of the application absolutely kick ass, but people wanted to use the signature management stuff more. Releasing as early as we did pointed this out to us. We were able to shift focus rapidly and early.

3. Stay Agile! Especially in the first few months

One of the key things we tried to do was to remain as agile as possible. We have a ticket tracking system, JIRA, which is an awesome piece of kit, but we found it slowed us down. While developing our Minimum Viable Product for BrandFu, we were still getting constant feedback from our South African user base. This meant that when new information came in, we had to analyse it, determine what we would do it about it, and then implement. JIRA was slowing us down.

We ended up with the team sitting in one room, around one table with a big whiteboard. Ideas were hashed out immediately, details were scrawled onto the whiteboard and eventually erased when implemented. It meant our turn around time was hours instead of weeks. We could keep on top of changes we needed to make for our launch rapidly.

Now that things have launched and we don't have a crazy deadline, we can switch back to the more staggered process of log ticket, allocate to sprint, execute and so on.

4. Don't get attached to your code

Your customers will feedback (if you let them to of course, and why wouldn't you), and they will tell you things you don't want to hear. That feature you thought would be awesome and then people tell you they don't want it? Say good bye to it. Never be afraid of throwing stuff away. The Lean Startup even has an example of IMVU, where the product had to be altered so dramatically after launch, that it is now an almost entirely different product serving an entirely different need than it started with.

Things will change, things will be added, and things will need to get thrown away. It happens.

5. Anything else?

Sure! There was tons of things learnt. But a blog post is really not a good way to point them out here. The books I mentioned I would consider invaluable reading for anyone looking to develop a commercial application on the web. Hell, if your looking to create ANY business in this era of Internet transactions and communications, you would find good use out of the material in those books.