Whoever leads an innovation project has two roads for building its vision: defining it alone and then communicating it, or constructing it collaboratively with the working group. Both work. One of the two, in most cases, works better — but the interesting part is what must happen before, in both cases. And that's where the mistake I see most often hides.
Imposed vision or shared vision?
The imposed vision — decided by the leader and communicated to the team — has its legitimate use cases. It works when time is short and an immediate direction is needed; when the team hasn't yet developed a collaborative culture, and an overly participatory process would only generate confusion; and above all when the group is hostile to the project or there's fierce competition over ownership — in those contexts, a co-creation exercise would amplify tensions rather than resolve them, and a clear, non-negotiable top-down approach serves better. The risk, though, is well known: the vision gets perceived as a directive, the team accepts it without feeling it as its own, and engagement stays lukewarm.
The shared vision, built together with the team and possibly with stakeholders, generates a sense of belonging, a more solid alignment and — the decisive factor — a group that will defend it when resistance arrives. In government, collaborative involvement in strategic decisions is an exception more than the norm, and the first reaction is often scepticism; but it passes quickly, giving way to a stronger endorsement: people who helped build the vision will be far more inclined to actively support it. If you want the project to have more strength, more support and less hostility, involving the team is the most effective choice.
The top-down phase that comes before the workshop
Here, though, a misunderstanding needs clearing up: building a shared vision never means giving up leadership. The most common mistake is thinking the vision can emerge spontaneously "from below", with no initial orientation. Sharing completes the guidance; it never replaces it. A shared vision is neither the outcome of a vote nor a compromise: it's an idea that is born from someone and grows thanks to many.
Every serious process begins with a phase of clarification from above, in which whoever leads — manager, innovation lead, executive — defines the strategic objectives, the perimeter and the overall meaning of the journey. This phase is directive by function, and never by authority: the objectives represent the limits within which the group will move. If the team started negotiating them, the discussion would shift from the why to the whether, generating uncertainty and slowing everything down. First you trace the route; only then does it make sense to decide together how to travel it.
What the right objectives look like
To be useful, objectives must be concrete and verifiable. The classic criterion, still valid, is the S.M.A.R.T. acronym: Specific, with no ambiguity; Measurable, with objective indicators; Achievable, ambitious yet proportionate to the resources; Relevant, tied to the project's strategic value; Time-bound, with clear deadlines or milestones.
And they must be few: one, two, three at the very most. If your list contains ten, you're mixing strategic priorities with operational actions. Objectives exist to orient; when they multiply, instead of giving a direction they create dispersion and fragment the group's energies.
S.M.A.R.T. Specific, measurable, achievable, relevant, time-bound.
Three at most. Ten objectives are a shopping list, hardly a route.
Non-negotiable. You discuss the how, never the why: otherwise the conversation slides into the "whether".
Boundaries of the playing field. Inside those boundaries the team works freely; it's precisely the perimeter that makes freedom possible.
The mistake of falling in love with the tool
There's a test worth running on every objective you formulate: are we defining an objective, or listing a tool? It's an extremely common mistake, swapping the "how" for the "why". "We want to adopt a new CRM to manage user requests" is a tool. "We want to reduce request handling times by 30%" is an objective — and the CRM is just one of the possible ways to get there.
Tools change, objectives remain.
Many innovation projects fail exactly here: energies concentrate on the solution instead of the problem. You fall in love with the brilliant idea, the newest technology, the most visible project, forgetting to ask whether it actually serves the purpose. It happens because tools give an immediate sense of concreteness — they can be bought, implemented, shown off — while objectives demand time, measurement and accountability. Only by keeping your attention fixed on the objective can you pick the right tool, never the other way round. This is what separates a transformation project from a mere exercise in style — a theme that also runs through Making Things That Work.
Then the field opens up
With the objectives communicated and the common ground built, the most stimulating part arrives: the collaborative work on the vision, typically in structured workshops. Here the design thinking approach is at its best, with its alternation between divergent, exploratory phases and convergent, focused ones — the Design Council's Double Diamond is the model I use most often to explain it. First you gather suggestions, aspirations, examples of strong visions; then you synthesize, trimming the redundancies, down to a clear and powerful formulation.
The leader's role, in this phase, is facilitating depth: asking the right questions instead of supplying answers. "Is this an action or a direction?" "Would this sentence still hold in ten years?" Because an authentic vision outlasts time: it's what remains when tools and processes have all changed. What characteristics the final result must have is the subject of A Vision Is a Compass; the overall frame of the journey is in Compass, Team, Fuel; and on what it takes for collaboration to actually work — because on its own it never suffices — there's Is Collaboration a Silver Bullet?