Frequently Asked Questions
These common questions and their short answers are taken from Christian Crumlish’s book Product Management for UX People: From Designing to Thriving in a Product World. You can find longer answers to each in your copy of the book, either printed or digital version.
- Can I become a product manager and continue to do a lot of design work every day?
Unlikely. Maybe in a small start-up where they need you to do two jobs at once, but product managers are not designers and the day- to-day work of the two roles differs significantly, as explained in Chapter 2, despite the large overlapping areas of shared concern. - Do UX people make good product managers?
They absolutely can. It’s no guarantee, but the best product managers I’ve worked with had a sophisticated understanding of user experi- ence research, strategy, and design principles, an abiding obsession with the needs of customers and other users, and a deep respect for UX practitioners. Chapter 3 identifies some of the key UX strengths the provide a strong foundation for product success. - If I become a PM, will it mean that I can boss around the engineers (finally)?
Not really, but you cannot succeed as a product manager without learning how to effectively organize and focus the efforts of your colleagues on the engineering team. Chapter 4 explains how you can use your UX “superpowers” to become your developers’ best ally. - Is “growth hacking” the enemy of good user experience?
Kinda. Certainly the cancerous “growth for its own sake” ethos driven by capitalism and its Silicon Valley derivative, venture capitalism, makes short shrift of most UX ideals, but “growth” itself is not a dirty word. Every organism must learn how to grow if it is to thrive. See Chapter 6 for a rundown on how to optimize your product’s growth in a healthy way. - Are product and UX teams always stuck in turf wars?
No, but poorly designed org structures and weakly articulated role responsibilities from leadership are a recipe for conflict, strife, and wasted effort. This is why, whatever side of the table you sit on, you need to negotiate the gray areas and the distinctions between “involved” and “has the final say” for each critical aspect of the work, as discussed in Chapter 9. - How many information architects does a product leadership team need?
At least one, as explained in Chapter 11.
