Disclaimer: the concepts here are likely universally applicable, irrespective of industry. Feel free to replace any software product development concepts with any relevant terms of art in your industry—these lessons should hold.
In many technology teams, “done” is synonymous with “delivered.” We ship features, release products, and check items off the roadmap. Yet this becomes a problem: many teams become so focused on delivery that they lose sight of the real goal — creating impact.
Putting deliverables over outcomes leads to dysfunction. It erodes team morale, fuels distrust between engineers and product managers, and ultimately results in wasted effort. Deliverables are things we produce, but outcomes tell us whether we’re actually succeeding.
Here are some of the dysfunctions that will inevitably arise in such an environment:
1. The “Ship It and Forget It” Mentality
This is a classic mistake. The team races toward a deadline, deploys a feature, high-fives each other on Slack, and moves on. But no one stops to confirm:
Did it work?
If teams don’t measure impact, they’re essentially throwing darts blindfolded. Was the feature meant to increase engagement? Reduce churn? Improve performance? Drive customer satisfaction? Reduce costs? Is it even being used?
If the answer is “We don’t know,” then there’s a problem.
One way to define “done” is something like this: code merged, tests passing, CR approved, feature pushed to production, and JIRA ticket closed as “done”.
This definition does not take impact into consideration. Another way to define “done” could look something like this: it made the impact expected, as observed with data, or it has been shut down because it didn’t.
Anything short of that? You’re probably just moving tickets around. Let’s be real—what’s more demotivating than building something nobody uses?
Of course, this requires the existence of predetermined, measurable success criteria. It requires time to be set aside to observe the results of these measurements, and a series of thoughtful decisions around what to do next. Do you claim success, continue to invest, or cut bait? What’s the expected return of that decision?
Healthy teams don’t celebrate shipping. They celebrate impact.
2. Enter, Cynicism: They Can See the Data
Engineers aren’t naive. They know when a feature they built isn’t getting used. They see when something hyped as a “game changer” quietly fizzles out. When this happens repeatedly, cynicism sets in.
A predictable cycle emerges:
- A product leader declares, “This feature will save the company!”
- Engineers rush to build it.
- The feature flops.
- Engineers roll their eyes the next time leadership makes a big claim.
Over time, this creates a toxic distrust between product and engineering. Engineers don’t resist building—they resist wasting their time on things that don’t create value.
Contrast that with healthy teams: Product managers rigorously prioritize work, ensuring engineering time is spent on high-impact initiatives. They treat engineering effort as a scarce resource—not something to be thrown at every idea that sounds good.
When this happens, trust builds. Engineers stay engaged. The work feels worth it.
3. Misaligned Metrics: Rewarding the Wrong Things
One reason teams fall into the deliverables-over-outcomes trap is that they’re being measured on the wrong things.
If success is measured by metrics such as number of features shipped, story point throughput per sprint, sprint completion rates, roadmap on time delivery percentages, then teams will game these metrics optimize for these, regardless of whether they solve real problems.
These are proxy metrics, not success metrics. The real goal isn’t to ship—it’s to drive meaningful customer and business outcomes. Outcomes such as:
- Engagement
- Revenue
- Retention
- Satisfaction
- Performance
- Cost
…and so on. A feature that doesn’t move these numbers probably isn’t a success, no matter how “on time” it was.
Optimize for results, not just releases.
4. Success Theater: The Art of Pretending to Work
Every org has some form of “success theater”—a pristine Jira board, dashboards full of green checkmarks, product updates filled with impressive-sounding releases, large steering committee meetings with well-prepared powerpoint decks.
But when you zoom out and ask, “Did any of this actually move the needle?”—sometimes the answer is not really.
This is what happens when teams focus on activity instead of impact. They feel productive but aren’t necessarily creating value.
A touch of polite honesty can go a long way. “Was this really a success if no meaningful impact was achieved?” and “Why are we celebrating work that made no real impact, instead of retrospecting on what went wrong?”
Teams that put outcomes over optics are less likely to engage in self-deception. Stronger introspection leads to better future decisions, which leads to better products.
Remember: the tickets aren’t the work!
5. Quality: A Casualty of Meaningless Deadlines
When outcomes aren’t the priority, quality is the first thing to suffer.
In a world where success is defined by “Did we ship [on time]?” rather than “Did we solve the problem well?”, engineers will perceive scope and deadlines as fixed constraints — which means the only buffer available is quality.
This can lead to a dangerous mindset: hit the deadline, no matter what. The result?
- Brittle features get shipped. Engineers don’t have time to think about anything other than the happy path, users struggle with functionality that doesn’t quite solve their need or breaks in unexpected ways.
- Customer frustration increases. If a new capability is doesn’t meet the need, is hard to use or unreliable, it doesn’t matter that it was delivered “on time”—because in practice, it’s still unusable.
- Sales & account teams lose faith. Repeatedly bringing incomplete, broken, or irrelevant products to their customers burns salesperson credibility, causing future product activations to take longer to result in commercial success. Politics takes over – “we can’t hit our numbers because…”
- Technical debt skyrockets. Shortcuts pile up, making future development harder and slower.
Engage with customers early and often, and be willing to use their feedback to flex on scope and deadline. Teams that prioritize being responsive to customer feedback and allowing it to inform decisions on scope and timing are more likely to deliver customer delight.
Shipping something that doesn’t work isn’t really shipping. It just means you delivered a problem instead of a solution.
How to Shift from Deliverables to Outcomes
So, how do you fix this? How do you move from shipping features to shipping impact?
1. Reorient Your Purpose
Unifying your team around a clear mission that orients everyone towards customer delight will in itself start to change the culture. Infusing client-centricity into the everyday language of product managers and openly sharing customer needs, wants, and pain points amongst the team will help build a strong foundation of context for the team.
2. Redefine “Done”
A feature isn’t done when it ships. It’s done when it’s either successful or killed. If it hasn’t delivered value—or if you haven’t explicitly shut it down—you’re not done.
3. Measure What Matters
Optimize for results, not releases. The right KPIs focus on business impact, not just feature count or velocity.
4. Ruthlessly Prioritize
Engineering time is the most constrained resource in almost any technology company. Treat it like gold. Don’t waste it on things that won’t matter.
5. Be Willing to Kill Things
Not every idea works. That’s fine. What’s not fine is keeping dead features alive out of inertia. If something isn’t delivering value, shut it down or be willing to accept the perpetual tax of cognitive overhead, reduced development velocity, and increased levels functional and security risk. Admit when ideas fail. Kill them. Move On. It’s a form of growth.
6. Embrace Flexibility
Be willing to pivot. Most deadlines are arbitrary and often exist to streamline coordination. Customers don’t really care about your internal processes.
Choosing to maintain those deadlines at the expense of negative customer satisfaction is a form of revealed preference!
It’s About Impact, Not Output
Shipping software is easy. Shipping impact is hard.
Effective teams know the difference. They don’t treat work as a series of tickets to close. They treat it as the process of solving real problems for real people, in a way that moves their business forward.
So next time you hear someone say, “That feature is done,” ask them:
Did it make an impact? Or did we just mark a ticket as complete?
Because in the end, impact the only definition of “done” that really matters.