Audits With a Side of Spam

To counter-balance my first blog post on the sexy subject of vibe-coding, I wanted to write about audits today. Wait, wait, wait, before I lose you, audits are not as bad as they are portrayed. In my last 18 months at work, I have had the pleasure of supporting four different audits; two internal and two external. I started as a total novice, and I now consider myself to be proficient. I only realized this when I was helping a peer with their first audit deck and I got to whip out the audit framework I have been developing over the last 18 months. I present to you: SPAM.

S is for storytelling. Whoever is auditing you is less familiar with your work than you are. You must present a clear and coherent story when presenting them with information. When walking them through an example, make sure everything is one consistent storyline. As they orient themselves to your world, any inconsistencies will jump out to them and create new questions (and potentially new audit requests). Storytelling both helps them understand the intricacies of your product better and keeps them focused on the details you are trying to illuminate.

P is for polished. This may seem obvious but it especially needs to be reiterated for internal audits. Although these are technically your colleagues, they should not be treated as such. All materials that are handed off or presented to audit teams should be reviewed with a fine-toothed comb. Acronyms should be spelled out the first time they appear, the slides should be visually appealing and legible, and consistent language should be used throughout.

A is for accurate. All information should be double and triple checked. I made the mistake in my first audit of pulling information from stale documentation and when asked to do a live demo, the system was not working as I had described. While crisis was averted in this example, it is best to avoid this by making sure all of your audit materials are up to date. If you do catch a mistake in information that has been handed out, call it out as soon as possible and share the accurate information. Since audit requests often involve follow up walkthroughs or questions, any mistakes can compound.

M is for minimal. My fiancé’s work was being audited last year and he mentioned his strategy was to throw as much paperwork at the auditors as possible. I sounded the alarms. Auditors are usually extremely thorough and do not phone it in. If you throw material at them, they will digest it and come back hungry with more questions. While working on audit responses, I start by grounding myself in the original request, usually review it while working on it, and come back after I am done to ensure my response is the minimum information required to answer the question.

Codifying SPAM for a teammate helped me realize how much audit work has shaped me as a Product Manager. Honing my communication skills (both verbal and written), learning even more about my products, and collaborating with teammates on urgent audit decks have all been valuable exercises for me.

Coincidentally, two of the audits I supported were for roles I had just stepped into. I had to answer to auditors for a product that I was just learning about and it ended up being one of the best on-ramps I could have asked for. I had to dive in and create documentation, flow charts, and get to know the engineering team I would be working with. Being thrown head-first into an audit, where I was expected to be expert, created a forcing function for me to get up to speed faster than I would have otherwise. After the audit, I ended up having incredibly thorough documentation that I could reuse in other scenarios. Lastly, audits can be amazing confidence-building experiences. Creating polished documentation, answering rigorous questions, and presenting on my product in deep detail leaves me feeling the expert I claim to be.