Growth Methodologies in a Distributed Environment

 

Screen Shot 2016-04-08 at 15.40.36.png

In 1986, my mother climbed “Passo dello Stelvio”, by bike after ten months of extensive training. I was six, and I happily followed my mom throughout her adventure. My grandfather was a biker; my uncle is a biker and my cousin too. For quite some time I thought I was supposed to become a biker too. After my mother had gone on top of that mountain, I decided to remove the sidewheels from my little bike, and I fell many times, getting bruised, and frustrated.

I ultimately learned how to ride my bike, but at some point, I realised it was just not my thing. I like bikes, I have one, they are beautiful objects, but riding bikes at a professional level it’s not for me.

My job was supposed to be something else: many years later I became a growth engineer, and started working at Automattic, the company behind WordPress.com.

One of the well-known thing about Automattic is that we don’t have meetings, we don’t have offices, and the company is fully distributed. Everybody works from home, wherever home is. We are mostly located in North America and Europe, but we are a global company that covers the whole world and all the time zones. We love to work asynchronously; we don’t need to be all awake at the same time to get things done.

Combining being spread across multiple time zones, with the open vacation policy we have, we developed asynchronous ways to keep the productivity wheel spinning. We are productive but not hierarchically organized, and the first message we get when hired is: “Welcome to the chaos”.

When I was hired, I was coming from a very different experience; my previous employer wanted all of us to be at the same place at the same time and had a very strict organizational pattern in their mind to make sure everything was carefully organised. Productivity was nowhere near to optimum and not even close to the level we reach at Automattic.

I specialised in growth methodologies, and when I joined Automattic, coming from a very structured work environment, I had a little struggle in trying to apply my experience in a chaotic environment. There were no deadlines, and everything happens just because the best people in the industry are offered a fertile ground and not too many rules.

Let’s start with a the question I get all the time: “what is growth?”.

We hear this word a lot, but the real meaning is not easy to grasp. Like many of other terms in this industry, the sense of it mutates according to the context. Trying to have a unique definition is quite hard.

Growth = Optimizing the product/market fit

Having a company with so many products, and so many stakeholders, growth cannot just be limited to a single key metric as many startups can afford to focus on.

We have millions of people who rely on us to improve their lives. Our job is to support them along this journey. Growth focuses on making sure that the decisions we make have a positive impact on our stakeholders’ lives: better UX, better support, better internal tools, better satisfaction, better revenue.

Among many things I do and many tools I use, the following three are the most important:

Business Analytics

An example of a Business Analytics tool is Google Analytics.

It offers great insights on what happens on your online premises, giving the opportunity to track, measure, compare different key metrics, mostly tied to the behaviour of you online visitors.

But the measure of visits, traffic, clicks, are not the final goal, they are key metrics, represented on a tool, that contribute to the success of your business.

Always keep clear in mind the separation between metrics, tools, and goals of your business.

Split testing / Usability testing

These testing activities are relevant parts of my day-to-day work. I submit our designs to real people, so to find out how to improve them before hitting the market. I also perform split testing to measure with reasonable precision the performances of new designs, flows, and interfaces.

Data-Informed Decisions

Most of the decisions we make as human beings are wrong. Deeply wrong. It happens at the personal level when we chose a restaurant, food, clothes, etc.
It occurs in business when we sign a bad contract with the next partner, we approve the next feature on our website, we select the next design on our product.

Every time you hear the sentence “I feel this is gonna work for sure”, guess what, it’s wrong.

My job is to tell you how small that “for sure” is.

My job is to provide enough information to the decision makers, so they can limit the amount of risk of every decision, maximizing the potential impact.

All of this it’s science. And we all know that science requires to be strict. You cannot just make science without having a rigorous process. Otherwise, it’s Voodoo.

The main struggle I had, when I joined Automattic, was to find ways to implement strict procedures, to a chaotic environment. There were strong constraints that were not possible to change in either way. The math behind an A/B test does not accept compromises. The distributed nature of the company cannot be altered.

At the same time, there were problems to solve. There were decisions to make quickly. Way worse that a wrong decision is not to make a decision at all.

I had to find ways to provide test results on short time frames, without letting biases and errors pollute the results.

Cerulean

Screen Shot 2016-04-08 at 15.41.51

This is the team I’m part of. There are five of us: Brie, Dan, Mike, Ran and I.

