If you are reasonably sure that the menu can be accessed from a given point (and graphics placed alongside it, especially if they are actually in memory, is a good point) then forcing a value like that is a good thing to look at. When you do not know and debug menus start being accessed from options menus, sound tests, "press start" screens, in the actual game and whatever else is when you get to break out the big toys, doubly so if you suspect the method of getting to the debug menu was removed from the final build somehow. How it might get removed varies, though typically NES era stuff will have it left in and the access methods removed, later stuff might actually be recompiled without it (more modern consoles often have nice memory laden debug/development versions) and all you will find is some strings and graphics from it.
Anyway if it is a combo or options select combo that does the deed it will have to be noted in memory somehow as you are entering it. As title screens, options menus and more are not noted for their massively changing memory, and don't have the most functionality beyond "if button pressed then jump to whatever next menu is behind the one that was selected" you can usually spot when things get modded. If you are just using cheats then a combination of savestates and observation may get you what you want, if you are actually playing with a proper debugger then following the code, and then maybe jumping to a disassembly will tell you exactly what it wants and then jump.
Others elect to do things like force an actual jump (not just the value it uses to figure out a jump) to places in the debug part of the code. You can do this in various ways but usually if you see the debug text in memory then you can find a function that references part of that and work backwards from there.