Tips for an i18n launch with HubSpot's Product Program Manager

Hello reader! This is a part of a series of interviews about localization and internationalization which spans thought leaders from Shopify, Google, and Pinterest, among others.

If you've enjoyed the series and found the issues relevant to you, hit the button below to register to receive our playbook when it goes live. 

Robert Bauch, Product Program Manager at HubSpot 

So far in this interview series, we’ve looked at localization as a project delivery department for translations, a governance team for international activities, and as a driver of globalization strategy.

But I wanted to take things back to square one. There’s a time in a product’s life when it wants to go abroad – or rather, when a commercial team wants to take it abroad. And suddenly, product and engineering have a lot of work to do.

That process is internationalization, or i18n, and it is painful, and important to get right.

I was speaking to Robert Bauch, whose tenure at HubSpot had coincided with their growth from one to 40 countries. (HubSpot has also grown from $78 million to $1.731 billion in revenue over the last decade.) 

Employed in 2013, Robert was doing much of the internationalization work to prep the product for its arrival abroad. Today, “I’d be hard pressed to say if there’s a country where we don’t have a single customer”, he said. 

I wanted to hear the story of how HubSpot got started. 

Starting out: building a cross-functional team

It was 2013.

“We’d just opened our first non-US office in Dublin,” Robert recalled. “The first forays were UK&I, because they were the easiest… but we wanted to drive into the German-speaking market.”

In the room, “the COO, our CEO,” said Robert. “Both of them were very interested in this… We had our MD of Global Sales, and then our VP of Engineering, who was my manager at the time. We had our German-speaking marketer, who was the Director of Marketing. And there was me.” 

Also, come to think of it, other departments as well. “Sometimes legal,” Robert considered. “It was very cross-functional.” 

That, argued Robert, posed the biggest challenge set and the most important thing to get right.

For starters, it’s hard to know how to structure the i18n team.  “I started out working under product operations, and then I got moved into engineering,” said Robert.

“I think that engineering is actually the right place to have it. This is just my personal experience – but for me, something did change when I started to report to engineering. We made decisions faster; we were aligned with the people who were doing the bulk of the work.”

“The other thing is, there’s a good balance to be made about having somebody who’s non-technical, and making sure that there’s alignment between organizations, as well as a counterpart to help think through the technical bits, and understands technical culture.”

Bringing that team alignment in was absolutely vital for HubSpot. “I think one of the main challenges you run into in a company is that sometimes teams can work at cross-purposes,” said Robert.

“What’s the value to the customer? That question starts to bring everybody into alignment. At the end of the day, if you’re not building things your customers need, neither of those matter.”

“It was something we had to learn – we didn’t have it right out of the gates – but once we had that in place, it makes the overarching effort so much easier.” 

“We had such a great relationship with our customers we knew that we had to understand what they were saying – where they saw the value they could bring to their own customers.”

In fact, for HubSpot, the customers helped not only to align teams, but set the i18n agenda in a detailed way.

“They were the key beta participants helping us narrow down on quality in the early days, and helping us set priorities for what to localize. We leveraged them for translations – especially for really small volumes of content on the app.”

“It really gave them ownership – it was one of our biggest successes.”

Putting the technical work in place

I also wanted an end-to-end account of how the internationalization team had developed. Did the way that HubSpot – and Robert – understood the problem change?

“HubSpot’s not different from other companies”, said Robert. “From a business perspective, it’s easy to think [about i18n] as a cosmetic problem. It’s when you understand more about those markets, potential users, you start to recognize that it’s an architectural, technical challenge as well.”  

By cosmetic, did Rob mean translation-only?

“It can be that… it’s also how deep in your organizations you’re thinking globally,’ said Rob.

“One of the early pushes was driving towards the needs of our global product. We need to have sales. We need to create pitches. It stops becoming just about content… more about, “how do I create a full experience for this particular market?” That’s when it becomes technical.’  

I asked whether HubSpot suffered from technical debt in i18n.

"I think we were lucky,” said Robert. “We were already doing some deep, code-level work in the stack… so we could build onto the stack in a way that took internationalization into consideration.” 

Robert’s advice for technical debt was to try to avoid it.

“It’s something where, if you’re confident in your product, you’re going to get to that [internationalization] point. A lot of modern code frameworks allow you to externalize content from the outset, even if you’re not going into languages straight away – that’s the big debt you would carry.”

