Fast. Good. Cheap?

I usually work in a tactical writing mode: documenting new features and workflows in an agile development environment, or writing special content for training or specific customer requirements. I’m very comfortable working at a tactical level. But in the iron triangle of fast/cheap/good (where you can pick any two), going for fast/good incurs a cost that’s very easy to miss for a while: losing sight of the strategic goals…or failing to create them at all.

“Now” outweighs “sometime later”

The problem with strategic goals is that they’re often difficult to define precisely. Further, in a small, fast-moving company, it seems like they’re constantly subject to change.

Which makes the whole “strategic” thing very easy to ignore. If I have four topics, release notes, and a customer notification to write by Wednesday, that’s going to outweigh a task to plan for the next six months to a year.

Seriously: A year? How can I possibly predict what I’ll need in a year?

Experience, that’s how

Yes, “I don’t have time right now” is just an excuse. A pretty valid one, but it won’t help me when that year rolls around and I’m not ready to support 5 products in 15 languages while reusing 50% of my content.

Which are all fantasy numbers, since I haven’t even gotten that far in my strategic planning.

So let’s make a plan.

Start with the basics: What do I do?

I need to provide documentation for multiple products (yup, it’s now two instead of just one). I need to reuse content (documentation, videos) between those two products. The documentation includes descriptions of workflows (not just features in isolation), use cases, and some reference info.

(Quick aside: Am I the only one sick of step-by-step task topics? Maybe because I’ve gotten so much negative feedback about numbered lists making tasks look more complicated than they are, where a more narrative style makes them seem easier, and makes the documentation seem friendlier and less formal. But that’s another topic full of random thoughts and anecdotal evidence.)

So: Multiple types of written documentation, videos, content reuse. And I need to be able to repurpose some of the content for training (slide decks, handouts, material for exercises).

What do I need to plan: How will I meet those requirements? Can I do it with my current tools, or do I need <link>a new doc tool (or tools)</link>? Research that, come up with a list of requirements, a list of tools, and find the best match (features, cost, ease of use).

Second part: Customer support

I’m also responsible for customer support for our products. Again: Two products, with the possibility of more; one product has users on two (very different) versions.

I’m currently providing 8/5 support (8 hours a day, 5 days a week), except in the case of urgent issues. At some point we’ll want to expand that to 24/5, or even 24/7, and I have to figure out what we need to do to make that possible (“hire more people” is obvious, but I think I’ll need to include a few more details than that).

If I move to a different documentation process, I’ll need to include the support ticket-to-documentation pathway in that. Right now that pathway is 1) flag ticket as a doc issue; 2) identify the documentation to be updated; 3) rewrite that info and add it to the documentation.

But if I’m not the person handling the support ticket, I need to set up a notification system that tells the doc team when a support person has flagged a ticket as a doc issue. Fortunately, I can do that right now.

…3 minutes pass…

Done!

(And I feel a little silly, because I have no excuse for not doing that before now.)

Third: What do I need more of, and how do I do it?

Two big ones: Videos and in-product help.

For videos, I need to formalize a process of identifying video-worthy topics, and then building a workflow to go from written to video content, as well as a method for building accurate time estimates for that.

In-app help is going to require research: How much do I want to add to the product, how much can be displayed meaningfully, and what’s the best way to work with the engineering team to make that happen (in terms of file formats and scheduling issues).

And beyond that…

I skipped translation/localization. Having a doc tool that outputs to HTML will help with that. And having separate voice and video channels for the help videos makes that process easier (although timing is still a bit of a pain). The “who?” and “how much?” questions are still there, but if I can give them files in a non-proprietary format, I think the whole process will be easier (and might reduce the “how much?”).

Summary: What I need to do

So for my plan, I’m starting with What Do I Do, How Do I Do It, How Can I Make It Better, and What Future Requirements Do I Need To Plan For. I need to find a balance between tactical work and strategic planning, but I’ve been trying to get that right for years.

But not doing this means that I’ll be relying on the same processes to get me through another year with more products, more support tickets, and more requests for non-documentation content (for training and marketing, off the top of my head).

Whoa there! Am I breaking the triangle?

But Neal, you say, aren’t you trying to get fast, good, and now cheap, too?

Er…sort of? Fast is always going to be part of what I do, as long as engineering works in an agile development cycle. And I’m not going to compromise on good (I said good, not perfect).

Which means that it’s Cheap that needs to bend a bit. But that doesn’t mean hiring a team of writers or support agents. Right now, it means having our subject matter experts spend time writing up workflow guidelines that I can turn into documentation (also the primary support resource). So getting them to do not-cheap tasks now will pay off handsomely in the future. And that’s another argument that your doc team needs to make.

Advertisements

One thought on “Fast. Good. Cheap?

Comments are closed.