As the title suggests, this post is diving into how you can build better relationships with your stakeholders via intake process. If you’re a large organization you should have a tool that facilitates intake across all teams in a systematic and standardized way. Amazon used an internal ticketing system that allowed team to discover who owned a particular system or experience and then submit a ticket to that team with a severity level. Internal teams had different SLAs depending on the severity of the issue and many provided information about their office hours in case internal teams wanted to connect with them. But what happens when you don’t have a system like this and your partners and stakeholders don’t know where or how to reach you? The first thing that happens without process is escalation: “I want this thing, I don’t know how to get you to prioritize it or listen to me, so I’m going to escalate.” Constant escalation for priority without understanding the process by which things get prioritized is unhealthy (at best). In these situations I would encourage you to setup your own bug intake and feature intake process to provide a set process. This process should facilitate: 1) Ownership, 2) Transparency, and 3) Communication.
Here is an example of a bug intake process I’ve created:
(note: if you are building an intake process for features, this workflow will slightly differ)
This process starts with an offramp to get critical issues to an on-call if necessary, if it’s not necessary it follows a process with a more sustainable SLA. If you don’t have a pre-defined heirarchy of severity levels and expected SLAs, you’ll need to create and socialize that first. The next step is triaging the issues so ownership can be assigned. Single-threaded ownership of a bug is critical at the beginning of the process.
Next the product manager conducts a little discovery on the problem, if the product manager doesn’t fully understand the issue they have the submitter come to a weekly office hours to get their questions answered.
After the bug and the conditions surrounding the bug are known, the product manager either rejects the bug or prioritizes it (and creates a Jira story for tracking). This provides transparency to the submitter on where their issue is at and when it will be looked at.
Finally, once a resolution happens, the submitter is followed up with to close the loop. I can’t emphasize how important this stage is. The resolution should be as automated as possible (with an email triggered when a ticket is closed) to prevent the product manager from having to email every submitter, but if that is not in place, the product manager must follow up to close the loop.
Having a process like this in place helps to build trust with stakeholders (when done correctly), and can help cut down on unnecessary escalations. Whenever possible, provide a detailed reason why a bug cannot be addressed or is not above the line in the next sprint. The ownership, transparency, and communication will help your stakeholders feel heard–even if they don’t fully understand the development process!
