By writing better requirements

Provides comparison and understanding of looking at products in terms of what the products can do, versus what the user can do with the products.

Discussion of agile vs traditional requirements management

If you want to be a bad product manager, create new products based on business desires and existing assets. If you want to be a good product manager, create new products that fill customer needs that are not currently being met.

Presents philosophy that there are four classes of software:

• MeWare:  The developer creates software.  The developer uses it.  Nobody else does.
• ThemWare:  The developer creates software.  Other people use it.  The developer does not.
• UsWare:  The developer creates software.  Other people use it.  The developer uses it too.
• NobodyWare:  The developer creates software.  Nobody uses it.

Includes detailed real-world analysis of City Desk, a software package - applying the ideas 

Very insightful and fun view of how software is made - and how that process has evolved over time.  Great images, great way to explain to "other folks" how software gets created.

Good explanation of how to create a decision tree as a visual artifact when gathering requirements

Article starts with good justification for why requirements should be managed.  Then presents the different types of requirements, and checklists of 'stuff to do' for functional and non-functional requirements.

Overview, explanations, and details from Scott Ambler.  This documentation approach can be used for agile and non-agile processes.  It can also be used for product management / development and for business analysis.

Michael Shrivathsan's article Know Thy Customer.

Details on the following five approaches to understanding your customers better:

1. Listen to customers.
2. Usability tests.
3. Follow-me-home.
4. Walk-a-mile.
5. Customer surveys and focus groups.