Docs and sales and changing roles

My role is changing again, but this time back towards tech writing and support. I’m moving away from customer success, and away from direct training; but to be honest, I hadn’t been doing much of either, so it really comes down to continuing to do what I’ve been doing. Although that will probably change, and expand, in the future.

Confusing? Yeah, to me, too, but it’s not at all bad. And I think it reflects something becoming more common for us content creators.

I’m basing this (as I do everything on this blog) on my own experiences, and those of writers that I’ve managed recently. I seek out jobs with fluid definitions, where I won’t feel confined by a rigidly defined role. Which is why I’m working for a small company and handling tech writing and customer support.

We’re working on our customer success plan, but we’ve decided that we need to hire someone with actual experience in this area. I agree with and encouraged this decision. As I learned more about customer success, by reading blogs and books, and by talking to friends in the field, I realized that I wouldn’t fill the role all that well. I still have a lot to learn, and someone with experience is required.

Expanding my role

This isn’t a bad change, or even much of a change for me. I’ll be working with the customer success team that we do build (once we build it). That will give me a chance to learn the skills required for the role, as well as learning whether I want to take on that role at all. In any case, I won’t be jumping in blind.

For now, my role remains as busy as it was: We’re releasing a new version of our main product soon, and I’m spending most of my time creating user docs. I’m also going to be creating videos for those topics (which is why I’ve been reading and writing about that). And I’m handling customer support issues; fortunately, we have a low volume of tickets.

But I’ve also been asked to take on a new task: To work with our sales team to create pre-sales collateral.

Pre-what what?

Ok, that’s a big jargon-y. Essentially, I’ve been paired with someone on our sales team to determine what sort of information Sales needs to have available to give to prospects, and for their own education. This includes technical white papers, less technical explanations of the technology, a UI overview, and a few workflow scenarios and use cases.

Sounds like useful documentation, doesn’t it?

Obviously, this is information that I should have, anyway. It’s more technical than marketing material, but doesn’t go into as much detail as some of the product documentation. I’ve been using some of the training material that I created, combined with some of the product docs that I’ve written. The content that I don’t have (end-to-end walkthrough and use cases) are things that I should have, so none of this is wasted or wasteful effort. It’s just another example of creating content for different audiences.

Overlapping content means content reuse, right?

Here’s where I admit that I hadn’t anticipated this requirement when I created the doc set. Now I do have a need to reuse content, and I also need a way to make sure that every correction and update gets added to the right places.

This is when you can feel free to point and mock. “Gee, Neal, wouldn’t it be a good idea to have a good CMS and document publishing solution? Exactly the sort of thing that you hoped you could get away without having?”

Yeah…I’m going to have to work on that. It’s not a problem if it’s just me writing the docs, but add another writer or two and it will be much too difficult to handle without a real plan. Since I don’t plan on adding another writer in the immediate future, this gives me some time to research and implement a solution.

But that’ll be another post. Or maybe a series.

Back to the current job

I’m enjoying the chance to work with sales. This is another area where tech writers don’t often tread, but it makes sense, at least in my situation. Our documentation is available to customers only. Sales wants information that they can give to prospects who want more conceptual and usage information about our product. Instead of exporting some of the product documentation as PDFs, we’re going to tailor this information to this audience and requirement. We need something that addresses common questions, and that looks more impressive than standard product documentation. A sort of middle ground between glossy marketing material and the functional documentation that I usually create.

Which is not to say that I don’t care how my docs look, but tech writers focus on ease of use of the content ahead of the sexiness of the packaging. So it’s good that I’m working with someone in sales to create this content, and then we’ll work with marketing to improve the presentation.

What are the benefits?

The benefit to me is that I get to work with people who I don’t normally work with (sales), but who are an audience for the content that I create. Their requirements overlap with requirements that I’ve already identified, so I have more reason (and executive approval) to work on that material.

For the sales team, they get standardized, consistent content that they can hand to prospects or otherwise use in the sales process. And as a tech writer, anything that you create to directly help sales is a huge win. Which leads me to…

Sales and product documentation

Your documentation is a sales tool. I’ve been told this by salespeople at a previous company. When I started there, the docs were restricted to current users. I had received so many requests for PDF versions of the docs (from sales, sales engineers, and professional services), that I pushed to make the docs freely available to everyone (because of some historical weirdness, the API docs were already on an open wiki).

At my current company, the docs are again behind a login screen. Given the size and content of the doc set, and the availability of webinar recordings and white papers on our corporate site, I don’t have a strong desire to fight for open documentation right now. But the sales team knows that prospects often check the documentation when they’re evaluating a product, and the quality of that documentation is one of the factors that affects their decision.

Prospects want to see good docs; sales wants to present good docs; customers want to use good docs; and I damn well want to write docs that address all of these needs.

The tricky part is to get metrics showing how the documentation affected the sales process. Unless a prospect says, “It was the documentation that sold me!”

…and then you know that they used to be a tech writer, right?

Anyway, unless they’re that explicit, I don’t know how to come up with metrics that I can use to show how awesome I am…er…I mean, how awesome the docs are.

Let me be clear: I don’t know how to do that. I need to do more research, or, maybe, just keep working with the sales team to learn more about their processes.

More things to learn

Focusing on creating content rather than customer success makes sense for me. I’d love to be an expert at everything, and handle all of these roles myself. In fact, it annoys me that I can’t. But it makes more sense to focus on a few key areas, and learn as much as possible to expand my role.

That’s not to say that I don’t have enough to do; I have plenty on my plate right now. But I’m also tempted by shiny new skills, and some of them come in handy. Sometimes I gain enough knowledge to be dangerous (SQL and Java UI: I can create a web app with a button that sends a DROP TABLE *; command).

But I’ve identified areas of immediate interest: building useful content for pre-sales collateral, and measuring the value of that. Those two items will keep me busy for a while.

Advertisements