Site icon I Manage Products

55: How to beat writer’s block

Jock Busuttil
Hand writing on old parchment / paper using quill pen

I’m writing about one hundred things I’ve learned as a product manager.

For a variety of reasons, in the last few months I’ve fallen out of the habit of writing regularly. And just as I fool myself that having a gym membership is the same as exercising regularly, so also I need to remind myself that blogs don’t write themselves.

Over the last few months I’ve been working with another set of great, challenging and occasionally misguided clients. They’ve been pleased with the results I’d helped them to achieve, and I’ve been able to learn a huge amount from working with them.

In turn, this has given me plenty to write about on the topics of product management, user research and changing the way organisations work and behave, so I’ll be sharing this with you bit by bit over the next few articles.

But as a writing warm-up – I don’t want my writing muscle to cramp – here are a few of my procrastination-beating tips for beating writer’s block.

Answer a question #

As a product manager, people ask me lots of questions. Thankfully, I enjoy answering them. And from time to time, I remember to wrench myself away from sending a massive email to them and instead answer the question face-to-face. Much better.

A couple of things usually occur to me about half-way through explaining something:

“Wow. I’d totally forgotten I knew that. Well done, brain.”

and

“Blimey. This is gold dust. I should totally write this down.”

Way back when, I originally started to blog about product management because my memory’s terrible and people kept quoting back to me helpful advice I’d given to them (and forgotten) earlier on.

So if you’re finding it tricky to fill that blank page with product management wisdom, get someone to ask you a question and answer that instead. Or have a practice on Quora.

Get someone to interview you #

While I was looking after the product team over at the UK’s Ministry of Justice, most of my product managers were contractors. Owing to the combined quirks of working in government, the ever-present risk that a contractor may suddenly decide to go work elsewhere, and the somewhat unpredictable nature of project funding at the time, it was entirely possible I could lose a product manager with as little as a few days’ advance warning.

Red tape and bureaucracy meant that the time needed to replace a product manager was about 3-6 months for a contractor and even longer for a civil servant. I likened the ongoing recruitment process at the MoJ to hitting a bullseye on a dartboard positioned six months in the future. (For balance, I’m told it’s getting better now.)

With a possible product manager evacuation at any time, I wanted to make sure that we had product handover notes that were always up-to-date, but without making them unwieldy and unmaintainable. Thus, the product bible was born.

My product bible was the bare minimum of information that one product manager would need to hand over to another about their product:

And then a bunch of links to more detailed information, product backlog, roadmap and so on. The goal was not to duplicate information that already existed elsewhere, just to link to it.

My product managers were capable, competent and motivated.

Could I get them to summarise their products in this way? Could I hell.

It wasn’t that they didn’t want to, it’s just that they barely had any time to sit down and think in a straight line for long enough to be able to fill it out.

So I interviewed each of them, transcribing their answers as I went. Because I was able to ask them questions about their product, and because they were on top of their products, they could brain-dump easily and fluently.

All I had to do was to write down what they said, and the whole process took no more than 15 minutes for each one. Once the product bibles existed, they were far easier to maintain than to create from scratch.

So even if you write the questions and get someone to ask you them and write down your answers, you may find this unlocks your words rather effectively.

Give a talk #

If you find yourself giving a talk on a particular topic of interest, record it, transcribe it then edit it to be coherent. As a very rough rule of thumb, a twenty-minute talk will easily be over 3,000 words. You can even create a rudimentary lapel microphone using any of those sets of headphones or ear buds designed for taking calls and record the talk on your smartphone.

Yes, you’ll hate the way you sound.*

Yes, you’ll realise that you use a particular filler word or sound so often it annoys you.*

Yes, you’ll be astonished how some bits sounded great in your head, but less so out loud.*

But on the plus side you’ll have some nuggets of gold that can be extracted with some judicious editing.

* Actually, you may not do any of these things. This is just what I do.

Just do it #

In the end, just write. It doesn’t matter if it’s terrible, as the very act of writing will prompt you to write a better piece. Editing is the answer – nothing ever comes out perfectly the first time, or even in the right order – but you’ll be surprised how coming back to what you’ve written later on can help you notice the mistakes, logic failures and non-sequiturs you’d missed first time around.

Writing is like a muscle, the more you exercise it, the stronger your writing becomes.

Exit mobile version