The Difference Between Teams Where “This Isn’t What I Expected” Happens and Teams Where It Doesn’t: How to Build Systems That Reduce Misalignment

The new feature was released without incident, and a sense of relief and achievement was quietly spreading through the company.
The engineering team had carefully fulfilled the requirements and completed quality checks.
“We’ve done it. This should move our customers one step closer to solving their problems.”

However, this “sense of achievement” is, at best, a feeling based on an internal perspective. Inside the company, judgments are made based on “as scheduled,” “no defects,” and “compliant with the spec”—criteria of “correctness as developers”—so the sense of relief at completion tends to be very strong.

Meanwhile, how customers, the recipients of the software, feel is often on a completely different axis from that internal sense of achievement.

That atmosphere was broken by a single message from a customer.

“Um… the new feature you added is a bit different from what we were expecting…”

In that moment, the entire team was wrapped in a frozen “Huh?” kind of mood.

Taking Stock of the Situation

In this project:

• We had interviewed the customer in advance about their requests,
• Sales had properly explained the content,
• A demo had been shared before release,
• Testing (QA) was complete,
• The engineers felt confident that they had “implemented everything correctly according to the spec,”

so as an internal process, things had been proceeding very carefully.

And yet, the customer came back with, “This isn’t what we expected.”

A heavy atmosphere spread through the team.

• “How could something like this have happened?”
• “Did someone make a mistake somewhere?”

This is by no means rare in software development.
If anything, you could say it’s a pitfall that tends to occur precisely when the process appears to be going smoothly.

We ourselves have witnessed this kind of situation many times.

There’s an invisible misalignment of “expectations” lurking between the people who build and the people who use. How to interpret that phenomenon is the theme of this article.

The People Involved and Their Positions

When something like this happens, each person involved has a different position and responsibility. It’s not about one specific person being at fault; rather, each person has their own “rightness,” yet there is a structural background that prevented things from meshing.

👨‍💻 Engineer

Role: The technical expert who designs and implements features according to the specified requirements gathered in interviews.

• Feels proud of having built everything according to the requirements
• “We weren’t told about any additional spec changes”
• Feels that, technically, nothing is wrong
• “We built exactly what we were told to. I don’t understand why we’re being criticized.”

“We built it exactly according to the spec—why are they saying it’s ‘not what they expected’…?”

🧑‍💼 Engineering Manager

Role: Ensures engineers’ work proceeds smoothly and maximizes the team’s output.

• Feels that there were no issues with the process itself
• But senses there may have been gaps in communication or contextual understanding
• “The team worked hard, and I don’t think there was anything fundamentally wrong with how we ran the project.”

“Is it right to ship now, or should we hold off and refine it more…? It’s hard because I can see both sides.”

🧑‍💼 Sales

Role: Faces the customer, relays their requests and background to the company, and is also responsible for maintaining the relationship.

• Thought they had explained everything properly to the customer
• But suspects there may have been parts that couldn’t be fully conveyed in words
• “I thought the client was on board… What did we miss?”

“Maybe I should have probed deeper and confirmed more at that time…”

👔 Executive / Business Owner

Role: Responsible for the overall business direction and outcomes, and must make decisions directly tied to release timing and competitive strategy.

• Deeply concerned about any erosion of trust
• Wants to focus less on blaming an individual and more on the team’s repeatability and trust-building
• “A small misunderstanding could lead to a major lost deal.”

“Protecting the team while maintaining customer trust—that balance is incredibly difficult.”

📋 Product Manager (PM)

Role: Oversees product planning, progress, and release, and is responsible for delivering value to users and the business.

• The person who organized the requirements and adjusted the scope
• Feels puzzled: “I thought I had communicated everything properly…”
• Stands between development and sales, feeling the limits of being a “translator”
• Easily feels accountable for the outcome, yet struggles with the difficulty of controlling everything

“How should I have handled expectations that couldn’t be fully put into words…? Maybe I should have pushed one step further.”

🙋‍♀️ Customer

Role: The end user who actually uses the service or feature, waiting with expectations for results.

• The requirements aren’t wrong, but they feel “something’s off”
• What’s most off is not the feature itself, but “how they had expected to use it”

“It’s not exactly wrong, but this isn’t really what we were looking for…”

Concrete Examples: “It Matches the Spec, But It’s Not What We Expected”

Here are some concrete examples that are common in the field: cases where things were “according to spec” but misaligned with expectations. Your own team may have had similar experiences.

📱 The Mobile View Was Not What They Expected

“It was perfect on PC, but when we opened it on a smartphone, the button was cut off…”

Background:
All design reviews and behavior checks had been done on PC, but actual users were expected to use it on smartphones during their commute. The assumed usage context was misaligned.

Key points:

