Especially when a team is facing a requirement that “looks familiar,” the biggest danger is often not that we do not understand it, but that we assume too quickly that we already do.
When we truly do not understand something, at least we know we need to ask questions, seek information, consult experts, and obtain validation.
But when we all assume we already understand it, we can easily overlook details that deserve attention but go unnoticed.
This “we already understand this” mindset often causes teams to overlook the assumptions behind requirements, the usage scenarios behind specifications, and the gaps between test conditions and the real environment.
In my previous articles, I discussed how to identify the needs behind the requirements, the assumptions behind them, and the risks behind them.
In this article, I want to go one step further and discuss another issue that PMs often encounter, but may not always recognize easily:
Past experience itself can also become a project blind spot.
Because many project problems do not happen in areas where the team knows nothing.
They happen in areas where the team believes it already knows.
The Hidden Risk of “We Already Understand This”
My team and I stepped into a similar trap many years ago.
At the time, we were working on an ODM project for a smart home doorbell. The customer wanted to use this doorbell product on the front and back doors of luxury homes in a South American country for home monitoring.
One requirement in the specification was:
Night Vision distance must reach 30 meters.
In other words, the night vision distance had to reach 30 meters.
For a team with experience in surveillance products, this requirement did not look unfamiliar at first glance.
For a camera to support night vision, the basic idea is to use a suitable image sensor, IR LEDs, lens, exposure settings, and image processing. People who have worked on similar products before can easily make an intuitive judgment: this is not a particularly new requirement.
But that was exactly where the problem began.
It was not that we knew nothing about night vision.
On the contrary, because we had done it, tested it, and seen it before, we did not break down this requirement in sufficient detail at the beginning to confirm the assumptions behind it.
During the project, we encountered many other issues, but none of the major issues were related to night vision.
It was not until the samples were delivered to the customer in South America that we discovered a serious problem with the night vision function.
In one online meeting, the customer played a test video. The image was almost completely dark. Then they asked us:
“Why can’t this night vision see anything beyond 5 or 6 meters? Our requirement is 30 meters.”
On the Taiwan side, all of us looked at one another in confusion.
Before shipping the samples, we tested them in Taiwan, and the results were acceptable.
At first, some people even wondered whether the devices or components had been damaged during shipping.
But if the issue had been caused by shipping damage, it was unlikely that all samples would show the same problem. Besides, all other functions were working normally.
After a long discussion, we gradually realized the real issue:
The customer’s test environment differed significantly from the one we simulated in Taiwan.
To test the distance, both sides performed outdoor testing.
But the biggest difference was that the “open space” in the customer’s backyard and the “open space” we found in Taipei City were not the same thing at all.
Although infrared light is a common supplemental light source for camera night vision, it is still a light source by nature.
And since it is a light source, the image can only be seen clearly when there are objects to reflect the light, or when there is some other ambient light to help.
Outside the customer’s back door was a very large, open garden. Other than a small light near the doorway, there was almost no other light source.
Beyond the back door was a large grassy area with no walls, cars, buildings, or other nearby objects that could reflect IR light.
So what the customer saw was darkness.
But in our test environment in Taiwan, even in an outdoor open space, there were still streetlights, buildings, walls, ground reflections, city lighting, and various forms of ambient light nearby.
These conditions, which we were so used to, had silently introduced many assumptions into the night vision results that we did not consciously notice.
So, what we saw in Taiwan was a relatively clear night-vision image.
What the customer saw in the backyard of a luxury home in South America was a dark image where almost nothing could be recognized beyond 5 or 6 meters.
In the end, the issue was resolved through a negotiated compromise between both sides.
But the additional work hours, design changes, repeated validation, and increased cost were all still there.
The Specification Was Not Wrong. We Did Not Ask Clearly Enough About the Conditions Behind It.
Looking back, this was not simply a technical problem.
The requirement “night vision distance must reach 30 meters” seemed clear on the surface, but it actually contained many unstated assumptions.
For example:
Under what environment does this 30-meter distance apply?
Is it in complete darkness, or with ambient light?
Is it an indoor corridor, a semi-open driveway, or a fully open backyard garden?
Are there walls, ground surfaces, cars, plants, buildings, or other objects in the scene that can reflect IR light?
Does the customer need to “see that someone is there,” or do they need to “clearly recognize a face”?
Is the test standard subject visible, face recognizable, or image usable?
Are the front door and back door environments the same?
Is the image quality still acceptable in daytime and nighttime, under sunny and rainy conditions, and in dry and humid environments?
What we validated at the time was:
Whether the IR LEDs could make the image visible at a sufficient distance in a typical outdoor environment in Taiwan.
But what the customer actually needed was:
Whether the image could still be seen clearly in a large, open, low-reflection, low-light backyard environment at a luxury home in South America.
These are two completely different things.
And this is a very common problem in projects:
The team believes it is validating the same requirement, but the usage scenarios in each side’s mind are completely different.
How Could GenAI Have Helped at the Time?
If we had GenAI assistance at that time, it probably still would not have magically told us:
“The customer’s backyard is a large, open garden, so the 30-meter night vision will fail.”
AI does not know the on-site information that it has not been given.
But if we had included some key context and asked AI in the right way, it might have helped us ask better questions earlier.
For example, we could have asked:
“We are developing a smart video doorbell for luxury homes in South America. The product will be installed at both the front and back doors for home monitoring. One requirement says: night vision distance must reach 30 meters. Please help me identify the hidden assumptions behind this specification, the usage scenarios we should confirm with the customer, and the test conditions that should be included in the validation plan.”
In that case, AI might have reminded us:
- Night vision distance does not depend only on whether the IR LEDs are bright enough.
- It also depends on whether the site is completely dark.
- Are there walls, ground surfaces, cars, buildings, or plants nearby that can reflect infrared light?
- How far is the target that needs to be seen from the camera?
- At what height and angle is the camera mounted, and how well does the lens perform in low light?
- Does the direction and coverage of the infrared light actually cover the target area?
If any of these conditions are different from the original test environment, the actual effect of “30-meter night vision” may be completely different.
These reminders may not directly give us the answer, but they can help the PM realize earlier:
This specification is not only a hardware capability issue. It is also an issue with usage scenarios.
This is also what I have been emphasizing in my previous articles: using AI is not just about writing a longer prompt. It is about framing the problem properly and building enough context so that AI has enough information to respond in the right direction.
As long as the PM realizes this earlier, the PM can go back to the customer earlier and ask:
“When you say 30-meter night vision, what kind of scenario are you referring to? Do both the front door and back door have lighting? Are there walls or other reflective objects in the backyard? Do you expect to see only the outline of a visitor, or do you need to recognize the person’s face?”
If these questions had been asked before the design was finalized, the project might not have incurred such high rework costs later.
The Value of AI Is Not to Help PMs Pretend They Understand. It Is to Help PMs Discover What They May Not Yet Understand.
Using AI to produce documents, write requirement specifications, organize meeting notes, generate project plans, rewrite customer emails, or create a presentation outline are all areas where AI can be very useful.
But in project management, the greater value of AI lies in helping PMs avoid the blind spots that experience can create.
Experience is an asset.
But it can also cause a team to mistake “a judgment that was valid under one specific context” for “a fact that is true in all contexts.”
We have built similar products before. Does that really mean this one will be similar, too?
We have tested a similar environment in Taiwan before. Will the conditions remain the same when the product is used in the customer’s real-world environment in South America?
When we say we have already validated the specification, did we actually validate the specification itself, or only the test scenario we were familiar with?
These are the kinds of questions PMs should ask AI more often.
Because AI does not necessarily understand the product better than the PM.
It does not necessarily understand the technology better than the engineers either.
But if we provide enough clear context, AI can help us re-examine requirements from different angles, break down assumptions, challenge existing judgments, and remind us which seemingly obvious points still need to be confirmed again with the customer.
Past experience is still important.
But with a new customer, a new market, and a new usage scenario, past experience should not be treated directly as the answer. It should be re-examined.
So when PMs use AI, do not only ask:
“Please help me write this document faster.”
Ask instead:
“Please help me see which parts I thought I already understood but have not yet fully validated.”
That is where AI becomes truly valuable for PMs.
Not replacing the PM’s experience, but helping the PM see the boundary of that experience.