From an idea to a physical product: 5 things we learned from building a global debit card
Following the launch of our TransferWise debit Mastercard in 2018, we’ve taken the card to 30+ countries on four continents, had over a million cards ordered and have lots of expansion and feature plans in the pipeline.
And, while the growth of the product has been stable, there have been some bumps in the road. For the first time, we’ve dealt with areas like manufacturing, physical stock management and shipping, while growing a team and product fast.
At TransferWise, we like to retro projects — this means reflecting on how they’ve gone, what we learned and what we could’ve done better. Expanding on my previous blog about the journey of launching the debit card, I wanted to share some of our learnings from the process of launching and growing the card itself. There are things we’ve done right, a lot of things we could’ve done better and some great learnings we can take away for next time.
So, what did we learn from launching a global debit card product?
Building a new product, growing it geographically, entering new markets, dealing with new regulations, the ins and outs of the payment industry plus working alongside partners. This journey has taught us a lot and here are a few key learnings:
1. Launch gradually and remember that customer feedback is king
As the card product was something new for us, we wanted to do a gradual launch in the UK as a starting point. We launched quietly in beta and listened closely to customer feedback and NPS comments to pinpoint issues, questions and the features that needed prioritising. ~20,000 customers participated in beta testing the product and unsurprisingly, we learned a lot. At TransferWise we use a lot of customer user testing sessions. In beta phase of the card, we talked to a lot of opinionated early adopters which helped us to get useful insights.
Initially we were wary of how the card would be accepted and adopted by consumers. There’s virtually an infinite amount of merchants and point of sales stations around the world. It turned out that getting to the desired acceptance level was actually not our biggest challenge. With acceptance and decline rates the majority of problems and solutions have been technical. And when problems arise with card usage, we often reach out to acquirers that are rejecting the card to figure out the reason faster. Both merchants and issuers desire highest possible acceptance rates, so fixing these problems is always a win-win conversation.
The main learning for us was that the card itself was working rather well, but we needed to improve the onboarding experience before the actual launch. So we were able to smooth out the process before we went live avoiding distribution errors and delays.
Launching gradually and listening to feedback allowed us to focus on the right things before fully launching the product.
2. Expect the unexpected when you’re building something new
Building any product from scratch brings its own surprises, and our card product was no different.
We began working with new partners and card companies. Our first addressable market was EEA (European Economic Area) and we set up card manufacturing in the UK. The facility had a good location, we could conveniently visit it from our London office and it was suited well for rolling out a pan-European product. In the early internal alfa phase when our CEO, Kristo Käärmann, wanted to order the card we realised that our manufacturer actually didn’t have special characters like the letter ‘ä’ in their machinery.
Indeed, it turned out it’s difficult to print names and addresses outside of the UK onto the card and the envelope. And when issuing cards to customers in different markets (take for example markets like Germany or Hungary with a high use of special characters), such details matter.
It was a learning experience for the manufacturer too. We worked together to revisit character sets of different countries and wrote a script to run through all possible characters we might need globally. This test framework has helped us to ensure that our card embossing and card envelope address printing is ready for the next markets.
What started as a problem has shaped our understanding of the industry and let us fix things as they come along.
3. Start from scratch to protect your existing infrastructure
When thinking about how we were going to build the card, we anticipated lots of usage, high volumes and the potential for technical stress on the system.
In our TransferWise ‘send money product’ we already had powerful financial transaction processing rails. However the nature of card transactions is different — they’re smaller in value, more frequent, quick, different seasonality and the list goes on. Even though it was much more time consuming we built our card domain from scratch and as independently as possible from the rest of TransferWise systems. Although uptime and reliability is always a priority for us, we knew that for a card product, customers will be even more sensible in regards to any downtime. So we only used touch-points which were inevitable — for instance using our Balances feature from the main system.
It took a lot more time to design our tools and systems from scratch, but the long-term benefits and lowered risks for our overall product were worth the wait. We detached parts like clearing and reconciliation and financial reporting flows.
Instead of building debit card system on top of any existing legacy, we used the card to roll out new better solutions to old problems. For example, when building online payments feature for the card, in collaboration our Security team, we redesigned how our Two-Factor Authentication (2FA) works under the hood. We tested and launched it with our MasterCard SecureCode implementation and then updated the authentication system also for the rest of TransferWise for regular logins.
Designing something new is a great opportunity — we realised that what’s optimal for our main product might not be optimal for the card. And the time invested in developing card technology was also used to improve the rest of our systems.
4. Want sustainable growth? Scale your teams with the growth of the product
Since launching the card, the rapid growth of new monthly users and transaction volumes have been validating our proof of concept. Unsurprisingly, the growth of the product has brought along lots of feature requests, challenges and maintenance work. A year in we realised we hadn’t forecasted the growth of the team proportionally and that the team at that time was severely overworked.
We’ve since grown the team to a healthy size and structured the Tribe into various teams to allow them to focus on the most important areas. Finding the right people to join the team takes time and we’ve learnt to constantly monitor team capacity and think ahead to prevent the same situation again.
In my previous post I highlighted how valuable it is to have different Product Engineering sites around the world. While it’s not a hard prerequisite, it makes launching cards in new markets noticeably easier. We issue cards in more countries than most other global issuers. It’s hard to imagine how we could do it in such a short span of time without our “global core tribe with split regional ownerships” organisation model.
5. Communication is key
This one might sound obvious but we learned a lot about the importance of communication when working in cross-team and cross-location settings.
Building and launching the card was a huge cross-team effort including Product teams, Analysts, Legal, Compliance and Fraud teams and Marketing and PR. We had a launch date we were working towards and there was some added pressure as our PR team had secured launch coverage for those dates. As things came up the nearer the launch, aiming for the date caused fatigue in the team. The learning here was that we need to communicate better cross-team about potential changes or delays to our plans.
With our tribe and teams located across multiple offices, we learned to manage cross-location communication too. We understood better how to make everyone feel included and creating a sense of unity in the team. We added biweekly tribe calls with updates from each team and dedicated US, European and Pacific updates rotating between each member of the team. These gave us visibility of the big picture, as well as insight into what each sub-team was working on.
This year has been different. Before the Covid-19 pandemic, we always focused on bringing our teams regularly together with their overseas teammates. Traveling to other offices or our partners’ sites is integral part of our culture. Usually tribes meet up at quarterly plannings and there’s always someone visiting and working at another office. Working together helps creating that sense of unity in the team and makes also the remote collaboration much more effective.
For the obvious reasons, travel has been on hold for a while now, but the tricky times of 2020 didn’t stop us from achieving set goals for the year. Now 2021 is looking exciting with many launches and features ready to be shipped soon for our customers. Hopefully the world heals, becomes a safer place again and maybe we can return to our normal way of working as well (fingers crossed!).
Was this journey all worth it?
The short answer is, yes. At TransferWise we’re not afraid of challenges and are always looking for the learning or bit of insight that helps us solve a problem. It’s this drive that makes every product we work on better each time.
P.S. Interested in working with us? We’re hiring! Check out our open Engineering roles here.
Stories from the Engineering team
Solutions Engineering at Wise
It describes exactly what my team and I do at Wise, which is great, but it can also be interpreted...
How Wise reduced AWS RDS maintenance downtimes from 10 minutes to 100 milliseconds
The problem In Wise, we have followed a microservices architecture, where we have about 500 microservices, but also 300 production...