• “Responsive support” existed as a requirement, but there was no shared understanding of “to what extent”
• The cause was not technical, but a shallow understanding of how it would be used

📧 Notification Specs Weren’t Standardized

“By ‘notification’ you meant email, right? Wait, weren’t we talking about Slack notifications?”

Background:
Everyone used the word “notification,” but each stakeholder had a different image in mind.
There was no alignment on timing, channels, or even the content of the messages.

Key points:

• The more abstract a term is, the more you need a shared definition
• It’s an area where “same word, different mental image” misalignments easily occur

🧾 The Output Format for Reports Didn’t Match

“We really need PDF. These are documents we have to submit.”
“Well, we thought CSV would be more convenient for aggregation…”

Background:
Even with the same need for “report output,” the desired format differed depending on the purpose. Within the customer’s organization, some people preferred PDF and others preferred CSV.

Key points:

• If you don’t ask “What will you use this for?”, you’ll end up misaligned
• It looks like a discussion about output format, but is actually a mismatch caused by insufficient understanding of the business workflow

🔁 Automated Sorting Backfired

“In the morning we process things in this order. If the order changes, it’s confusing…”

Background:
The development side thought “latest first” would be convenient, but on the ground, “order” equaled “work sequence.” There was an implicit business logic behind the ordering.

Key points:

• The user’s familiar workflow clashed with system automation
• What you think is an “improvement” can become a “change that causes confusion”

🗂️ Tagging Feature Isn’t Used

“They said it looks useful, but they don’t know how they’re supposed to use it.”

Background:
A flexible tagging feature was provided, but there were no operational rules, so no one used it. There was also no guidance on how to use it.

Key points:

• The more powerful a feature is, the more you need onboarding and usage guidance
• Only when you include “designing for actual use” can you really say a feature is “fully released”

What Structure Lies Behind These Misalignments?

Looking back at these examples, several common points emerge.

• The words matched, but there were subtle differences in interpretation
• Technically everything was correct, but slightly misaligned with user expectations
• How it would be used and the business background may not have been fully shared

There is a wider gap than we think between “according to spec” and “according to expectations.”

If we look back at the concrete examples we’ve discussed so far, we can see some shared backgrounds and structures in how these misalignments arose.
In none of them was the process broken, nor did any one person clearly make a mistake.
Yet small differences in interpretation and mismatched assumptions may have combined to produce the final misalignment of “This isn’t what we expected.”

If we zoom out a bit, we can see a gap like: “It’s properly finished, but for some reason the customer isn’t satisfied.”

It was built according to the requirements and is technically sound.
Even so, there seems to be some disconnect between what the customer had “pictured in their mind” and the actual “deliverable” they received.

Behind that misalignment, there are often nuances that never quite became words, business assumptions, and the background of expectations.

Common similar lines and examples:

• “I thought I did exactly what I was told, but somehow they got mad.”
• “I’m pretty sure it was written in the spec, but apparently it didn’t get across.”
• “They seemed really positive in the demo, but once it went live, complaints came out.”

In each case, there may have been small oversights or differences in interpretation in places where everyone thought they “understood.”

So what should we have thought and done in such situations?
Let’s continue by considering “hypotheses about the causes” and “measures we can take in the field.”

Where We Think Misalignment Arises

Looking back, there may have been several timings and structural aspects where misalignment had room to creep in.

Hypothesis 1: Expectations Were Never Explicitly Documented

The customer had expectations like “I thought it would work like this” or “I assumed we’d be able to use it this way,” but those expectations never made it into the requirements or documentation. In other words, there may have been an invisible gap between “I thought I told you” and “I thought I heard you.”

Hypothesis 2: Words Like “Easy to Use” or “Intuitive” Were Interpreted Differently

For example, even if a document says “Make it easy for users to use,” the image that the development team and the customer have in mind can be completely different.
Abstract words are convenient, but without concrete alignment, they easily become breeding grounds for misunderstanding.

Hypothesis 3: Alignment Meetings Became Formalities

There may have been “opportunities for alignment” such as interim reviews and regular meetings, but did they just end with “Looks fine”?
The act of “having a meeting” may have become the goal, and the original purpose of “truly checking mutual understanding” may not have been fulfilled.

Hypothesis 4: There Was an Assumption of “I’m Sure They Get It”

PMs and salespeople may have thought during conversations with customers, “This much must be getting across,” or later realized, “Oh, I might not have told the dev team that.”
In other words, unconscious assumptions may have piled up.

Solutions: How Can We Prevent Misalignment?

The kinds of misalignment we’ve seen so far seem to arise less from “someone’s carelessness” and more from “points in the process and relationships where misunderstandings are likely.”
It may be impossible to eliminate them completely, but with small practices and mechanisms, we can probably reduce the risk.

