How to halve the time it takes to write your product comms.

Being a product writer in a startup can be tough. There’s so much you can work on, and so little time to work on it. You’ve got to be smart with your time, your tools, and the way you approach your work.

With that in mind, I’d like to share with you how I’ve scaled product comms with the Notification Service team here at TransferWise. Why product comms? Because comms don’t get talked about much. Which is kind of funny! Most companies send shedloads of emails without thinking.

But product comms deserve to be designed as much as any other screen in your app. They can drive you a little mad if you’re not careful, though.

Yep, that’s me!

The what service?

The Notification Service sends out everything from transactional content to surveys. You know, those little messages you get straight to your phone whenever you spend on your card. Or the emails you get asking for feedback. It keeps all that content in its own CMS.

There’s about 300 notifications in there. While that may sound like a lot, it’s a lot less than it could be. TransferWise has 750 currency routes, a multi-currency account, and a debit card, after all.

I started on the Notification Service about two years ago. Back then, we had a much smaller scope — we were moving some emails from one legacy system to a new one. It was a chance to pretty up the copy and tweak the HTML templates.

If only it had been that simple. Instead we found that we needed to replace several email systems that were all chaotically interlinked.

After taking stock of all this, I realised that this now meant auditing, writing, and editing hundreds of emails and push notifications. Gulp. I had to get creative.

Here are three things that helped me tackle all this work. Fast.

1. Think in terms of systems

Much like a product designer, as a product writer it helps to think about the different components that go into the piece you’re writing.

In the Notification Service, that’s meant working out what each discrete part of an email or notification is, and how each of those components should be used.

For example, in most emails, we have a ‘hero sentence’; a sentence that’s in a larger, bolded type. It sits above the main body content, but below the greeting.

Most people don’t want to read a full email. So we use the hero sentence to neatly sum up the contents of an email. But as I was writing the first batch of emails, this hero sentence kept tripping me up.

An example of a hero sentence. Admire its herculean proportions.

I didn’t have a clear idea of what this component should do. And the fact that it was in such big type made things worse. What went in it really mattered.

Cue lots of umming and ahhing.

From working on other projects here at TransferWise, I knew that the first thing on many customers’ minds was the question of what their money was doing, and when it would be delivered by us.

So I drafted a few emails that followed that pattern — putting the most crucial information about the transfer up there in the hero sentence. Then, I tested that work with actual users to see how if it performed well. We released a small batch of new emails that followed this style a week later.

I followed a similar approach with the rest of the components. Then, I documented it all. And as a result, I now spend far less time looking at a blank doc and scratching my head.

Good systems let you know which pieces should go where, and what they’re best used for. Because if you’re working in a fast-paced business, you don’t have time to reinvent the wheel.

But I’ve also found that I’m no longer a blocker. I work with many product managers who can follow the system and build a decent first draft. I just polish things up towards the end. Much better.

2. Push your tools as far as possible

When I write content for the Notification Service, I try to make sure I’m not rewriting the same things over and over again.

One thing that helps me do that is our CMS. See, in the CMS, a notification can include code as well as copy.

For example, if you send money, you can choose how much you send, or how much you want someone else to receive.

You could write two emails to cover these two scenarios. But then you’ve got two near-identical emails that you need to keep track of.

So we have one email for both situations. It’s just got some code that says one line should change depending on the use case.

It can either say ‘Your transfer of 4,000 EUR to GBP’ or ‘Your transfer of EUR to 3,500 GBP.’ The rest of the email stays the same.

A secret screenshot from our CMS.

Now, this can make things a little uncomfortable in the short term. For one thing, it’s meant checking that copy flows nicely, even when bits of it change.

But it pays off. Using code has saved me and the team countless hours trawling through old templates. Remember, you’re the writer — let the machines do the repetitive stuff!

3. Make a taxonomy

If you’re working at a place that’s growing fast, naming can be tricky. Here’s what can happen:

1. There isn’t consensus around what a thing is called.
2. So everyone calls it by a slightly different name.
3. This leaks out into your product.
4. And that doesn’t always make sense for customers.

I don’t have to tell you this, but naming matters. It’s how your customers find their way around.

One way to counter this is to create a taxonomy of all the products and services that your company offers. It can be helpful to say what you shouldn’t say as well.

Then put it somewhere public — we use Confluence — and make sure it gets attention from people who work on things that customers read. Start with other writers, then move onto product and product marketing.

Anyway, I bring this up because naming really slowed down my work on the Notification Service.

Let’s say I was writing an email about verification — that’s when TransferWise needs to ask for some more info from a customer.

What do you call those documents? What do you even call the process itself? What does the customer do? What do we do?

It’s easy to get lost in the weeds.

So I started spending time with the Operations teams that would send these notifications. I watched how they worked, and did a bit of pair-writing. I could even see how customers reacted to the content they were already sending.

This really helped me clarify my thoughts, so I could start building a taxonomy of our operational processes.

A good taxonomy helps you move on from internal debates about naming, and lets you focus on customer problems instead. And that’s the fun part anyway.

So, what’s next?

With these fundamentals in place, the team and I can sail through the requests we get.

That’s let us become more proactive about the comms problems we want to solve in the future, and spend more time digging into data and customer insights. It’s all very exciting.

Even so, there’s still a million and one problems to solve at TransferWise. So if you’d like to work with a fantastic team, take a look at our careers page.

And if you want to chat about anything in this article, feel free to connect on Twitter or Linkedin.