3 lessons learned from the establishing of an in-house growth hacking team

3 lessons learned from the establishing of an in-house growth hacking team

In this article I’m going to talk about the “hacking” part, too many posts are there for the growth:

After doing some research on this new buzzword – “Growth Hacking”, we agreed this was something we needed. The problem was, that most of the articles and experienced guidebooks about building this kind of a team were directed at content centered companies, blogs, shops etc. We needed a growth team for a well-established product, big and full of features – We needed something between an onboarding team and a marketing team.

Looking back, once we established the team, gained some losses and earned some wins, I can summarize my conclusions of the process into 3 main lessons that focus on the ideas and developing part of the growth hacking team:

“Hacking” is not about code. It isn’t code you are hacking. I repeat – hacking, is not code hacking.

We know that a crucial part of this type of a team is the existence of a well-experienced developer who knows the code – but this doesn’t mean he hacks code.

What he does, is hack the product.

You find a hack to the user journey. You “hack” through the everyday thought process of your product team who define “what is our product”. You hack thought processes, you take an idea and put a “what if” after it.

Your code, as a proud developer, as an expert, senior, veteran or a superhero developer – should always be perfect.

The implementation process can have shortcuts, they’re even necessary. You don’t need instructions, controllers and angular philosophy kind of code for each new testing feature, but your code should be perfect.

No need for “doSomthing()” named functions please, but this is necessary for EVERY feature that you haven’t tried yet. Every new feature is a test. And building huge perfect architecture for something you don’t even know how will behave, is a waste of time and money.

A growth hacking company is a company that thinks of a feature -> hacks it -> tests it -> builds it -> and improves its features. But that’s an entire different subject for a different post.

Growth isn’t marketing, its product.

This is extremely important. Especially when you “sell” the idea and need of this team to management:

A good amount of money is spent on this team, and it’s expected to bring quick results. Easy money. And where is the best place to look for this money? At the cashier’s table.

Our natural go-to strategy is the checkout pages, homepage and the packages pages, all and all – they’re just versions of landing pages and should be tested by marketing teams. If your marketing teams are busy with acquiring traffic for landing pages via facebook, twitter and Linkedin campaigns but don’t test internal pages on your website as a testing ground, your hacking team can do some tests there to inspire them – but this is not where you can help.

You also don’t need developers to create blog posts.

Your hackers are product people, not marketing:

  • They should be looking for ways to make the user convert, after using the product, but first – make the user use the product.
  • Make the user understand that he might get more if he pays, but while using it.
  • Create the WOW moment a paying moment also.
  • Look at the graphs of user behaviors while using the product and assume things they can try.
  • Go back to the graph. Make it grow, use unconventional ideas to do that.
  • The team should fail. fail and fail again.

When we just bootstrapped the team, one of our first tests, was a simple, stupid “share your results on facebook / twitter”. It is not a new, or brilliant idea.  But we needed to test it ourselves. It was fast and easy.

The success we got from this “in product” non-designed test, was better than any result we got from similar tests we ran on checkout pages than our growth hacking team did. The added value of more traffic, branding awareness, and user satisfaction is just a side dish to the sales.

We didn’t use the traffic we already had and try to convert it – we brought more, gave them good onboarding, invited their friends.

Growth hacking is not online marketing – Test the product.

Create a test, not products. A growth hacker shall not maintain a feature

Here is the tricky part for a developer:

A developer in a growth hacking team is a product enthusiast guy or a girl. Seriously, it’s the developer who will give up some dev happiness (e.g. – building some nonstandard stuff), for the sake of a great product.

But as long as a growth hacking team doesn’t have a clone team that will continue maintaining their work, it cannot assume that its features will be maintained. They should be built in the easiest way to plug out of the system once the test is over. After that, maintaining a good test that should become a feature is a company decision.

It is tragic to see something you worked on go down. Especially when it shows good results, but that’s something you need to accept, and wave goodbye to it, giving it to somebody else and just hoping he / she will treat your feature with respect and love as you did.

There are some exceptions to the above. If a test performs really well, if it’s a really simple and non-maintainable code (does that exist?) or if it is your domain (no one should have only one job in a company, narrow responsibilities are narrow-minded) – all the above can be maintained features after testing.

All in all, it is important to know that even the goals and the ways of the growth hacking team is, in fact, a hack. A good one, an out of the box thinking to do things differently than the company has been doing until now. And that’s all it is – an out of the box team, and so should be each one of its members.

And remember: First rule of growth hacking – always talk about growth hacking.