Wise (formerly TransferWise) multi-currency account with Nilan Peiris (Big Bets 5)
This is a newsletter about big bets, explored through conversations with the product leaders who worked on them. For this one, I chatted to Nilan Peiris, VP of Growth at Wise (formerly TransferWise) about their multi-currency account - a transformative bet that took the company well beyond their core product of cross-border payments, to offer an account that lets users hold, receive, send, and spend money in more than 50 currencies. Wise was valued at nearly £9bn after their direct listing in London in July.
‘I don’t believe in big bets,’ Nilan says to me, as he joins our Zoom call. This isn’t a very promising start for a discussion on the topic. ‘But one of my colleagues tells me that all my PMs use this language anyway,’ he laughs. ‘I just have a problem with management picking the bets.’
That fits with what I know of the culture at Wise (formerly Transferwise), which is based around empowered, autonomous teams. So we start by talking about how he thinks about growth instead. Nilan is passionate about word of mouth driven products, having come from a marketing and growth background, and he bakes that into their product approach. ‘We optimise for experiences that are talkable, not just changes that improve the conversion rate.’ And, by his reckoning, that means a product experience that is 10x better than what’s in the market already, or a price that’s 10x cheaper. This is how he frames success for the team, and then they’re responsible for taking the bets.
Beginning Borderless
One of Wise’s biggest bets (sorry, Nilan) was its multi-currency account. Having built a successful core product around international money transfers, this was their first big product expansion. Did it fit the mould of bottom-up innovation? ‘Absolutely. It was an idea by our Product Manager for Growth in the UK, and it came from asking people why they weren’t Wise customers.’
At the time they had only 20% market share in the UK for cross-border payments, and they wanted to understand how to capture more. The reasons people gave for not using Wise included needing to receive money internationally, not just send it, and needing to make multiple (200 or more) payments a day, which they didn’t want to have to pay for one by one. The natural solution was to let people hold money with Wise in an account.
Nilan tells me this wasn’t a bet with a grand vision up front: it was iterative and based on the needs they heard from users. ‘We didn’t start out wanting to build the world’s best international account,’ says Nilan. ‘We just wanted to solve these particular needs, and then it evolved from there.’
Despite this low-key framing, it clearly represented a big change to their business model, so I’m curious as to whether it had a leadership sponsor at the start. Nilan tells me that’s not the way they approach new projects. They operate in independent teams organised around a customer problem, and teams are part of squads, which belong to tribes. A given team can autonomously try out any idea they think is promising if it doesn’t need more resources. If they do need more resources, they can ask their squad, but each team should only have to go one level up to get investment for a new project, rather than right up to the top. This being fintech, the compliance team is often involved too, and in the case of the multi-currency account idea, helped secure an EMI (Electronic Money Institution) licence as the team began building the product.
Building the first version
Along with securing a licence, in order to meet the customer needs they had identified, they had to solve two particularly hard problems: getting account numbers for every country in the world, and global onboarding. No central bank could just issue account numbers for every country, so instead they had to get various banks to lend them a range of numbers, which was suboptimal because it created operational challenges. As for global onboarding, every country has its own legislation stipulating what a customer needs to do to be able to open an account. These were both good examples where building the end state through waterfall would have a taken an unfeasibly long time. For example securing bank accounts at every central bank in the world would have added decades to launch. Or trying to design an onboarding framework that worked everywhere globally from day one would have been a never ending task.
Their approach to reduce time to market was to build the minimum possible to launch quickly, working with partners for banking and verification where possible. And over time they reduced cost and increased quality through developing solutions in house, or integrating directly into the underlying infrastructure partners were using.
This was particularly true when they decided to add a debit card to the account, since even ‘vanilla’ card issuing is notoriously lengthy and complex. They started by issuing debit cards with different 3rd parties, like processors and BIN sponsors. But within a year and a half they were able to get their own issuance licence for cards directly through Mastercard and later Visa, and cut out the middle man. Wise also wanted to offer a user experience in which the card dynamically knows if you’re spending a currency that you hold a balance in. If so, it should use that, and if not it should select the currency you hold which is going to be the cheapest to convert at the moment you want to use it. There was no precedent in the market for this kind of feature, so pulling it off required a lot of work with Visa and Mastercard.
Scaling it up
Our conversation moves to measuring success. I ask whether they were able to tell from launch that this bet had paid off, or if there were moments of doubt along the way. ‘You’re not doing your job right unless you feel it’s not going anywhere. That’s the feeling you get if you’re building something that’s never been built before. Otherwise the problems you’re solving are too easy.’ It took a long time before they definitely knew it was working, Nilan tells me - maybe a year and a half or two years. But by then, they could measure success by the incremental amount of the cross-border payments market they had captured. I can’t share the specifics of what it was - but it certainly had a material impact on growth.
How did they make sure they were putting the right number of people on this product to support it as it grew? Rather than launching this new bet with a team of 100, the team started small as a single product team, which organically grew, till it could split into two. There was some parallelisation, when a second team took on building the card product. ‘The only constraint on growth for a team was the rate at which you can hire and onboard an engineer.’
This brings us to one of the most interesting parts of the Wise model: a fluid internal market for talent. Engineers are able to switch into projects they preferred, typically those that were growing fast with inspirational product managers. So products that seem promising flourish very quickly, whereas others that aren’t haemorrhage people and eventually die. ‘It puts a stop to unsuccessful ideas much faster than I could identify and kill them,’ says Nilan.
He gives me the example of two PMs he hired at the same time to work on two different bets: one was Wise for Business, and the other for an unnamed product we’ll call Project Toucan. Business products had been heavily requested by users from day one and now represent 20% of their total volume, whereas Project Toucan, which started with a similar level of investment, died within a year and a half. Part of the reason the bet on business succeeded was that the PM was able to inspire more people behind the opportunity, and so engineers quickly moved over to work on it.
Future bets
Nilan notes that over the past 6-12 months, he’s seen teams taking fewer bets. This is a pretty common pattern I’ve observed in scale-ups with mature products, especially those that celebrate a regular cadence of shipping (Wise sends out a big quarterly email to all their users explaining how they improved the product over the last 3 months) as teams can feel less incentivised to take on long-term bets.
Nilan shared some of his early thoughts on how to fix this: one idea is to ask some of the more experienced engineering and product leaders to take on a ‘side project’ of a new bet. ‘We’ve learned that the wrong way to get things to happen is to hire a new team and put them on it,’ Nilan says. ‘It’s always worked best for us when an existing product or engineering director kicks off a new product on the side of their desk.’ Rather than bringing in multiple specialists in a particular area, these people tend to have just enough of each of the skill sets that they need to work on new, but adjacent, products: enough knowledge of compliance, engineering, customer service and marketing to get a product out of the door. And they don’t bother with long-term business cases, but instead just focus on the next milestone they need to hit and the people they need to get there. If anything becomes particularly promising, resources can quickly be allocated to it.
It’s an interesting model, and I’m keen to see how it plays out. Perhaps the next big idea is already sitting on the side of someone’s desk, waiting to take off.
My top takeaways
Choose bets that are talkable
You don’t need a grand vision to make a big bet succeed - just keep responding to the needs of your users
If you have the right culture and processes for allocating resource, bottom-up bets can thrive without explicit leadership support
Use third parties to minimize the time to market
Letting engineers choose their own products can help accelerate successful bets and kill off unsuccessful ones