SaaS Writing Consultation & Production

SaaS Writing Consultation & Production

No one wants to read your tutorial, until they do

Matthew Guay

Friday, January 19, 2024

Everyone won't read every article you write. And that's good. That frees you up to write both what you want and what's most likely to rank on Google search, and give everyone the articles they're most likely to want to read.

It’d take you three years to read each of Robert A. Caro’s five books at five pages a day. Or a year and a half to read everything Isaac Asimov wrote—if you read one book a day.

Even the most dedicated fans rarely have time for that.

Write the best blog, craft the most interesting newsletter, record the most engaging podcast, and still only a fraction of your audience will read or listen to your every word. That’s fine. Your blog wouldn’t have an audience to speak of if it wasn’t for those part-time readers.

And if you did your job well, if your article grabbed their attention and made them want more, then they might come back. They might even sign up for your email newsletter if they’re really interested. Then they’ll read, sometimes, when they’re free, and with luck land on your site randomly via Google when they’re looking for a solution.

They won’t read everything you write. But that’s good. That means you don’t have to write for everyone, every time.

Where will people read? Phones are for downtime. Computers are for work time.

Ben Thompson made an interesting observation in late 2023 about Google’s search traffic. 28% of Google’s ad revenue comes from Apple’s Safari browser users—while 30% of Google’s organic traffic comes from Safari. Yet, if anything, more of Google’s revenue should come from iPhone users, “iPhone users are famously more affluent, which may make their searches worth more, and the iPhone has much higher market share in the U.S., which commands the highest advertising rates,” noted Thompson.

So why did only 28% of Google’s search revenue come from iPhones? Because people are more likely to browse, “window shop,” on mobile, then getting actual tasks done on a larger screen. “some of the most valuable keywords, like those associated with travel or insurance are probably entered when users are in “research mode”, i.e. much more likely to be using a computer, relatively speaking.” Even if they do their research on the phone, even if an ad on a search put a specific insurance company in their mind, they might not actually purchase plane tickets or insurance through a mobile browser. They’ll wait, instead, to purchase on the desktop.

That feels intuitively correct (at least for a certain generation: It’s possible the mobile-native generation will default to their phone for everything). I use the read later app Instapaper for precisely this reason: I rarely read longform on the desktop, but love having articles queued up to read later on my phone. Same goes in the opposite direction: I’ll look around for trip ideas and check prices in general on my phone, but do detailed price comparisons and flight bookings from my computer.

The data played out in a few blogs I run, as well. One had a nearly perfect 50/50 split on mobile to desktop readers, but each individual article had a different ratio. A popular tutorial had a nearly 30/70 mobile to desktop split; the vast majority of people preferred to fix problems from their computer. A popular longread that had gone viral a few times, though, had nearly the opposite traffic pattern: 60% of readers were on mobile, versus 40% on desktop.

If you’re writing long articles you hope readers will read in their entirety, best make sure your blog reads great on mobile. If you’re writing documentation and tutorials, your site should still be responsive but it might not be quite as critical.

Same thing goes for CTAs. Dynamic CTAs would be best, but if you want to simplify things, a web signup link might convert better on docs and tutorials while a mobile app download button would do better on longreads.

What will people read? Longreads when they’re interested. Tutorials when they have problems.

That also means that your longreads, perhaps, can be written with less of an eye towards Google and more of an eye towards other distribution channels.

People don’t read tutorials unless they need them. Average people, that is. Some people will be superfans and read everything, and that’s great. Your average reader only wants solutions when something’s broken, much like going to the doctor only when sick.

They’ll hit a problem, Google a solution, and ideally your tutorial will show up. They’ll follow the steps and be on their way—hopefully continuing to use your product instead of churning, or remembering your brand as a helpful one. Best case, your tutorial might be able to casually steer users of a competing product to use your product instead.

Write tutorials specifically with Google search and a frustrated reader in mind. Think about what that person will search for, what additional questions they’ll have, and write the solution clearly. Research keywords to see what else people are looking for about this topic, and if there are related, easier-to-rank-for keywords that are worth your focus. Then, write the tutorial and answer everything your tutorial promises. 