Below are some of the approaches we’ve tried in our own work and with clients. They’re not cure-alls, but we hope they’ll be of some help.

Introduce Ways to “Visualize” Expectations

Instead of relying solely on the feeling of “This should be fine” or “I’m sure they get it,” sharing the imagined “finished picture” early on can reduce misunderstandings.

• Create storyboards or simple prototypes (clickable mockups) to align on the feeling of “This is how it will behave when you actually use it”
• In addition to the spec, also write down the background: “What do we want to achieve with this feature?”, “How do we expect it to be used?”, and “Conversely, what kinds of use cases are out of scope or undesirable?”

Prototypes in particular allow you to confirm things in a “visible form” before implementation, creating a space to catch “This isn’t what we expected” early.

Change the “Quality” of Alignment Meetings

Many teams already have “checkpoints” such as regular meetings and interim reviews.
However, if those times are just for progress reports or end with “No issues,” they may not function as true alignment.

• Position review time not as “a place to check correctness,” but as “a place to jointly look for any sense of discomfort or mismatch”
• Show prototypes or screen designs and ask, “Does this behavior match what you had in mind?”

If you make “discovery” rather than “confirmation” the goal, it becomes easier to find the seeds of misalignment early.

Expand the PM’s Role from “Translator” to “Editor”

Product managers often serve as the bridge between business and development, tasked with “accurately conveying requirements,” but that alone may not be enough to prevent misunderstandings.

• Instead of just “The customer said this, so I’ll pass it on as-is,” take a moment to ask, “Is it really okay to deliver it in this form?” and “Will this wording actually get the idea across?”
• When necessary, have the courage to “edit” the requirements themselves; this can be crucial in preventing misalignment

If PMs can not only translate but also “interpret the background and intent and then edit,” the overall precision of understanding among stakeholders improves, which in turn can reduce misalignment.

First Steps: What Can We Try Right Now?

Being told “Use prototypes to prevent misalignment” or “Visualize expectations” can leave you wondering where to start.
We often hear this in the field when we’re supporting teams.

So here are a few ideas for small, easy first steps.
None of them require you to overhaul your team’s entire way of working. The goal is to reduce misalignment through small habits and tweaks in conversation.

Add a One-Line “Customer Expectation” to Your Requirements Template

When organizing requirements, jot down even a short note about the “background”: “Why do they want this feature?” and “In what situation do they want to use it?” For developers, that alone can dramatically change the mental picture.

For example, instead of just writing “Export feature,” write something like “We want to output a nicely formatted PDF for internal reporting.”

Prototype “Part of It,” Not “All of It”

It’s common to say, “It’s too much work to mock up every screen.” But just creating a simple mock in Figma for the flow users care about most, or for screens where misunderstandings are likely, is often enough.

The value lies in checking, “Does this actually convey what we mean?”

Add One Question to Interim Reviews: “Does This Match What You Had in Mind?”

In progress or spec review meetings, adding just one question can change the tone.

• “Does this behavior match what you were imagining?”
• “Does this screen feel like something users won’t get lost in?”

The intention is to turn the time into “alignment” rather than mere “confirmation,” which is the first step toward reducing misalignment.

Ask: “Is There Anything You Assume Is ‘Obvious’ and Haven’t Said Out Loud?”

People like PMs and sales, who interact with customers daily, have a lot of “gut feel.”
But that often doesn’t make it into documents, and “things that are obvious on the ground and therefore left unsaid” can become sources of misalignment.
In such cases, simply asking, “Is there any assumption you haven’t explicitly shared?” can surface valuable information.

How We Get Involved in These Challenges

In this article, we’ve explored the familiar misalignment of “This isn’t what we expected.”

Even if it’s hard to eliminate misalignment entirely, facing it carefully bit by bit can change team relationships and trust. We’ve seen many such transformations in the field.

On themes like this, we feel there are roles we can play precisely because we’re third parties.

For example, we can pick up on subtle discomforts that tend to be glossed over in everyday conversations, or deliberately put into words things that are hard to say internally. We can make structural misalignments—things everyone takes for granted and thus overlooks—visible from a neutral perspective.

Here are some of the ways we support teams:

• Introducing prototyping and user-story-based requirements organization
• Designing and rolling out requirements templates and “checklists of points to confirm”
• Designing facilitation for interim reviews and internal feedback sessions
• Supporting spec management to reduce “interface misalignment” between design and implementation
• Designing technical checklists that translate review points down to the code level
• Designing use-case-driven tests in the pre-implementation phase

None of these require special tools or major organizational reforms.
Misalignment gradually shrinks when you “change the way you work just a little” in your day-to-day tasks.

If similar frustrations have been lingering in your team, or if you’ve ever thought,
“Who am I even supposed to talk to about this?”
please feel free to reach out.

We’d be happy to start by thinking it through together with you.