Readers who have potential features they would like to see in OpenOffice and Office (or other ODF and OOXML applications) should over the next month (i.e. early 2Q 2009) submit requests to the ODF TC comment list (there is a template) or to the Ecma TC 45 (OOXML) or through your local national body to ISO SC34 WG4 or WG5. In fact, often the best way will be to make contact directly with an amenable committee member or the committee chair, and ask them about the procedure.
Of course, there is no guarantee that a requested feature will make it into the standard, or make it in your preferred form, and you should expect up to three years lag time before you see the feature in products, depending on the standards cycle that the individual product cycles. And vendors may decide not to implement optional features, of course.
But all that aside, if we don't speak up about your requirements, they probably won't be met. Mind reading is not the optimal mechanism for standards development!
In particular, this may apply to you if you have put in a request for an enhancement (or perhaps bug fix) to a product, such as OpenOffice. If the enhancement (or bug fix) relates to what ODF specifies, it cannot really be fixed in the product: the product will attempt to follow the standard.
But we cannot expect the product maintainers to route our RFEs and bug-fix requests to the standards committee: they are not a telegraph service.
Of course, the bottom line about a feature is that it needs to reflect some broad or significant requirement, not a niche one or pet idea. You may have ideas for a version of ODF that is more suitable for cats, but it may not be very compelling for the appropriate committees. On the other hand, a requirement by the defense sector or privacy advocates would be much more compelling.
And running proof-of-concept code helps. Burdening developers with extra features is always an issue, so the less work for developers (i.e. the more work that we do) the better.