
A full roadmap is not a strategy
Around this time of year, I find myself thinking less about what my design team should deliver next year and more about what the organisation needs us to help achieve.
Annual planning has a familiar rhythm. Business leaders begin discussing growth targets, budgets, operational efficiency, and market opportunities. Product teams start shaping their roadmaps. Engineering begins assessing capacity and technical dependencies. Design leaders are expected to translate those ambitions into a plan.
It is tempting to start listing everything the team could accomplish. The customer journeys we want to improve. The research we have been meaning to conduct. The design system that needs investment. The additional designers we would like to hire. I have been in those conversations, and I understand the instinct. When you are responsible for a design team, you see opportunities everywhere. You also see the gaps that prevent your designers from doing their best work.
But I have learned that a full roadmap does not necessarily mean you have a strategy. You can have an impressive list of initiatives, ambitious objectives, and a well-organised presentation without answering the most important question: what will become meaningfully better for customers and the business because of the decisions we make today?
That is the question I believe directors of product design should bring into annual planning. Our responsibility is not simply to secure work for our teams. It is to help the organisation understand where design can create value, what investments are required, and what commitments need to be made across leadership to deliver meaningful results.
Start with the business, but understand why customers should care

One of the first things I look for when planning the year ahead is the connection between the company’s ambitions and the problems customers are experiencing. A business might want to increase acquisition, improve retention, expand into another market, or reduce operational costs. These are legitimate objectives. They give teams direction and help leadership allocate investment.
But customers do not wake up thinking about our revenue targets or growth strategy. They want to understand a product, complete a task, solve a problem, or accomplish something important to them. Our role is to connect those two perspectives.
Imagine a company identifies customer onboarding as a major growth opportunity. Leadership wants more people to complete registration and begin using the product. The obvious design response might be to redesign onboarding. But before assigning designers or committing to delivery dates, I would want to understand why customers are leaving.
Perhaps they do not understand the information being requested. Maybe identity verification creates unnecessary friction. Perhaps the product does not communicate its value clearly enough. Or customers may begin onboarding on one channel and struggle to continue on another. Each possibility creates a different design problem and potentially requires a different organisational response.
This is where I expect design leaders to contribute to product strategy rather than simply respond to it. The business objective might be growth. The customer outcome might be greater clarity, confidence, and fewer barriers to getting started. The design strategy needs to explain how improving the latter can contribute to the former. That connection should be clear enough for a product designer, engineering director, product manager, or executive to understand without needing a separate interpretation.
Understand the problem before committing the organisation to a solution

Once the business direction is clear, I want to understand what is preventing progress today. This is where annual planning can become uncomfortable. Sometimes the evidence is incomplete. Sometimes we have plenty of analytics but little understanding of customer behaviour. Other times, research tells us what is wrong, but nobody has established ownership for fixing it.
I would rather make those gaps visible during planning than discover them halfway through the year. For our onboarding example, I would start with the existing experience. What percentage of customers complete onboarding? Where do they abandon the process? What errors occur? How often do they contact support? What do we know about the reasons behind those behaviours?
Quantitative evidence helps us understand the scale of a problem. Qualitative research helps explain what customers experience and why. Neither should operate in isolation. But understanding the customer problem is only half the work.
As a director, I also need to understand the organisation responsible for solving it. Does the onboarding experience span multiple products or channels? Are different teams responsible for identity verification, customer communications, and account creation? Are their priorities aligned? Do they have access to the same customer evidence?
A fragmented customer experience can be the result of fragmented organisational ownership. If three teams are independently improving different parts of the same journey, each might achieve its local objectives while the overall customer experience remains difficult. That is why I believe design strategy and organisational design need to be considered together. You cannot always improve a connected customer experience through disconnected ownership.
Decide what deserves attention, and what does not
One of the more difficult responsibilities of design leadership is accepting that the team cannot pursue every worthwhile opportunity. This becomes especially difficult when you have talented designers who want to contribute, stakeholders who need support, and a growing list of product initiatives. It is easy to confuse demand for design with the value design is creating. A team can be fully occupied and still be working on the wrong priorities.
During annual planning, I want to identify the few areas where customer needs, business objectives, and organisational capability intersect. That means making decisions about where designers should focus, how responsibilities should be organised, and which initiatives should wait.
For example, rather than assigning designers exclusively to individual screens or features, I prefer to explore ownership around meaningful customer problems. A designer responsible for customer onboarding can develop a deeper understanding of the entire experience, including its performance, dependencies, and recurring issues. That does not mean every organisation should abandon platform-based teams. Some platforms require specialised knowledge, particularly in complex enterprise environments.
The important consideration is how we establish accountability for the customer outcome while coordinating the platforms and teams needed to deliver it. I also want designers to understand why their work matters beyond their immediate backlog. When someone understands the customer problem, the business objective, and the measures of success, they can make better decisions without waiting for constant direction. That is a stronger form of ownership than assigning someone a collection of deliverables.
And it requires us, as leaders, to be equally clear about what we are not prioritising. Every commitment consumes capacity. If leadership adds another initiative, something else may need to change. A credible strategy makes those trade-offs visible rather than quietly transferring the pressure to the team.
A design strategy becomes credible when business ambition, customer value, and organisational capacity are connected through clear commitments.
Build the team around the strategy, not the other way around