(For fellow i18n beginners – “Content Externalizing” refers to taking copy embedded within code, and replacing it with a token which refers to a multi-language file. You need to do this for every line of content in the product. This is a dull and repetitive task which, says Robert, “‘no engineer wants to do, engineers hate doing it. You’re looking at a screen, to see what words show up, testing to ensure you get the right string, pull another file, create another token.”)

But for HubSpot, said Robert, “There were three stages of maturity. First, we got really tight with a [translation] vendor. From the very beginning, they were helping to supplement the translations. That part of the quality process we took on early was finding a good vendor and sticking with them.

“The second part was again leaning into our partners before we launched more broadly to help us narrow down the important pieces… like tooling. The partners gave us a really good understanding of where we could focus on quality, provide ease of use, and go from there. 

“The third one was to identify key languages where you can ensure that a user experience is high quality internally. We had certain languages to invest in – like Japanese, German. HubSpot does localization for over 50 languages, and a complete app for 10. 

“With Japanese, you have to have somebody who is ingrained in Japanese culture and language to have an app which is perceived as high quality. You don’t necessarily need someone in Finnish. We don’t have an internal Swedish speaker, but we offer a Swedish UI.” 

Better Quality, Everywhere 

Which brings us to quality, the final big challenge in i18n. Robert thinks about the quality challenge predominantly in terms of scaling. 

“As we got the product internationalized, we could stay fairly close because we were operating at a really small scale. That made it easier to keep the quality tight… over time, we needed to ramp up the volume of content we were pumping into these markets.” 

In time, marketing and product content split their workflows and their processes. “The needs of scale began to separate us… and then also the quality requirements started to change in your product. We had a very different threshold for quality.”

Marketing copy needed to be “polished to the max” said Robert; product needed to be more consistent to specialized language libraries – and much faster.

“In product, we needed to keep moving. We were pushing code to production hundreds of times a day. 3-400 times a day. We needed [a quality process] to keep up with that.”

“We tried to thread a line…. to have a localized product which wasn’t detracting from the experience of customers, but which allowed us to go quickly. We did some experimentation around laying over a Google translator or a proxy translator, but then realized it was below the level of quality we were shooting for.” 

In the end, Robert pioneered the Babel system. Babel – which is no longer “crazy novel” said Robert, was built to help achieve continuous localization which did not slow down the developers.

“We were still in a waterfall translation management model. We couldn’t send translations out, hold somebody pushing their changes to production, for days to weeks later.” 

“A couple of companies provided open APIs, to get content in and out of their system. We started to think… we know how our dev cycle works. Can we plug in continuous translations on the fly?”

“Babel allows us to get code to translation and get it back within minutes for the machine translation layover. And it very rarely takes more than 24 hours to get a solid human translator on the string. And the engineer or dev doesn’t even see it happen, he or she just sees the code come in, and they pull it into their repository.”

For continuous localization, said Robert, “add machine learning as soon as you can. There are so many tools and this was ten years ago – the landscape wasn’t as robust as it is now. Add machine learning and automation to your process, because you can leverage so much of the work you’ve done in the past to ensure quality with speed in the future.”

Parting advice on internationalization

It’s better to allocate the time and effort into i18n up front. “The sooner you can get internationalization treated as a first class citizen within an organization, the more smoothly it’s going to run. If you start to scale, and there’s long times between questions getting asked and answered, trust gets diminished. At that point, you start to incur debt, because you have problems that are going unsolved. 

And “don’t be afraid to look at what other companies are doing. I have to say, when I was learning I knew literally zero. 

“The willingness for other companies to talk to this is very high – it’s such a cool challenge. Every company is thinking this, but the community in general is actually quite small. Then you take a subset, who will talk about globalization at the technical level…. These people want to talk about it. The problem has already been solved! It’s about finding the right combination of solutions to fit your use case.”

“We were super fortunate to get a localization leader named Nataly Kelly to come in, who became our head of global marketing for localization. She’s a wealth of knowledge. I had people from Airbnb reach out to me… we went and toured LinkedIn and talked to their whole localization department. I was also lucky to work with Eric Richard, who was the key engineering advocate in the process.” 

I had come to Robert expecting technical advice. But I was struck by how much success in i18n depended on the same things as in other areas of business – leadership and good communication.