In product orgs, the word “autonomy” tends to get attached to seniority and titles. Sara Paul, writing for Nielsen Norman Group, puts the bar somewhere else:

Our research shows that autonomy is about becoming sufficiently informed to credibly shape shared product decisions.

You’ve earned design autonomy when you’ve collected enough context to make a recommendation that holds up under scrutiny. Until then, you haven’t. Low-autonomy designers, in Paul’s terms, “execute predefined solutions.” High-autonomy designers shape what gets prioritized, because they know things their stakeholders don’t.

The four-part pipeline is the practitioner half:

The designers who achieved high autonomy kept information flowing to them from all sources within their organization. Their pipelines consisted of four parts: (1) Gathering information from across teams and channels, (2) Building relationships with people who provide information, (3) Creating crossfunctional spaces for information to be shared, (4) Synthesizing information to form a “big picture” of context that empowered credible recommendations.

Paul’s examples are specific enough to put to use. The opening one is a lead designer at an online review platform whose ad-setup experience lived across mobile, desktop, and web. Three teams owned different parts of the experience and the whole was nobody’s job. Here’s how the story ends:

She saw the problem, took the initiative to gather the information she needed, and synthesized it into a recommendation that boosted her influence over what got built. This is design autonomy.

None of this required a new title. It required a tracker, a few standing meetings, and the willingness to do the synthesis work nobody assigned.

The designers I want—and have—on my team are the ones who can fill in for a PM when they’re on vacation. Paul’s article is the mechanism for getting there. The PM-shaped skill is holding the information context that lets you make a defensible call.