Once I understand where the organisation needs design to contribute, I look at whether the team is equipped to deliver. This is an important distinction. Having enough designers to distribute work is not the same as having the right capabilities to achieve the desired outcomes.
Perhaps the team needs stronger research expertise. Maybe the design system has become a dependency across several product teams. Perhaps complex workflows require more experienced interaction design or service design capability. There may also be gaps in content design, accessibility, analytics, or engineering support. I do not want hiring and tooling requests to become an independent wish list. Every investment should connect to a problem the organisation has agreed is worth solving.
For example, if several product teams are struggling with inconsistent patterns, duplicated components, and repeated implementation decisions, the answer might not be to assign more interface design work to existing designers. The organisation may need dedicated design system ownership and engineering capacity. That investment could improve the ability of multiple teams to deliver consistent experiences, rather than benefiting a single product initiative.
The same thinking applies to coaching and career development. When I work with designers on their goals, I want them to understand how their development connects to the organisation’s direction. If a designer wants to grow in strategic thinking, I might give them responsibility for defining a customer problem, interpreting evidence, or leading a cross-functional decision.
If another designer wants to develop systems thinking, I might involve them in shared patterns, governance, or work spanning multiple products. The objective is to develop people while increasing the organisation’s ability to solve important problems. This is also where AI deserves consideration. AI is changing how designers research, explore, prototype, document, and build. But I would not make AI adoption an annual objective simply because the technology is available.
I would ask what capability we are trying to develop. Can AI help designers evaluate more alternatives? Can it reduce repetitive production work? Can it support more realistic prototypes? Can it help teams understand complex information faster? Those opportunities need clear standards for evidence, privacy, accessibility, human oversight, and design quality. Without shared foundations, giving teams more powerful tools can increase output while making consistency and accountability harder to maintain.
As design leaders, our responsibility is to develop the operating model alongside the technology.
Give designers ownership of outcomes, not just deliverables
One thing I want to avoid during annual planning is creating objectives that designers cannot meaningfully influence or evaluate. An objective such as completing a redesign by the second quarter may help with delivery planning, but it tells us little about the value created. I would rather connect the work to a measurable customer or business outcome.
Returning to our onboarding example, we might establish a baseline completion rate and identify an improvement target based on research, technical feasibility, and available capacity. But I would not stop at completion. We might also examine error rates, customer comprehension, support contacts, or accessibility barriers. Improving one metric should not come at the expense of customer trust or another part of the experience.
These measures help the team understand the consequences of its decisions. They also give designers a stronger role in product conversations. Instead of reporting that five screens have been redesigned, a designer can explain what problem was investigated, what changed, what evidence informed the recommendation, and what the team is learning from the result. That is a different level of accountability.
I also believe we need to be careful about claiming ownership of business outcomes that depend on several disciplines. Design contributes to conversion, retention, adoption, and operational efficiency. But those results also depend on product decisions, engineering quality, marketing, pricing, customer support, and external conditions. Our role is to establish credible measures, work with partners to evaluate results, and be transparent about what the evidence supports.
At the director level, I want that discipline to become part of how the department operates. Designers should understand the outcomes connected to their work. Product and analytics partners should support measurement. Leadership should review what the organisation is learning and adjust priorities when necessary. Measurement should help us make better decisions throughout the year, not simply prepare a favourable report at the end of it.
Turn the strategy into a leadership commitment

