Moving to product
When working at trivago, you switched to a martech product management role. How did it happen?
Originally, I moved to Düsseldorf to take German classes. Then I heard that trivago was actively hiring and thought my marketing experience could help land a job. When I joined in 2013, trivago was in hyper-growth and went from three hundred people to a thousand very rapidly. I did SEO for a year or two and eventually moved internally to a product position because it sounded like the coolest job in tech.
Since then I’ve been loving the career. Over time I moved to working on trivago’s travel magazine, the main tool our content marketing department was using to improve the site’s natural search ranking. This led to an opportunity in Zalando, the largest e-commerce for Fashion in Europe. Zalando was automating their entire performance marketing department and since I had prior experience with Display ads, there was a fit between my skills, and what they were looking for. Martech happens to be the mix of my two main domains of expertise.
How was the transition to the product role? Was it as cool as you expected?
Oh, it went brutally. I knew product management was a mix of different things that I liked doing: communication, tech and business. In the beginning I had no team and piggybacked on other teams resources to build features. I quickly learned that product managers really do not like to share their engineers. Then we started hiring a team of front end developers and built a few applications for trivago before moving to martech. We really started with the bare minimum, just an engineer sitting with me. I was reading articles and books on product management and applying new techniques as they were needed. The learning curve was extremely steep, something I still enjoy today.
Build vs buy
Why do you think companies, as they reach a certain size, try to in-house everything?
My best guess would be to say it’s hubris! What can happen in scale ups is you start to think that everything is possible. So why not ditch Salesforce and build a copy of it “tailored for our needs”? And later down the road you realize that maybe it’s not such a good strategy for everything and you still need the occasional Salesforce or Mailchimp to take care of very important aspects of your tech stack.
At trivago it began with doing some inhouse bidding for SEM, since search is the main marketing channel in travel. It’s easier to focus on the key differentiators of a business when making these “build” decisions. Later on the logic was extended to almost all the tools — to the point where some decisions had to be reverted to “buy”, a process which is not easy since you have to shut off a tool you built and go for an external provider instead. But as it turns out, you can’t easily replace Salesforce.
A positive side effect of building internal tools is keeping a “can-do” attitude. Back at trivago, the general thinking was that you could solve your business challenges by building something. This mindset had the advantage of having us look for creative solutions to many problems raised during hypergrowth.
Companies building internal tools invest a lot into planning the outcome and ROI, but poorly estimate maintenance costs — how do you see it?
Oh, definitely. We tend to believe the workload on a new tool decreases drastically once it is delivered. But it doesn’t work that way: if we take the trivago magazine for instance, we originally had two engineers working on it, and even after its first and second redesigns, the team kept growing. The infrastructure needed to be updated, new marketing features were frequently requested, and so on. The workload even after a successful launch never went down.
My advice is to be extremely attentive to this drag along effect — teams in martech end up maintaining dozens of products and pipelines, some of which simply get outdated over time. I’m a big proponent of letting things go and focus on that part of your stack which produces most of the outcomes.
