SMART Goals: Built for Approval, Not Delivery
Most articles about SMART goals tell one of two stories. Either the framework is a reliable tool for turning vague intentions into actionable plans, or it is a bureaucratic ritual that gives organizations the appearance of rigor without the substance of it.
Both stories are true. The tension between them is the point.
This article holds both views simultaneously, because that is the only honest way to engage with a framework that has been in circulation since 1981 and shows no signs of disappearing. SMART goals work in specific conditions and fail in others. Understanding where that line sits, and why, matters more than defending or dismissing the acronym.
The frame for this argument is the NEOS project, a multi domain EV charging platform I led as Design Director in 2025. The project ran for nine months, covered five platforms, served two distinct user groups, and required meeting GDPR, PCI-DSS, and WCAG 2.1 AA standards while integrating real time charger data and supporting multilingual and right to left interfaces. It was the kind of engagement where goal setting decisions have real consequences, and where the gap between useful clarity and false confidence becomes visible in the work itself.
Part One: What SMART Goals Are and Why They Work
What the Framework Actually Says
SMART is a framework for writing and evaluating goals so that they are practical, rather than just aspirational. Each letter names a quality a well formed goal should have.
S — Specific
Specific means the goal answers the questions a team actually needs answered before it can start:
- What do we want to accomplish?
- Who is involved?
- Where does the work need to be delivered?
- Why does this goal matter, and to what degree does it need to be achieved
A vague goal like “improve the user experience!” gives a team nowhere to stand. A specific goal names the user, the flow, and the outcome, not the output! Specificity removes the space where assumptions and misalignments quietly grow.
M — Measurable
Measurable means there is a metric, or a set of metrics, that will tell you whether the goal has been reached. This is not about turning everything into a number for its own sake. Not every metric is meaningful, and choosing the wrong one can mislead a team just as badly as having no metric at all. The right question is what evidence would genuinely confirm that the objective has been met. Measurable goals create shared accountability. When a team agrees on the metric upfront, there is no room for post-hoc redefinition of success.
A — Attainable
Attainable means the team, having looked clearly at its constraints, available time, and resources, agrees the goal is realistic. This does not mean easy. Attainable goals can still be ambitious. The key distinction is between a goal that stretches capacity and one that simply exceeds it. Attainability also improves when large goals are broken into smaller, incremental steps: rather than trying to reach the destination in one leap, you define intermediate milestones that make the full journey navigable.
R — Relevant
Relevant means the goal fits the broader strategic direction of the organization and supports the actual purpose of the project. A goal can be specific, measurable, and attainable and still be irrelevant if it does not serve what the business actually needs. Relevance is the filter that keeps a team working on things that matter, not just things that are achievable.
T — Time bound
Time bound means the goal has a documented deadline or a clear timeframe. Without a deadline, even the most well-defined goal tends to drift. Time boundaries create urgency, help teams sequence work, and provide natural checkpoints for review and adjustment.
Together, these five qualities define a goal a team can act on with confidence. A goal written to all five standards becomes something like:
Complete the vehicle-first onboarding design and pass WCAG 2.1 AA accessibility review by the end of sprint four. That sentence tells the team what success looks like, when it is due, and what standards it needs to meet.
Specific Goals Drove the Right Research Questions
One of the earliest challenges in discovery at NEOS was resisting the temptation to treat the user problem as obvious. The initial framing suggested the platform needed to solve charger discoverability: drivers could not find stations easily, so we needed better maps and broader coverage.
Research revealed something more specific. Drivers were not failing because they could not find stations. They were failing because they arrived at stations without confidence in availability or compatibility. The anxiety was not about discovery. It was about trust under uncertainty, particularly when a driver’s battery was low and the cost of a wrong choice was high.
This shifted the goal from a broad directive like “improve station discovery” to something precise: design a vehicle first onboarding flow that captures the driver’s car model once, then automatically filters every station and charger surface to show only compatible options.
That goal answered all the specificity questions: what it accomplished, who it served, where it would be delivered, why it mattered, and to what degree it needed to work. The specificity of that goal then made every subsequent design decision easier to evaluate.
If a proposed UI pattern did not serve a driver in a low-battery, high-anxiety moment, it did not belong in the core flow.
Attainable Goals Kept the Team Grounded
A 9 month engagement covering five platforms, two distinct user groups, and multiple compliance standards is not trivially achievable. The risk in that kind of scope is not ambition. The risk is overcommitment: a team that tries to do everything at once and delivers nothing well.
Attainability shaped how we sequenced the work. We built the design system from zero to a full component library in six weeks, with platform specific adaptations and accessibility baselines. That timeline was aggressive, but it was attainable because we broke it into incremental deliverables: core tokens and primitives first, then component variants, then platform adaptations. Each step was achievable in itself and built toward the larger goal.
We also used PERT estimation to avoid the trap of single-point time estimates. For each task, we defined optimistic, most likely, and pessimistic effort, then calculated average. This gave us plans that accounted for uncertainty: approval delays, dependency blockers, and rework. Attainable goals are not just about what is theoretically possible. They account for the real conditions a team operates in.
When CarPlay exploration stayed at low fidelity longer than it should have, we paid for it with a week-15 interaction revision. Attainability is not just about capability. It is also about timing.
Relevant Goals Aligned Individual Contribution to Purpose
My role at NEOS was not simply assigning tasks to get work done. It was finding the right person for the right feature, aligning individual interests with company goals. That principle is an application of the relevance criterion.
For the design team, every feature assignment was framed against two guiding questions: are we building the right thing, and are we building the thing right? When research revealed that operators were repeating status updates across multiple tools, we did not simply design a cleaner version of that repetitive workflow. We questioned whether the workflow itself was relevant to the operator’s actual goal: keeping user-facing station data accurate in real time. The answer led to an action sync flow that reduced repetitive manual overhead entirely.
Relevance also meant connecting individual ownership of features to what each designer cared about. Designers interested in accessibility owned the WCAG audit and remediation work. Designers with a systems mindset took on component architecture. The goals each person worked toward were relevant not just to the project but to the kind of work they were developing as practitioners. That alignment produced better work and more sustained engagement.
Time Bound Goals Created the Conditions for Iteration
The NEOS timeline ran from March to December 2025. Within it, the work was not linear. We ran sprint cycles integrating Agile, Double Diamond, and Lean UX principles into a single way of working. Each sprint had defined goals with deadlines for refinement, peer review, and sign-off.
Time boundaries did more than create urgency. They created natural checkpoints for asking whether the current direction was still the right one. The heuristic evaluation we ran before user testing was time bound: complete before validation begins. That constraint forced us to resolve nine critical usability issues before inviting real users into the experience. Those fixes improved the signal quality of subsequent testing because participants were not spending their time reacting to obvious interface failures.
Time constraints also surfaced trade-offs we might otherwise have deferred. Connector auto detection remained a version one assumption because the evidence needed to validate it at scale would only come from live session data after launch. Defining that goal as time bound meant we shipped a well reasoned assumption rather than holding the release waiting for certainty that was not yet available.
Part Two: Where SMART Goals Break Down
The Redundancy at the Core of the Acronym
SMART gives you five letters, each presented as a distinct dimension of a well formed goal. In practice, three of those five letters check almost exactly the same thing!
Measurable asks: can you track progress toward this goal?
Attainable asks: can this actually be done given the constraints?
Time bound asks: is there a deadline that makes completion possible to evaluate?
These three questions are not independent. They are three different angles on the same underlying assumption: that you can define the scope and effort of the goal with enough confidence, at the moment of writing it, to commit to a number, a timeline, and a judgment about feasibility.
M, A, and T are all planning assumptions. They do not check different things about the work. They check the same thing from slightly different vantage points: is the plan credible? If that planning assumption is sound, all three pass together. If it is not, all three fail together.
You do not get extra information from asking the question three times with different labels. — Ali
What this means in practice is that SMART appears more rigorous than it is. Five-dimensional evaluation sounds thorough. But when three of those dimensions collapse into a single question, the framework produces a false sense of completeness. Teams finish writing a SMART goal and feel like they have done the analytical work, when in many cases they have mostly rehearsed one assumption from multiple angles.
The Planning Assumption Problem
The deeper issue is what the planning assumption requires you to believe.
Writing a Measurable, Attainable, Time bound goal requires that you know enough about the work, at the start, to say: this is what done looks like, this is how long it will take, and this is how we will measure it.
Get Ali E. Noghli’s stories in your inbox
Join Medium for free to get updates from this writer.
This is reasonable in certain contexts. If you are ordering materials for a construction project or scheduling a license renewal, the work is well understood, and the timeline is largely within your control.
SMART works well for tasks where the scope is stable and the unknowns are manageable — Ali
Product design, software development, and most knowledge work are not that kind of work. They involve discovery. The problem you are solving at the start of a sprint is rarely the same problem you understand by the end of it. Research redirects. Prototypes reveal contradictions. User testing surfaces behaviors that no one predicted. Engineering constraints shift what is feasible.
In that environment, a goal that was Measurable, Attainable, and Time bound when written can become wrong in each of those dimensions by the time the team is halfway through the work, not because the team was bad at planning, but because the work itself taught them something that changed the picture. SMART does not have a mechanism for this. It is a framework for writing goals, not for revising them in response to what you learn. And because goals written in SMART format tend to carry organizational weight, tracked in planning sessions and reported in dashboards, changing them in response to learning can feel like failure rather than adaptation.
Objectives as Direction, Not Destination
In Lean and Agile thinking, the purpose of a goal is different from what SMART assumes.
Lean is built on reducing waste: eliminating work that does not contribute to value. Two of the most significant forms of waste are overproduction, building more than you have validated, and waiting, spending time on decisions that can only be made once you have more information.
Agile is built on inspecting and adapting: using short cycles to generate real feedback, then changing direction based on what that feedback tells you. The value of an Agile sprint is not completing a pre-specified plan. It is producing a testable increment and using what you learn from it to inform what comes next.
Both Lean & Agile frameworks treat objectives as direction, not destination. You know roughly where you are trying to go, and you commit to a step in that direction, but you do not treat the destination as fixed. You treat it as your current best hypothesis, subject to revision as evidence accumulates.
SMART goals are built on the opposite assumption. They treat the destination as fixed and the path as knowable in advance. The entire structure privileges the intelligence available at the start of a project over the intelligence that only becomes available through doing it. In Agile and Lean terms, a SMART goal written at the beginning of a project embeds a planning assumption that will almost certainly be outdated before the project is done. The question is not whether it will change, but whether the team has the organizational permission to change it without that being treated as a failure.
The Organizational Approval Function
The SMART acronym has been in circulation since George Doran published it in a 1981 management paper. It has survived over four decades not primarily because it produces better outcomes, but because it serves a particular organizational function: it gives managers and executives a legible format for approving work.
A goal written in SMART format is easy to review. It has a clear deliverable, a metric, a timeline, and an implied cost estimate. It is easy to put in a quarterly planning document, present to a board, and track in a progress dashboard. It signals that the team has thought carefully about what they are committing to.
That signal is useful to organizations. It creates accountability in a form that leadership can evaluate. And that is exactly the problem.
The format is optimized for legibility to stakeholders, not for accuracy about the work.
A team writing a SMART goal learns to ask: will this satisfy the approval process? — Ali
They learn to scope the goal in a way that is defensible, not necessarily honest about the uncertainty involved. They learn to write timelines that feel attainable rather than timelines that reflect what the work actually requires. They learn to define metrics that can be reported confidently rather than metrics that genuinely capture whether value was created.
The result is planning theater: goals that look rigorous in documents and presentations but do not reflect the real complexity of what the team is navigating. The acronym survives because it serves organizational approval processes, not organizational delivery.
What This Looks Like in Real Work
Look at the NEOS examples from Part One through a Lean and Agile lens.
The vehicle first onboarding goal was not defined at the start of the project. It emerged from research. The initial framing was about charger discoverability. Research revealed that the real problem was trust and compatibility anxiety. The specific goal only became visible after the work of discovery had been done. If the team had written a SMART goal at the outset that was Specific and Time bound around charger discoverability, that goal would have pointed the work in the wrong direction.
The A/B Test result showing that removing the “Find a Station” CTA improved session initiation by 20 percentage points contradicted what moderated testing had suggested. That finding was not predictable before the work was done. It was only accessible through the work itself.
In both cases, the actual decision-making was driven by what was learned, not by what was committed to in advance. The SMART framing was applied after the fact to communicate outcomes, not before the fact to guide decisions. That is a meaningful distinction. When SMART goals are used as retrospective framing for outcomes that were actually shaped by iterative learning, they tell a cleaner story than the work deserved. They make discovery driven work look like prediction driven work, which can mislead an organization about how good design and delivery actually happen.
The Measurement Problem in Creative Work
Not everything that matters is measurable in the way SMART implies. A design system built with genuine care for component reuse, accessibility, and future maintainability creates value that does not show up in sprint velocity or feature delivery count. The quality of a research protocol, the rigor of a heuristic review, the judgment exercised in a design decision: these are not easily quantifiable, and demanding that they be measured to count as goals pushes teams toward optimizing for what can be tracked rather than what actually creates value.
Lean thinking has a specific term for this dynamic: Goodhart’s Law, often summarized as when a measure becomes a target, it ceases to be a good measure. As soon as you define a metric for a goal, you create the conditions for the team to optimize for that metric in ways that diverge from the underlying purpose the metric was meant to track. Session initiation rate is a useful signal, but a team that chases it as a primary metric can make choices that boost the number without improving the experience.
SMART’s Measurable criterion does not protect against this. It demands that a metric be chosen and documented, but it has no mechanism for ensuring that the metric remains a genuine proxy for value rather than becoming a target the team games, consciously or not.
The Time Bound Trap in Uncertain Work
Time-bound goals create urgency. Urgency is sometimes exactly what a team needs. But urgency and speed are not the same thing.
In Lean thinking, speed comes from reducing waste: eliminating steps that do not add value, clearing dependencies, shortening feedback loops. Urgency without waste reduction often produces the opposite of speed. It produces decisions made too early, validations skipped to hit a deadline, and design debt that slows the team down in every subsequent sprint.
Agile sprints are time boxed, which can look similar to SMART’s time bound criterion. But the purpose of a time box in Agile is different. It is not to commit to delivering a specific scope by a specific date. It is to create a regular rhythm for delivering something testable, learning from it, and adjusting. The scope inside a sprint is expected to be revised based on what the team learns. A SMART goal is not designed for that kind of revision.
When a Time bound SMART goal meets real Agile delivery, one of two things tends to happen. Either the team delivers the committed scope on time by cutting quality, skipping validation, or ignoring new information that emerged during the sprint. Or the team misses the deadline and faces the organizational consequence of an unmet SMART goal, which discourages honest planning in the future. Neither outcome serves the team or the organization.
Part Three: A Practical Reconciliation
When to Use SMART and When to Let It Go
The honest case is not that SMART goals are always wrong!
For stable, well understood work with defined outputs, they are genuinely useful. Administrative tasks, compliance requirements, personal productivity goals with clear scope: the framework helps because the conditions the framework assumes are actually present.
The honest case is that SMART goals are often applied to work that is not stable, not well understood, and not fully defined at the outset. In those contexts, the framework does not serve the work. It serves the appearance of planning rigor.
The distinction that matters is not the type of industry or the seniority of the team. It is the nature of the work itself. Is the path to the goal discoverable before starting, or only through doing? If the former, SMART is a reasonable tool. If the latter, SMART will produce a plan that looks thorough on paper and becomes misleading in practice.
What Lean and Agile Teams Need Instead
Rejecting SMART does not mean rejecting direction or accountability. It means choosing tools that are honest about the nature of complex work.
Objectives and Key Results, properly applied, come closer to the Lean and Agile ideal.
An objective is a qualitative statement of direction: where are we trying to go, and why does it matter?
Key results are signals that would indicate movement in that direction, not commitments to specific outputs by specific dates.
OKRs, when they work, treat the objective as a compass heading and the key results as evidence of movement, not as a definition of the destination.
Lean-Agile planning rhythms, where goals are set at the direction level and execution is planned in short cycles based on what is currently known, distribute the intelligence of goal setting across the life of the project rather than concentrating it at the start. They acknowledge that the team will know more in week eight than they knew in week one, and they create structures that use that later knowledge rather than locking it out.
The Two Questions That Replace Five Letters
At NEOS, the most useful goal setting tool was not a five letter acronym. It was two questions applied continuously, sprint by sprint: are we building the right thing, and are we building the thing right?
The first question is about direction and relevance. Does this genuinely solve the user’s problem? Does it support the product strategy? It prevents the team from executing well on the wrong problem.
The second question is about execution quality. Is it technically sound, accessible, and scalable? It prevents the team from moving fast toward a destination that cannot be sustained.
These two questions do not produce a plan. They produce a discipline of evaluation that applies at every decision point, as the work reveals what the right thing actually is. They do not require a metric to be named before the work starts. They require only that the team keeps asking, honestly, whether it is still moving in the right direction.
That kind of discipline does not fit neatly in a five letter acronym. But it is what actually moves complex work forward.
Closing
SMART goals are simple in description and demanding in practice. Writing a genuinely specific goal requires that you have done enough thinking to know what you are actually after. Writing a measurable goal requires that you have agreed on what evidence matters. Writing an attainable goal requires honest accounting of time, capacity, and constraints. Writing a relevant goal requires that you keep the broader purpose in view. Writing a time bound goal requires the discipline to set a deadline and hold it.
In the right conditions, that discipline is valuable. At NEOS, it helped a team stay aligned across a nine month engagement, communicate progress clearly to stakeholders, and recognize when the work had arrived where it needed to go.
But the framework carries assumptions that do not survive contact with discovery driven work. It was designed for a world where plans are made, then executed. Most product work does not happen in that world. It happens in a world where the act of doing the work is what reveals what should have been planned.
