When Frustrated, Write Requirements - follow up story

Productive ways to handle known issues in your product

What happened when I followed the advice in a recent Product Management IRL article? These insights are for premium subscribers to Product Management IRL. Let’s see how the recommendations help in real life.

This week’s backstory is about turning frustrations into requirements:

What Prompted this Article?

When I wrote this article, I was leading a newly formed product team. I was unclear about some of the roles in the service delivery team since I hadn’t worked with them before. Many meetings were turning into fault-finding meetings. I was getting escalation emails and meeting invites about poor customer communication and missed deadlines.

Each issue raised needed investigation to figure out who should handle the escalations. Surely, not every issue needs to be escalated to the product manager!

At first, this seemed like normal product manager issues. When stakeholders started raising issues, I had to do something different.

I took a timeout and turned the escalated issues into requirements. I wrote the recent issues into a document and grouped them into themes. I took a couple of days to edit the document - it was 2 pages. I sent the document to the customer success managers to check if anything was missing.

The response to the document was fairly subdued - 2 people said thank you and a key person agreed with the issues. Next, I put the issues into Jira for regular backlog management.

It was such a relief to put the issues into writing! I wanted to spread my good feelings by writing this article.

What Happened After this Article?

Throwing complex requirements into Jira for significant customer issues IS NOT what a product manager should do. Why did I say to do this?