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.

Article by Suzanne Robertson about how to approach writing requirements when you are under constraints that prevent you from completing them.  Good article, very stimulating discussion in the comments.

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

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.

Product roadmaps can be powerful assets to leading a technology business – buy only if they are created and managed in the context of appropriate policies. In fact, the product roadmapping process a company uses can be as important to its business as the roadmap itself. In the Product Strategy Network’s roundtable meetings on product roadmapping, field-tested practices and policies are presented in detail by PSN Members. Here are a few of the highlights:

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