Thread by @PavelASamsonov

Job title meanings are tricky because every role has 2 buckets:
-Activities the org expects (provides inputs & demands outputs)
-Activities the org tolerates (acquiring inputs & applying outputs costs political capital)

2 titles may do same activities, but in different buckets.

This is the problem at the root of explaining what a Product (or whatever) Designer actually does.

Many orgs expect a designer to accept ideas and produce pictures. We know the strategic user-facing work is necessary, but it goes against this grain of expectations.

And because it's unexpected (the designer has no official mandate), they spend a lot of time on:

-trying to get input data (being in the right meetings, meeting real users)

-convincing others to accept their strategic outputs (beyond mocks attached to Jira tickets)

These orgs usually have someone that (they think) is doing this stuff - Sales talk to customers, PMs do strategy and politics.

No one will notice if a designer doesn't do the "unexpected" work because no one recognizes that work as necessary for the expected output (pictures).

When designers say that a product designer does X, what they mean is that X is integral to the product design process. It does not - unfortunately - mean that every product designer is empowered or even allowed to do X, but only that they must advocate for X in the practice.

This is - fortunately - not the case for all such roles. But it's an important distinction because the design process does not change; regardless of how your org assigns activities to buckets, they are all still necessary to do good work.

The only strategy I can recommend is: make the "unexpected" work visible, and make it make sense. As your colleagues get used to seeing it, you'll get closer to that point of true influence: when someone says "ask $designer, we can't make this decision without them in the room!"