Write clearly, keep it focused and short, avoid stories and anecdotes, even rely on an LLM to help if you want (they’re better-than-average at writing things that have been around a long time, terrible about writing about brand new products and unique workarounds—and that, that’s what you want to be writing). Include full-sized screenshots, photos, and videos—your readers are likely on desktop, so give them all the detail they need. 

If writing about a competing product, include the full steps so the user can resolve their problem. Better for them to not convert to your product today than for your tutorial to leave them feeling baited and switched.

You could push the broadest of these tutorials to your users, publishing them on social media and your newsletter, if you’re certain the majority of your followers will be interested. But you could also not. Publish tutorials more quietly, link them internally to build umbrella content, share them with relevant partners perhaps to build backlinks (if you write a tutorial about an app that integrates with yours, it’s absolutely worth telling them about it). If you’re going to email them out, segment your list to send tutorials only to those most likely to be interested. For the rest of the traffic, let Google do its thing.

Longreads, on the other hand, are written for those dedicated followers—and to gain new ones. They’re the articles you should share with everyone, and share again when it’s been a while. They’re what you should include in your email newsletter, what should be featured on your blog’s RSS feed if you have one. They should get shared in any community where you think they’ll get an audience.

And they’re also where you can ignore Google—at least for the most part. You’ve got a story in your mind, a rant, an interesting anecdote, a philosophy around your industry, something you’ve got to share. The keyword data might say it’s not worth writing, that no one’s Googling this idea that’s taken up residence in your head. That’s fine. You’re not relying on Google for this one. You don’t have to kill your darlings for the sake of the algorithm.

“A blog post is a very long and complex search query to find fascinating people and make them route interesting stuff to your inbox,” opined Henrik Karlsson in an essay about why you should write more detailed, interesting, niche things, and how over time that’s the only way to build an audience. And he’s right. You’re writing something incredibly specific that you think will resonate with your followers—and the followers you want to have. Something you think might stick in their heads, something they’ll share with their friends and help build your following. It’s a contradiction to try and be interesting, to stick out from the crowd and say something unique, while trying to write for the same keywords everyone else is fighting over.

Strangely, posts you write without an eye towards Google will, if they’re popular, end up accidentally ranking for other keywords you would have never imagined writing about individually. You’ll get initial traffic from your readers, bursts of traffic if the post gets popular on social networks, and a longtail of visitors from others who reference your post and the random Google keywords.

They all won’t work. 99% of what you write won’t be popular. But the only way to get that incredibly popular 1% is to write the other 99 posts. And even the 80th or 90th most popular post will bring in some visitors, enough that over time you’ll end up with a content moat that, with luck, gives you a baseline of readers each day.

At the very least, you’ll have written things you want to reference, things you’ll link back to in the future, things you’ll be proud of in a way you’ll never be of the written-for-Google stuff. Both types of writing are important, but one’s far more fulfilling.

So write tutorials and documentation and integration pages, with an eye towards Google, optimized for readers on the desktop, distributed quietly, shared only with those who need it most, never included in your newsletter, maybe not even shared on social media.

Pair those with longform articles, dissertation, interviews, stories, theses, things you can only write by being in the arena. Ignore Google. Write for your readers, for yourself, for the social networks where your company gets the most traction. Push them to your email newsletter, post them on your networks, share them on Hacker News and Reddit, quote others and email them to let them know of your mention. Assume people will read on their phone; keep photos small, avoid anything that takes up the whole screen, optimize for reading.

You could keep them together in the same blog, differentiating only by your promotion methods. Or you could split them, with one blog for tutorials and another for blog posts (Zapier, for a while, had 3: A mainstream blog, another blog for developers, and a third with product and partner updates. Stripe spins up new entire sites for different types of content, one for their longform content magazine, another for developer docs, another for guides to starting and running a business, another for their press).

Then ignore the stats, for a while at least, and get back to writing. Keep the cadence up. One post, then another, and another, and before you know it you’ve got dozens of posts—and an outlier or two that brought in more readers than you’d have expected. You’ll keep your newsletter churn down, by not sending uninteresting tutorials to your followers every day. And you’ll get your best ideas published, when you’re not so worried about Google performance for everything you write.

Let's write your software's story, together.

©2024 Pith and Pip LLC

Let's write your software's story, together.

©2024 Pith and Pip LLC