Most career paths are tables nobody opens until review season.
They list skills, attach them to levels, and quietly become a scorecard. The designer tries to collect enough ticks for the next title. The manager tries to make the ticks feel objective. Neither person leaves the conversation with a better idea of how to become more useful to the product.
I wanted something different.
A career framework should not tell designers where they rank. It should help them see where they can create more impact next.
First: what is a Product Designer actually there to do?
A Product Designer is there to create value by turning the needs of the business, the product and the user into an experience people can understand and use.
That means our job is bigger than producing screens. We discover problems. We define which problems are worth solving. We design solutions. And we stay close enough to the outcome to learn whether those solutions worked.
The more senior the designer, the wider that responsibility becomes. Craft still matters—deeply—but progression is not a sequence from “small screens” to “big screens.” It is a shift from receiving a problem to shaping the conditions in which the right problems get solved.
My main goal as a Design Lead
My job is not to be the person with the best answer in every critique. If every important decision needs me in the room, I have created a bottleneck—not a team.
My main goal is to help designers progress until they can take on the objectives the company needs them to take on: with stronger judgment, greater autonomy and a clearer understanding of the impact their work should create.
That is not separate from business performance. It is one of its foundations.
When designers grow, teams frame better opportunities, research the right questions, make decisions with more confidence, collaborate with engineering earlier and ship work that is easier to evolve. Individual development becomes product capability.
The framework: four pillars, six levels, one direction
I created a career path around four dimensions of the role. It runs from Junior to Head of Product Design, but it is not meant to be climbed like a game. Its purpose is to make expectations visible and turn a vague conversation about “seniority” into specific evidence, choices and opportunities.
The framework has since travelled beyond the team it was created for. Other companies have asked to use it as a reference when shaping their own design career paths. That matters to me because the useful part is not the labels—it is the shared language underneath them.
Progress is an increase in scope—not just polish
Titles are contextual. The useful question is: what kind of ambiguity can this designer turn into progress, and for whom?
- Junior designers build solid foundations, learn the product and users, ask good questions and execute with guidance.
- Mid-level designers own defined problems with growing autonomy, involve the right people and connect decisions to product metrics.
- Senior designers challenge problem definitions, lead research and influence the direction of their squad—not only its interface.
- Leads coordinate design across complex initiatives, unblock others and raise the quality of decisions around them.
- Principals create leverage across the organization through systems, standards, strategic judgment and mentorship.
- Heads of Design build the environment in which multiple teams and leaders can do their best work.
This is not a demand that every designer becomes a manager. Leadership and craft can grow in different directions. A great Principal and a great Head may have very different days, but both increase the organization’s ability to make better products.
1. Product Vision: move from requests to direction
The first pillar is the ability to see the product as a system of users, business goals, constraints and opportunities.
At an early stage, that means learning the product, its customers and its competitors. With experience, it means contributing to strategy, questioning the framing of a problem, finding opportunities proactively and helping the team focus on outcomes instead of output.
I support this growth by bringing designers closer to product strategy: involving them in roadmaps, exposing the commercial context behind a request, reviewing evidence together and asking them to articulate the outcome before opening Figma.
The shift I am looking for is simple: from “What should I design?” to “What should change, for whom, and why does it matter now?”
2. Design Expertise: turn craft into a reliable foundation
Craft is not decoration. It is how a product makes its logic visible.
Designers need strong fundamentals, fluency with systems, the ability to map journeys and prototype ideas, and the judgment to balance complexity with simplicity. As they progress, their work should need less supervision, solve harder structural problems and eventually become a reference that raises the standard for others.
I use critiques, pairing and real product constraints to develop that judgment. I do not want a designer to copy my solution. I want them to explain why one option is clearer, what trade-off it makes and which principle can be reused the next time the interface looks completely different.
3. Product Cycle: own the result, not the file
A Product Designer should understand the full loop: research, framing, hypotheses, metrics, exploration, delivery and learning after launch.
Progress means taking ownership of a larger part of that loop. It means knowing when more research is needed, helping define the measures of success, planning work around outcomes, involving engineering before decisions harden and balancing quality, speed and risk without losing the problem.
This is where growth becomes visible to the company. The designer stops waiting for perfectly shaped tasks and starts helping the team create momentum through ambiguity.
4. Communication: make good thinking travel
A strong decision that only exists in a designer’s head cannot influence a product.
Product Designers need to collaborate across disciplines, document clearly, present a convincing narrative and exchange feedback without turning it into a defence of personal taste. At higher levels, communication becomes leverage: it aligns teams, gives context to decisions, makes progress visible and helps other people improve their own thinking.
I work on this through written decision records, critiques, stakeholder reviews, async updates and opportunities to present. The goal is not to make every designer sound the same. It is to help each of them make complexity understandable to the people who need to act on it.
AI is not a new box in the framework
AI changes the role too broadly to sit in a single row called “AI skills.” It belongs across the whole career path.
A Product Designer today should learn where AI can expand their judgment and speed—and where it can create false confidence. I encourage designers to use it throughout the product cycle:
But AI does not replace contact with users, accountability for metrics or the ability to make a trade-off. A plausible synthesis is not evidence. A fast prototype is not a validated solution. The designer still owns the judgment.
The new Product Designer is not valuable because they can generate more. They are valuable because they can understand more, connect it faster and decide better.
How I turn the framework into real growth
A career path only works when it changes what happens between review cycles. I use it as a coaching tool, not a verdict.
- Start with evidence. We look at recent work, decisions, collaboration and outcomes—not personality or vague impressions.
- Choose the highest-leverage gap. Nobody develops fifteen skills at once. We pick one or two areas that would unlock more autonomy or impact.
- Connect growth to real company work. Development needs an actual product opportunity: lead the research, define the metric, run the critique, shape the roadmap or own delivery with engineering.
- Create a tight feedback loop. Regular 1:1s, pairing, critiques and written reflection turn the project into deliberate practice.
- Measure the change in capability. The question is not whether the activity happened. It is whether the designer can now handle a problem, decision or scope they could not handle before.
This gives development and business the same direction. Designers do not practise on imaginary exercises while the company waits for outcomes. They grow by tackling the work the product genuinely needs—with support calibrated to help them succeed.
What success looks like to me
I know the system is working when designers bring opportunities before they are handed requirements. When they can explain the metric behind a decision. When engineers are involved early. When critiques become sharper without becoming less generous. When a person who once needed answers starts creating clarity for others.
And eventually, when the team can make an important decision without me.
That is not a loss of influence. It is the result I am aiming for.
Final thought
The best career paths are not ladders out of the work. They are maps towards greater responsibility for the work’s impact.
My role as a lead is to make that map visible, create the opportunities to move through it and give designers the context, challenge, feedback and trust they need along the way.
Grow the designer. Raise the product. Make the company more capable than it was before.
V.