Tag: microsoft

Writer’s block = not having read enough

Loved this post by Tressie McMillan Cottom.

For me, writer’s block is all about perspective. When I cannot write, I take that to mean that I do not yet have anything to, well, say. It is a novel concept, but I do not write until I have a point of view or an argument. If I do not have either of those things, it means that I am not done reading.

Sleep Around Before You Marry An Argument on Essaying

This perspective was quite insightful and immediately made me deeply think about the times where I have had to write a spec for a feature at work — if I could re-frame this into my own process it’d be something like:

Whenever I’m blocked writing a spec, it means that I am not yet clear on:

  • What is the customer problem I’m trying to address, or…
  • If signals (telemetry/research) validate that the customer problem is indeed a problem, or…
  • What is the proposed experience for the feature (visual or interaction design), or…
  • What are the dependencies from other apps, systems, platform, infrastructure, etc, or…
  • If my partners (other PMs in other organizations) are on the same page and aware of dependencies on their products/services/infrastructure, or…
  • If my leadership knows that this directly benefits our customers through the priorities our organization has, or…
  • If my marketing/sales/support teams are aware, and we’ve figured out a plan to not only ship a thing, but have systems in place to properly celebrate and support it.

It can sound like a lot, but as you do this again and again, it starts to feel like when you’re cooking/baking, or prepping to go on an adventure.

One time in Azure, I had to write a spec for a feature that addressed billing for our service. This took me way longer than it should have (I blamed “writer’s block”), but looking back, it was due to my lack of understanding of the feature itself. About a year later on the Windows team, I was helping a close-ish team (who were working on something completely new), and I was tasked to write a spec with three days notice. After spending many hours reading, asking “why” and deeply familiarizing myself to the problem space and approach, I completed the spec and led the review with leads and other stakeholders by the original deadline.

My takeaway: Next time you’re stuck writing a spec, ask yourself if you have a strong opinion on the topic (or the feature) — if you do not, that is a good signal to read more, work with your customers, or partner with your team to get a deeper understanding of the area.