As I've developed several products for Zope, I've had to figure out a number of things that were worth remembering, and are potentially worth sharing. Here's hoping this helps you in your product development:

• Using a docstring on a public method exposes that method to being called directly by a client. Suppose product Spam has a method Eggs. If Eggs has a docstring, it can be called from the URL Spam/Eggs. If you want that behavior, that's how you enable it� if you only want methods called from Zope's DTML Methods, don't use docstrings.
• By default, objects that use the Persistent library to maintain persistance don�t save changes made to dictionaries and some other complex objects. You must explicitly save information stored in a dict to maintain persistance outside the current session. The command to do this is:

  self._p_changed = 1

• The full range of OO techniques is available to you. You can subclass in code, use mixin classes, import code, and store instances of other classes. This is where Python really shows its strength, so don't be shy.
• DTML commands invoked by HTMLFile() appear to have greater access than can be had from DTML Methods or DTML Documents. DTML Methods can only call top-level properties and methods. HTMLFile can call methods and properties of embedded/nested objects. There may be other differences, but that's what I've observed.
• Put an empty file called "refresh.txt" in your product folder. Having one tells Zope that you want to be able to refresh the object without restarting the whole server. It's an invaluable technique during the development / testing phase.
• (Opinion) The more you use interfaces defined in your object code, the more easily portable and securable your product becomes. Using DTML files (not DTML Document objects or DTML Method objects) seems more dummy-proof, but is perhaps less easily customized.