↓ Skip to main content
  1. Insights/

Keep Those Requirements Checklists in Check

Adhering to Technical Requirements Checklists (TRC*) is often non-negotiable. If a design fails to meet these criteria, it simply cannot be shipped on most consoles, mobile phone stores, and VR stores. However, this necessary consideration often poses a significant hurdle to the prototyping process.

1.1Reviewing the Requirement Docs

(Please mark A, B, or C below)

1.1.1 Required: If you don't already know what to avoid, that is good! Don't even open the requirements docs.
1.1.2 Required: Do your best to unlearn what you have learned. Stay here. Do not open any more.
1.1.3 I'm so sorry.
Suggested: Do your best to unlearn what you have learned. Take every one of those items and stuff it all the way down.

Don’t read the docs. It sounds smart to look for non-starters and the manufacturers provide a convenient list of them. They even generously tell you which are “Required” and which are merely “Suggested”, because if everything is high priority nothing is high priority. One could not be blamed for checking if something you plan for is essentially banned in the place you plan to sell it. It’s also embarrassing to build something that clearly falls short of clear, documented requirements. Nevertheless, have the discipline to just avoid them.

Your more responsible teammates will probably either read them or just have them memorized. They may convince you to read them too, using some solid arguments like the ones above, nipping your promising ideas in the bud. “Why are you doing something that will never ship?”

1.2Dealing with objections. The developer is pressured by the team to stick within the Requirement Docs

(Please mark A or B below)

(Skip to 1.3.)
1.2.1 Required: Hold the line

Push back, gracefully, on these voices. Hopefully you have excellent relationships both vertically and horizontally to accomplish this. The team will usually find a way around these problems later on. You’re unlikely to keep finding yourself in TRC trouble. Therefore, the time wasted putting the brakes on your creativity at such an early stage will not pay off.

Even if you’ve handled the team, you may at some point still hear a nagging inner voice because there is a feature that so clearly violates a top “Requirement” that it will undoubtedly get you bounced.

1.3Dealing with doubt. Some part of the feature the developer is building will clearly fail the checklist.

(Please mark A or B below)

1.3.1 Required: Ship it.
1.3.2 Suggested: Ship it.

At this decisive point, my advice is to simply violate it. You don’t know enough this early in the game development cycle. What if the final draft is the winner and you never even got to write the first draft out of fear of failure and embarrassment? Allow yourself to evaluate how well your idea plays as separately as possible from how difficult it is to ship.

What you play may easily lead you in unexpected and promising directions.

*AKA TCRs, Lotcheck, Requirement Guidelines, VRCs