Building products with engineers is the most scalable way to drive organic growth. I will introduce briefly the disconnect I found between marketing and product/engineering from my past consulting experience, cover the basics on how we setup autonomous and independent growth teams and ultimately dive into how we drive growth by building products with engineers. In the “building products” deep dive I will give an overview of our framework to generate products ideas from search data, provide some tactical examples on how building custom CMSs allows us to quickly validate MVPs, why we invest in infrastructure to scale acquisition and what we learned so far by building products that solve customers problems across the entire funnel.
← All talks 
Grow Growth Turing Fest 2018
Scaling Organic Growth by Building Products
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hi everyone. Thanks for being here, first of all. It's a great honor to share what my team and I have learned over the past few years while building products that help us to scale growth. So my name is Fabrizio. I work at Ansowise in the organic growth team.
Before we go into building products for growth, I will just tell you a little story to get some context about what I mean by building products for growth and also tell you some requirements that we learned being fairly essential in order for us to do so.
So back in twenty fourteen, I was about to become a first time buyer, and similar to the roughly sixty thousand people that every month managed to get their mortgage approved, and at the same time I was consulting for a bank through my agency that I was working for, working on their mortgage product.
And funny enough, like, found myself into this situation where I was really passionate about getting a mortgage, and at the same time, for necessity of work, I had to figure out how to attract customers and drive growth through this particular product, which is a mortgage calculator.
As you can see, there's a big disparity between the two point five million people that every month dream to get a mortgage and the sixty thousand who actually get it, but at the same time it's a great opportunity. What more amazing than capturing those two point five million every month as a way for a bank or any kind of financial institution to sell a mortgage.
And that's pretty much what people see on Google. There is a bunch of ads. There is a product by Google, which is fairly mediocre. It's not like, as a first time buyer, had no idea on what to do with that tool, probably giving me a simple calculator that would have been more efficient.
And then there's a bunch of organic results of banks and money saving, extra money supermarket and people like that that rank for that kind of stuff. What I realized fairly soon enough by working with my client and that particular bank back in time is that there was a big disconnect between people that were building the mortgage product, the people that were building the calculator, which is kind of the entry product to drive growth in that particular space, to the point that my client forgot to put the calculator on
the page that was on Google appearing for mortgage calculator. Like, that was probably the worst scenario, but easily fixable to some degree. On the other front, the product that we had was not as terrible as the BBC one, which has been discontinued, still ranks on Google, and funny enough, there must be some kind of fetish why people still love this BBC product.
We were doing user testing two weeks ago, and the customer tell us that the most trusted place that you would check the rates would be BBC. I was like, okay, fair enough. Like, our our product wasn't as bad, but equally what we realized is that working with this particular bank, there was no way their engineering team would have been agile enough to build a product that was any better.
And my days was pretty much like fighting between the phone and the email to figure out what to fix next. And the reason why is because the product organization was not talking with the marketing side of things, and then engineering was sitting somewhere in the middle of nowhere with no ability to impact on this particular product.
That's pretty much when I kind of got a little bit bored and gave up and realized that I would never have been the calculator that would have helped me as a customer as well to get a mortgage, that was given any kind of good experience, decided to join TransferWise.
At that time, TransferWise, yes, was working still in finance. At that time TransferWise has roughly over a million of customers, now we have a little bit more. We were already transferring a good amount of money between countries all over the world, and more particularly we were helping people to save a great amount of money every day compared to what they would spend with their bank.
At that time, transfer wise, we were driving and still today is primarily thanks to word-of-mouth, and the reason why that happens is because we work hard and relentlessly on giving customer a product, a core product that is 10x better than alternatives. When it comes to price, speed and convenience of the product, we had a pretty **** **** and we still do PR operation going on to tell everyone what we're actually about, to let customers know that we can help them save money.
At that time we received a good chunk of our funding. We started all paid marketing activity that weren't that sustainable. Now they are. We are a profitable company. On the back end, the result of it was mainly this that you can see. Our growth was growing, our organic growth was doing perfectly fine because of people telling their friends, but the only thing that these guys were doing was then Google and TransferWise as an outcome of that and started using our product.
There was no organic growth at that time, apart from word-of-mouth happening, and that's pretty much when I joined. The reason why I joined, and something that is really important in order to actually achieve some of the stuff that we did later was the setup.
So I joined TransferWise because of the autonomous and independent teams that we have. Each of these teams focus on a KPI that makes a difference to our customer. In practice, it means that we have all these independent units that focus just on one KPI.
When it comes to growth and marketing, we focus on problem awareness, conversion team on the onboarding experience, currencies team on getting regulated all over the world and transferring money, experienced team on removing the worry from our customers so that they feel confident in trusting us with their money, down to our variety teams who looks after our evangelical customer and word-of-mouth.
Initially, you you join a company, everyone tells you that you're going to be your own boss. You don't quite believe that from the very day. I kind of learned that that was true probably two months down the line, when one of our quarterly meetings, when we were presenting one of our products, our founder Christo came to that meeting and quite bluntly commented to my idea to launch a new product as a **** idea, saying that that was not going to add any value to our customer,
and it was just a trick to get some traffic in through search. And, you know, at that point, you would put your nice idea on the corner, try to come up with a new magic trick, but people came to us and say, and to our team, Don't worry about that, right?
This guy is just the CEO, you guys are in charge of building that. So this is really important. And the other bit that is quite essential for us to operate in the way we operate is having the full stack team within our own team, because no one is really autonomous unless you have all the resources to do what you meant to do and what you plan to do.
And going back to my experience before not being able to be the best mortgage calculator out there was mainly down to us not having the right engineers in the team and not having an organization that was structured in a way that we were able to do that.
So the way we operate is we have a full stack team. Everyone in the team that we need in order to drive and move our KPI sits within the team. And that is really important because one thing that I didn't know when I joined was, you know, I kind of understood it, but I didn't quite understood it, in essence, was our mission.
So our mission as a company is to make money transfer instance, as fast as sending an email, convenient for people to use and eventually free, which is okay for customer, that's why they love us sometimes, but it's not quite the same for marketing.
In any organization you would expect that you keep pumping money into marketing and then revenue will grow. It doesn't always happen, but in our case it's even harder because we have this thing called mission zero. I think this year we dropped price in our core market at this once, sometimes twice, So we end up operating in an environment where our lifetime value of the customer continues to go down and force us to increase the scalability of our operation across growth, which is really exciting.
I wish I kind of knew that on day one, but now it's kind of the reality in which we have to operate. And just to give you a little bit more context of what my team does, what we do, we build products that solve customer problem, which is not the core transfer wise product, in order to drive growth.
And we use search, first of all, as a distribution channel to get traction into this product, but also we use search as a proxy to understand whether customers do care about this product. And over the past three years, what we end up building is two platforms that we use to launch experiments.
Four standalone products, we added more than three million pages to the site that when I joined was just the homepage. We have one point six million visiting every month, and we send out one point five million notification again every month. This is not just like, you know, these are useless number for the sake of you today understanding what we are doing, but it's just to show you that some of this stuff works and some of this stuff is finally making me happy because I don't see the flat line
anymore that was boring me to death. And the concept is pretty simple. We build products that start acquiring traffic and we build pages that start ranking in Google, and because of that we acquire customers. At this stage, you probably have some context about what I mean by building product for growth, roughly, thanks to the mortgage calculator example.
You have some idea on roughly how we operate as a team, which is essential in order to achieve some of that. And the other thing is don't be afraid by the fact that your company, at your stage, whatever stage you're at, might not have the resources, might not have the setup, because in reality, even though we got a good amount of funding, we run with a pretty skinned team, and we are fully sustainable and our operations are quite cheap, actually.
The only caveat to that is we invested from day one in getting full stack developers into the team, and we invested from day one in building our own technology, which otherwise would kind of limit you when it comes to scale. So, like, as a first step, now we go into what we learn, like, by building this product over time.
And the first step that we kind of cover is how we build platforms and tools to launch MVP as fast as possible. So what we do, we use search, pretty much, to understand what product to build and how to build them. When I first started was, again, me and three for stack engineers, so I didn't have quite enough time to figure out what our user wants.
I had no clue about what TransferWise was going to drive in terms of growth, like I just joined with no idea about the company. So we built a set of tools that help us research and clustering what people are looking for, and clustering this data to the point that we get fairly good confidence on what are the product features, what are the products that if we build we will be able to drive traction and growth.
You can do that in a very easy way, and we have done this most of the time just with a spreadsheet after you have all that nice and categorized data. You could use more advanced stuff, and we are testing some of this stuff with natural language processing API, but it's pretty much simple.
Excel will do the job. Once we get a sense of what the product is about and whether people actually need this product, we have some other little tools that help us estimate the opportunity, so we make sure that we don't build something that is really competitive and impossible to rank.
We talk to customers, something that in my past experience I wasn't allowed to do. So, I was working for a company that didn't allow me to speak to their customer, which is quite funny. And now that we are over a thousand people at TransferWise, we not only talk to customers as a team, because our time is limited, but we talk with colleagues who regularly do.
And this is really important because it helps us to make sure we don't go on the crazy side of business stuff that people don't want. So, we validated this because people search for it, we validated that it makes sense because we talked to them.
Once we do that, we are at the stage in which we say, okay, let's launch an MVP. For that we build a platform that helps us launch in this test really quickly. And this is really important because it helps us play with our style guides, helps us play with all the kind of tech stack that we have, and we get to the point where in literally minutes if we have assets and just an image, can launch a product MVP.
This is our first version of price comparison. It was nothing more than a landing page with an image on it. It doesn't have to be a product in order for you to validate that customer wants it. An image did the job and gave us confidence that that was the right thing to do.
And we do this at scale. We don't stop there, like saying, okay, launch an MVP and we launch something that looks like a product, but it's just an ACCI landing page, with a little bit of functionality. We take people in the team and we kind of industrialize that process by having people that continuously launch tests ongoing, to the point that we got a little bit we were a little bit too much freak in controlling how this operation was going.
We had an analyst in our team looking after how this launching operation was going, looking after how much we were publishing on this platform, but that helps us to realize exactly what was the limit. There was no way in which we were going to scale organic growth, in particular, and build acquisition, that was what were missing in growth at that stage in time, by working with the CMS, right?
Our growth was limited by the number of pages that people were publishing in the CMS. These were not products, we were just AKI pages that were not solving any real problem. But it helps us to get confidence on what to build, and second, it helps us to have very strong product pipelines.
Because of this activity that still goes on to date, we already know roughly what they're going to build in three years' time. So the challenge now is not necessarily what to build, what top line problem are we solving for our customer, but the core challenge is to get engineers and grow the team so we will be able to ship the stuff.
Because going back to my original example, what I realized in my past experience is that it's not about the budget that you have, it's not about whatever operation you're running, but it's down to the ability of the team to ship stuff. The more stuff your team ships, the more you will be able to grow.
So at this stage we have, I would say, an army of MVP that generally end up doing well as an MVP, but obviously don't scale. It's just a page that pretends to be a product in the best case. The next bit that we do is to scale this product.
So we take the MVP and we figure out how to push as much traffic as we can into this MVP. And the reason why our platforms that we built initially to publish this MVP are really important for us to do that, because we can reuse that code base to some degree, and we get a good sense of what this bunch of unstructured pages would look like on the code side of things, to the point that people, when they're frustrated of not having engineers, they start hacking this platform and they start
injecting code and hoping to simulate what the product will look like, down to the point that engineers freak out and tell them, know, if you do it again, I'm gonna lock everything that you will see and you will not publish a single page again.
Crystal asked us, is this fast enough? Like, it's probably a terrible, arky way. And that's when, as a team, hopefully doing a good job in hiring, that's when as a team we realized that there's no other way that we can get out from that apart from building a real product.
And the first thing that we did on this front was simply building an extension of our core product and make sure and building acquisition into our core product, which is pretty obvious if you work for, let's say, a hotel, a metasearch company, but there are so many companies where you don't build acquisition into your products, TransferWise as well.
You can install the app after your friend tells you that we do this service without even touching our landing pages, without touching the website at all, right? So you don't touch our acquisition channel apart from virality. So the first thing that we did, and we're still doing, is to make sure that the product imagine how many routes we are available to send money imagine how many countries we are available imagine how many new products now we serve business, we have a new multi currency account.
So all the stuff our team couldn't keep up at building pages on a dumb CMS. And equally, when we were scaling globally, what we built, we started to invest in infrastructure that was helping us to do this faster. Right now, we don't have to wait a week to when we go live in a new country to get stuff live in terms of acquisition, but we just need to, after translators are done through crowding, we can press a button and all our applications will automatically launch this translation done by real people.
And then, following up on our price comparison initial product, we realized that there was an opportunity to give a product that was helping people to compare money transfer providers, so we invested quite heavily in modularizing these products, so going from the landing page to building a service, a bunch of services that communicate with each other.
We have a data collection service, there's a price comparison engine that runs this stuff. We have a set of front end widgets that then play, they are spread across the website, and so we can ensure that from the homepage to our landing pages to the actual product, standalone product itself, to our success page where you go then and invite a friend, we are able to leverage this product.
And this is really powerful because, again, imagine seven fifty routes in seventeen, eighteen countries, We have like thousand providers that we would love to compare against. There's no way, even though you build some marquee functionality into like a content management platform, that we would be able to scale growth in this way.
With this setup, the day that we add one provider to our data collection service, we automatically generate a great set of pages that help us to scale growth, particularly faster compared to what you see in the previous chart, where basically the number of pages that we were putting out to acquire a customer were never passing the number of traffic.
The traffic was never passing the number of pages. And this is really important because we don't have to rely on people to build our acquisition, but our products end up building the acquisition by themselves. To the point that it's not just about acquisition.
So our primary challenge was back in time, within growth, to build acquisition into our growth like stack, but now that we have these modular services, we can leverage these at all the stages of the funnel, to the point that when you complete a successful transfer with TransferWise, we are able to tell you in real time how much money you saved against your previous provider, and people that do see that type of data end up inviting seven times more friends than what they would generally do if
they're not aware of their savings. Similarly, it happens on evolving the technology that powers some of this tool. We are reliant on search to drive initially traffic to this product, but the more this product becomes mature, the more we can stop depending on Google, stop depending on search to drive our acquisition, but we get people to install this product and then receive notification.
This is our rate tracker alert where people get notification about exchange rate. They're able to install this app and keep going without actually us having to worry about do we actually rank or not. So that's stage number two, and now the last phase.
We are at the stage pretty much where we have a bunch of MVPs that are barely products. In the best case, they are landing pages with some AKI solution. We then figure out how to scale acquisition against this product. And the last step is to make sure we actually build products.
Because up to now, our ability and our time spent on that particular product is really poor. Often, going back to the way that we drive growth, summarized, it's pretty easy for us to build pages and to drive growth traffic to this product. What wasn't easy is to actually drive customer, which is what we eventually want.
And so, here you have a summary of pretty much what is our process. Up to the point where we scale acquisition, we barely invest in the product itself. So it's still the very poor MVP. And we get people coming to our quarterly session saying, oh, again, this crap product, are you guys gonna fix it?
And often we don't, until we are confident that the volume that we have eaten in this product will help us to run tests fast enough. Sometimes it's just a matter of time for us to build conviction of what problem we are solving for that given product, and once we get to that stage, and we are right now with a couple of them, that's the point where we have enough understanding of what problem we are solving with this given product, and that's where we invest in the product itself.
And second, we invest on what you would generally call conversion rate, but in our case we call education. And the reason why we call it education is because we realize that the role of our growth team is, yes, to acquire new users joining TransferWise, but that doesn't take us very far.
We spend a bunch of money in paid marketing trying to achieve that, and we still invest in that. But the core problem that we're trying to solve as a growth team is education of our customer. In UK alone, I think seventy one percent of the people are still not aware of how much they're being charged when they transfer money abroad.
So our idea is that, you know, yes, we're going to care about, like, acquisition and that's the user acquisition, that's what we aim for as a team, but our core problem to solve for all the products that we build is this one, is to drive awareness of the hidden fees that banks charge and to help people to compare and shop around.
That's key goal that we have. And that's the stage where we, as a team, go back to any of our products in our portfolio, in this case we're talking about price comparison, and we heavily invest time to speak to customers, to the point that we go to their essence and build conviction, both with data and known, on what actually we're trying to solve.
We got enough traffic to run this test at scale, to the point that we are confident that we're doing the right thing. And then, going back to the actual problem that we're solving when it comes to price comparison, about telling people in real time how much they're going be in charge with their particular provider, which seems obvious, but some banks don't even tell you how much money you're going to get until you actually open bank account B and figure out that, oh wow, this is how much they're sending me.
So we invested quite a lot of resources in actually solving that problem and reverse engineer payment API, reverse engineer bank accounts, to the point that now we have a product that is not just acquiring a bunch of traffic that is helpful to have, but is really solving a problem.
It's the only place where you could probably find some of these bank rates and data in order to compare them live. It's probably one of the most transparent, to the point that if Western Union or anyone out there is cheaper than us because they're running promotion with tight customers, again because our mission in this case is not to just drive conversion, but is to educate customers, and we have seen that that over time pays out.
And we got to the point where finally, or at least, you know, it's an ongoing process, I'm not sure we ever got there, we get to a product that is really good. And we, you know, our colleague come to our meeting without being embarrassed of us calling ourselves guys working on product, and equally our customers, like they give us feedback to the point that they understand what we're trying to solve for them.
And because of the work that we have done before into modularizing and building a standalone version and a scalable version of this product, we get to the point where a lot of people are able to see this product and then are able to become Transverse customer.
So, just to recap, probably the most important thing in order to get started is the team. If I have to look back at my experience and being at TransferWise for about three years now, nothing would have happened if from day one we wouldn't have had an empowered engineering team within growth.
There are many other companies like Skyscanner and a few others that are playing with similar concept, right? Probably on their side they're on what we're doing on steroids. We are kind of primary school kids in this space, and we, like every team, freestyles a bit as well.
But this is really important because that gives you autonomy, and there are no excuses for building crap stuff. And then, once we have that, and once we're confident that the team has the resources to do that, number one, we build an environment that helps us, and anyone could do it.
That's why you don't need particularly having engineering resources. Any CMS could kind of do it, and then the more you want to scale probably will be harder, but you could. So we build platforms and tools that help us validate ideas as fast as we can, and as many as we can.
Sometimes it's not necessarily about the speed at which we validate ideas, sometimes it takes us even three months to get to traction, to understand that an MVP is worth time, but it's the number of the MVP that we launched that gives us confidence on what to build.
Once we are confident that it is worth engineering time, we try to scale it and get to the point where, some of our server will barely hold that traffic, and that's really healthy because it fleshes out that this is just a **** product at this stage.
And then once we are confident that there's acquisition built in, the product has got enough customer that care about it, that's when we invest in product. Probably not helping them from the very early day, but that's when the point where we go head down and figure out what product are we actually building, what problem are we actually solving for this customer, And, you know, and when we do that, we realize that that actually drives growth more than anything else.
And that's that's pretty much it for today. Thank you for being here. I hope it was helpful. I'll be around for the next day or so, so if you have any question, feel free to ask. Thank you.