Product Management vs. Engineering

Posted by Marty Cagan on October 31, 2007

Tags: , ,

If a great product is the result of combining a real customer need with a solution that’s just now possible, then it’s easy to see why the relationship between the product manager and the engineering team is so critical.

Read the full post

Personas for Product Management

Posted by Marty Cagan on October 22, 2007

Tags: , ,

Product management is all about choices. Making decisions about what opportunities are worth chasing, which problems are worth solving, what features will provide the most value, what the best time-to-market trade-offs are, and which customers are most important. While you’ll never make all the right choices, you have to make most of them right for your product to succeed.

Read the full post

Product Management vs. Project Management

Posted by Marty Cagan on October 9, 2007

Tags: , ,

Earlier I’ve written about how important it is to clearly distinguish the roles of product management and product marketing (see Product Management vs. Product Marketing). But many companies suffer from a related problem, which is when the roles of product management and project management are combined.

Read the full post

Prototype Testing

Posted by Marty Cagan on October 1, 2007

Tags: , , ,

Readers of these articles know that I view the high-fidelity prototype as the primary means of describing the product to be built. I have written elsewhere why a prototype is significantly more useful to the product team than the typical paper-based specification. However, that's really the secondary benefit. The primary reasons to create a high-fidelity prototype are to help you gain a much deeper understanding of your product, and ulimately so that you can actually test your ideas with real users before you have your engineering teams take months to go build something that you have no real evidence will serve its purpose.

Read the full post

Prototype Testing

Posted by Marty Cagan on October 1, 2007

Tags: , ,

Readers of these articles know that I view the high-fidelity prototype as the primary means of describing the product to be built. I have written elsewhere why a prototype is significantly more useful to the product team than the typical paper-based specification. However, that's really the secondary benefit. The primary reasons to create a high-fidelity prototype are to help you gain a much deeper understanding of your product, and ultimately so that you can actually test your ideas with real users before you have your engineering teams take months to go build something that you have no real evidence will serve its purpose.

Read the full post