Member-only story
PMs are not the boss of me
Finding problem-alignment as a designer
It’s a tale as old as time. PM (Product Manager) writes a ticket. The ticket goes something like this:
The assumption being that a designer will “do X.”
If you’re getting tickets like this (or worse, tickets with mockups or sketches) — you’re PM is jumping past the problem-alignment stage. This means that you’re not getting a chance to provide input at an extremely vital stage.
Sometimes a ticket will read:
Again, the designer is given the task of “doing Y.”
Make it stop
If this is NOT the culture at your organization, and problem-alignment is respected — you can stop reading.
If you have gotten tickets like this — I have some tips.
And worst of all, if design is treated like a service for product and engineering to utilize, bookmark this article.
What is problem-alignment
Problem-alignment is simply the task of making sure that everyone who is working on a project agrees on the definition of the problem.
For example, let’s say a PM writes you the following ticket:
Within this ticket is an implied problem. The problem, as defined by the PM, is that the “Buy Now” button is too small. But do you, as the product designer, agree with that? Do other sources of data point to the same problem?
For instance, do buttons of the same size work consistently throughout the app? Does user research point to a different problem? Perhaps the problem is that the button is consistently below the fold, and would benefit from being sticky. Or the button is using a secondary style…