This is where I believe annual design planning becomes most important. Once the priorities, evidence, team capabilities, and expected outcomes are clear, the conversation needs to move beyond the design department. It becomes a discussion about what the business is prepared to support.
I have learned that asking leadership for additional resources is more productive when the request is connected to a business decision. Saying that the team is overloaded may be accurate, but it does not provide enough context for an executive to decide what should change. I would rather explain the opportunity, the constraints, and the available options.
For example, we might be able to improve one part of onboarding with our existing team. A broader improvement across channels might require additional research, dedicated engineering support, or changes to team ownership. Those are different commitments with different costs, risks, and potential outcomes. My responsibility is to make those differences clear.
I want leadership to understand what we can reasonably accomplish with current capacity, what additional investment could make possible, and what we would need to defer. I also want agreement on the dependencies outside design. If the strategy depends on engineering capacity, analytics instrumentation, customer research access, or decisions from another department, those conditions need explicit ownership.
A design director cannot commit the organisation to an outcome that depends on resources and decisions the department does not control. That is why I believe executive alignment should happen throughout planning, not only during the final presentation. Discuss the constraints with engineering. Validate the business assumptions with product. Understand the financial implications. Identify where ownership needs to change. By the time the strategy reaches the leadership table, the conversation should focus on the decisions required to move forward.
The objective is not to persuade executives to approve a larger design roadmap. It is to help them make an informed investment decision.
Plan for a year that will change
There is another reality of annual planning that deserves more attention. The plan will change. Customer behaviour will evolve. Business priorities will shift. Technical constraints will surface. New opportunities will appear. AI capabilities will continue developing. A strategy that cannot respond to new information becomes a liability.
That is why I prefer to establish a clear annual direction while reviewing priorities and evidence throughout the year. Quarterly planning should create opportunities to reassess assumptions, not simply divide an annual roadmap into smaller delivery commitments. If the evidence shows that an initiative is not producing the expected result, we should be willing to change direction. If an investment in a shared platform capability is helping several teams move faster, we should understand why and consider where to extend it. If a customer problem turns out to be different from what we initially believed, the team should have permission to respond to what it has learned.
This is also where organisational maturity becomes visible. A strong design organisation does not need every decision to return to the director. Teams understand their objectives, the standards they are accountable for, and when to bring decisions forward. Leadership provides direction, removes constraints, and maintains alignment across the organisation. That creates space for designers to grow while keeping the department connected to business priorities.
The commitment is bigger than the roadmap
When I think about planning the year ahead, I keep returning to one idea.
The value of a design strategy is not measured by how many initiatives appear on the roadmap. It is measured by the quality of the decisions it helps the organisation make and the outcomes those decisions produce. A strong plan explains where the business needs to go, why customers would benefit, what the organisation must change, and how we will know if the investment was worthwhile. It also creates accountability on both sides.
Design leaders commit to developing their teams, making evidence-informed decisions, maintaining product quality, and demonstrating contribution.
Business leaders commit to the priorities, resources, partnerships, and decision-making conditions required for that work to succeed.
Neither commitment works particularly well without the other. As directors of product design, we should be helping organisations move beyond asking what design can deliver. We should be asking what design can help the business achieve, what customers should experience differently, and what needs to change across the organisation to make those outcomes possible. That is the conversation I want annual planning to create.
If you are preparing your design organisation for the year ahead, I would be interested in hearing how you connect design priorities to business commitments. You can connect with me on LinkedIn, or book a conversation through my ADPList mentorship profile to exchange perspectives on design leadership, team development, and strategy.






