We almost cover the whole time zones: Ran lives in Israel, I live in Vienna, Mike lives in Virginia, Dan lives in Philadelphia, and Brie lives in San Diego. Our days are organised to allow us to be efficient.

Let me show you three peculiar methodologies we refined over time so to get the best out of our efforts:

Weekly Sprint

Our sprint method requires us to define what we are going to do within a week, breaking down our job into tasks that can be completed before every Friday evening. We use Trello to keep track of what we have on the table, and we came up with a nice “size chart”.

Screen Shot 2016-04-08 at 15.45.28.png

Our size chart tells us that only three types of tasks are allowed on our boards:
– XS: tasks that require less than two hours
– S: tasks that require less than one day
– M: tasks that require less than two days

There is no Large, no extra-Large, no specials. With our weekly sprint, we only allow tasks that can be completed in less than two days. Otherwise, we risk to get stuck and create bottle-necks. If we have something larger, we need to break it down into smaller bites.

Weekly Growth Hangout

Growth hangouts include people from other teams. As a design team, we collaborate with others to get things done. The weekly growth hangout is made of three parts, with a very strict schedule.

  • 10 minutes to discuss test results from the previous weeks
  • 10 minutes to pitch tests for the upcoming weeks
  • 10 minutes for general discussion

It may look that 10 minutes are not enough to discuss things in detail, and that is exactly the point. The purpose of the hangout is to make sure we are all on the same page, but details must be discussed in a written form on an internal blog, so to allow everybody to chip in, provide feedback and contribute with informed opinions. That can only happen asynchronously, allowing people to think, do research, elaborate ideas.

Screen Shot 2016-04-08 at 15.45.41.png

During the general discussion, we iterate on the hangout format as well. The company evolves very fast, we hire very fast, we change very fast. We cannot afford that any of our processes gets stuck on the same format for a long time. We need to improve continuously every single thing.

This is an example of our testing board, where we keep track of the current, next, and past tests.

Meetup project

We live in different countries and a few times a year we get together, and we work in person for a week. Our team had a meetup a few weeks ago in Vienna, and this is our most recent meetup project.

We wanted to try the process described in the book “Sprint: solve big problems and test new ideas in just five days” by Jake Knapp.

It takes a design team from zero to MVP in five days. It requires a lot of post-its, a lot of stickers, and a lot of wall space. The perfect project for a design team.

Screen Shot 2016-04-08 at 15.46.35

Following the book, we created the blueprint for our next product. At the end of the week we ended up with a prototype, we tested it with real people.

It had a few points of failure. And that was good, because it happened early on in the design process, not when we went to market.

This model helps you to fail at the right time, on the right things, so to iterate and increase dramatically your chance to succeed.

We also had sessions of guerrilla testing, getting real people on the street, trying our mobile interface and giving us real-time feedback.

Takeaways

Make

Make things, don’t indulge in talking about it.
It’s way better to making things fail, than not to make things because you are afraid to fail.

Learn

Take notes of what works and what does not work.
Use your failures as your platform for learning new things.

Iterate

Don’t start long processes, with the unrealistic expectation of success.
Always plan in short iterations, changing direction often, adapting to the new things you are learning along the way.

Up and right

Screen Shot 2016-04-08 at 15.50.26.png

Growth looks like a straight line, but it’s not, it’s a complex path.
My mother did not get on top of that mountain with her bike spending a lot of time discussing her project with her friends. She trained every single day for ten months. And that was the only way to make it.

Some people make a living as professional bikers; other people use their bike to go to work. Others ride their bike at the park on Sunday. People can have different goals and different needs, but they all have to learn how to ride a bike. And they all will fall many times.

So when you read about growth methodologies, don’t think that they apply only to Google, or Amazon, or Automattic. Don’t spend too much time on forums trying to find the best design process, or the best A/B testing tool.

Take something you can immediately apply to your business, try it out, iterate, and make it yours.


Posted

in

by

Comments

4 responses to “Growth Methodologies in a Distributed Environment”

  1. […] try new things and the support from colleagues to execute projects well. Luca writes more about the growth methodologies on his […]

  2. […] I’m speaking at WordCamp Split about growth methodologies in a distributed environment. Don’t miss […]

  3. […] WordCamp Torino 2016, last April, I presented “Growth Methodologies in a Distributed Environment“. Check it […]

Leave a Reply

Your email address will not be published. Required fields are marked *