Capturing the shadow specs
Listen, including additional commentary (12 min):
Takeaway
Write a list of easily forgotten specs that can come back to haunt you during a launch, like accessibility, privacy, and browser support.
Why?
Plan for the true amount of work that needs to happen. You’ll figure it out one way or another.
Avoid unexpected crunch right before or after a release. Everyone hates this.
Gain peace of mind so you don’t have to rely on your memory. Learn from the past.
How?
Learn from rocky launches. Think back to past launches that didn’t go well. What do you wish you knew beforehand? What was missed? If you don’t have professional experience yet, consider apps you use and what you wish their teams had considered when creating the product.
Write and maintain your list. This should evolve over time and serve as a reference when you start something new.
Advocate for resources. There’s a high chance you’re on a team that isn’t used to prioritizing some of these things, like accessibility, and you need to convince someone that it actually needs to be done. Calmly offer logical reasons why they’re important, along with suggesting compromises (like phased approaches) for incremental progress.
Bonus: A sample checklist
Feel free to use this to spark your own ideas:
Accessibility - Reference accessibility standards like WCAG’s A, AA, and AAA standards for clearly defined and industry standard checklists. Some products and clients may be legally obligated to pass a certain level, like AA.
Privacy - Would the new feature potentially introduce privacy concerns? Are you exposing user’s data with AI in a way that might cause concern or legal issues?
Security - Similarly, could it introduce vulnerabilities that need to be anticipated?
Permissions - If your product has user permissions built in, it’s important for the team to know where the new feature fits in.
Integration - How does this fit in with existing features or 3rd party tools?
Browsers - What browsers and devices should this be supported on? Will any features have reduced scope in non-supported browsers or on mobile?
Analytics - Make sure you’ll be capturing meaningful metrics to monitor goals and success immediately upon launch.
Tech debt - Your team may need to address tech debt that blocks progress.
Automated testing - Developers often incorporate automated code testing.
Internal testing - Don’t forget Quality assurance (QA) testing, including of many things on this list like accessibility.
User testing - It’s also important to get user’s feedback through user acceptance testing (UAT), which likely will also involve training them on the new elements.
Marketing - Share the information and help create content that marketing or other business areas needs to effectively communicate this to current and potential customer. Users need to know what it is, decide to use it, and find it useful in order for the feature to succeed.
Case study - Capture the before state, progress, and outcomes, if this will be useful for a case study later on. Don’t wait until after launch when you can’t find details as well!
P.S. See Definition of Done
This is closely related to the Agile principle of “Definition of Done” (DoD). Here, I focus on a broader list including launch prep and business items, while the Definition of Done is traditionally more user story focused.
The core idea is the same. Something you build isn’t successful until a user actually uses it and it helps them. There’s a lot more that goes into that than just an idea and code.
