To Seem Rather Than to Be in Business and Product Development

North Carolina

I like North Carolina. I have spent many years here; it has a beautiful coast and nice mountains to beat the summer heat.  I have learned that wherever I live, it must be a place with mountains and a coast – and not a giant lake.  This limits where I live to a few specific states.

North Carolina’s state motto is Esse Quam Videri—“To be rather than to seem.” It is a compact statement about substance, character, and reality. What we are should matter more than the appearance we create.

Now flip it: Videri Quam Esse—“To seem rather than to be.”  I say flip it because it seems to me that some companies believe appearance matters more.

I thought I had written about this in a blog post in the past, but I could not find it, sadly. It might have gotten lost in the many website updates over the years.  I think this is important.  In my “career,” executives have at times tried to coerce me into saying or recording the state of the project or testing results in a way that camouflages the situation, rather than stating it honestly and accurately.  A book that I did not write on this topic is DoubleSpeak. I like this book, even if some of my colleagues do not.

I do not mean that as an alternative motto. I mean it as a metaphor for something not uncommon in business and product development: doublespeak. The words say one thing while the conditions behind them say something else. A delay becomes a “schedule adjustment.” A defect becomes a “product experience issue.” A missing capability becomes a “future-state opportunity.” The language creates the appearance of control while making the real condition harder to see.

That reversal describes more organizations than most leaders would like to admit. It appears when the presentation is stronger than the underlying plan, when the process documentation looks more mature than the work itself, or when a prototype is presented as evidence of production readiness. The organization appears capable, disciplined, innovative, or customer-focused, but the systems required to support those claims are incomplete.

The organization does not necessarily tell a direct lie. It does something more subtle. It selects words that soften consequences, blur responsibility, and allow different people to hear what they want to hear.  To avoid conflict.

That may reduce discomfort in the meeting. It does not reduce the risk in the product or the business.  

If an organization continually calls failures “challenges,” layoffs “workforce optimization,” defects “product-experience issues,” and missed commitments “schedule realignment,” people gradually lose the vocabulary needed to discuss what is actually happening.

Doublespeak Does Not Have to Be False

I read a book; I didn’t write this one, but I wish I had.  That book is called Doublespeak, and I need to give it the recognition it deserves (some of my colleagues are not a fan of the work).   I don’t know why, and it might be that this book doesn’t accurately reflect their experiences.  From my perspective, this is not an occasional occurrence.  Some of the areas per the book are:

• Euphemism

  Euphemisms can be compassionate and legitimate. Saying someone “passed away,” for example, may demonstrate sensitivity. A euphemism becomes doublespeak when it is used to hide responsibility, minimize harm, or make an unacceptable condition sound harmless.

• Jargon

  Specialized terminology can help experts communicate efficiently. It becomes doublespeak when professionals use it with people who cannot reasonably understand it—particularly when that confusion protects the speaker or obscures an important consequence.

• Gobbledygook or bureaucratese

  This involves burying a relatively simple fact beneath excessive words, abstractions, qualifications, and complicated sentence structures. The audience hears something that sounds authoritative but cannot determine what happened, who acted, or what the consequences are.

• Inflated language

  Inflated language makes ordinary activities sound exceptional, sophisticated, or important. It can also make failure sound like strategy and retreat sound like progress. The wording increases the perceived value or acceptability of something without changing its underlying reality.

is effective because the words can be technically defensible. The problem is not always that a statement is false. The problem is that it is constructed to produce an impression that the evidence does not support.

Consider the sentence, “The launch date remains achievable.” That may be true in the narrowest possible sense. Anything is achievable if enough assumptions break in our favor, enough people work nights and weekends, and no additional problems emerge. But the sentence can conceal unresolved requirements, incomplete testing, late tooling, unstable software, or a supplier that has not demonstrated process capability.

The words communicate confidence. The system contains uncertainty.

This is the essence of product development doublespeak: language that makes the work sound more mature, controlled, or complete than it really is.

Doublespeak does not eliminate product risk. It merely delays recognition until testing, production, customers, or the physical product reveals what the language concealed.

An Example

There is a project underway. The testing is set to begin upon delivery of the sub-assemblies, provided by a captive supplier – a supplier from within the OEM company.  The supplier needed the testing to take 2 days from the day of delivery. The project manager is involved in the discussion with the supplier. As the verification manager, I understood that integration testing would take much longer than 2 days to cover the riskiest feature content.  The project manager told the supplier that the team would do its best to complete the testing in 2 days.   There was no way this was possible, or as my Irish colleagues would say, Slim to none, and Slim is dead.  This leaves the impression that what they expect could actually happen.

The Corporate Translation Table

Most experienced people have heard some version of these statements. Not every use is deceptive, but each should trigger a request for more precise information.

These phrases are not automatically wrong. Context matters. However, when the language removes the actor, evidence, consequence, or next decision, it is no longer helping people understand the work. It is helping the organization avoid understanding it.

Product Development Is Especially Vulnerable

Product development creates fertile ground for doublespeak because the work contains legitimate uncertainty. Early in development, the team does not—and cannot—know everything. Estimates change. Tests uncover new information. Prototypes fail. Suppliers encounter problems. Learning is expected.  It might be better to distill this to something simpler or to language that is specific and easy to interpret, unless the team shares a common lexicon.

That uncertainty is not a weakness. Hiding it is.

When leaders demand certainty that the evidence cannot provide, teams often respond by changing the language. A low-confidence estimate becomes a commitment. An assumption becomes a planning basis. A prototype demonstration becomes proof of readiness. A partially executed verification plan becomes “testing substantially complete.”

The uncertainty did not disappear. It was converted into vocabulary.

Schedule Doublespeak

Schedules are frequent targets because dates are visible and easy to communicate. A single date appears more decisive than a range with assumptions and confidence levels.

The team may say that the program is “on track,” even though the original track has been quietly redefined. Tasks are removed, verification is compressed, resources are borrowed, and unresolved work is moved beyond the reporting window. The status remains green because the definition of green has changed.

This is how a dashboard can be factually populated and operationally misleading.

A useful schedule statement includes assumptions, dependencies, risk, and confidence. “The date remains possible if the interface decision is made by Friday and the supplier delivers conforming parts by the fifteenth” is less comforting, but it supports action. Precision gives leaders something to manage.

Prototype Doublespeak

A prototype can demonstrate progress, but the language surrounding it often claims too much.

“The prototype was successful” may mean that one carefully prepared unit operated long enough to complete a demonstration. It may have been assembled by an expert using selected parts, hand fitting, undocumented rework, extra inspection, and engineering support that will not exist in production.

The prototype may have been valuable. The doublespeak occurs when evidence that the concept can work once is presented as evidence that the product can be produced repeatedly at the required volume, cost, cycle time, and quality.

The more accurate statement is narrower: What hypothesis did the prototype test? Under which conditions? What failed? What required intervention? What uncertainty remains?

Honest language does not diminish the prototype. It preserves the value of what was actually learned.

Quality Doublespeak

Quality systems have their own vocabulary, and that vocabulary can clarify or conceal.

A “quality escape” sounds almost accidental and harmless. In practical terms, a defect passed through the organization’s controls and reached the next operation or the customer. “Operator variation” may direct attention toward an individual when the work instructions, fixture, measurement system, design tolerance, training, or production process made variation likely.

Even “root cause” can become doublespeak when the investigation stops at the first answer that can be corrected easily. Retraining the operator is convenient. Understanding why the process allowed the mistake may be more difficult.

DFMEA, PFMEA, control plans, verification plans, and process validation can also become part of the appearance. The documents exist. The boxes are populated. The dates are entered. Yet the information may not be connected to engineering decisions or shop-floor controls.

The organization appears compliant without becoming more capable.

Metrics and Dashboard Doublespeak

Numbers can become doublespeak with surprising ease. A number appears objective, but its meaning depends on the definition, source, time period, exclusions, and context.

“Ninety percent complete” means little until we know what is being counted. Tasks opened? Documents drafted? Engineering hours spent? Requirements verified? Failure modes controlled? Production risks retired?

Likewise, reporting the number of tests executed says little about test coverage or product confidence. One thousand passing tests may be less important than one unexecuted test tied to a critical failure mode.

Metrics become doublespeak when they measure what is easy to report while creating the impression that they measure what matters.

Innovation and AI Doublespeak

Innovation language is particularly vulnerable because the terms are broad, attractive, and difficult to challenge without appearing resistant to progress.

“Digital transformation,” “AI-enabled,” “Agile,” and “data-driven” may describe meaningful changes. They may also describe new tools placed on top of the same unclear responsibilities, disconnected data, unstable requirements, and delayed decisions.

Buying software does not create integration. Renaming meetings does not create agility. Applying artificial intelligence to an ambiguous process does not create clarity. It may generate the appearance of speed while increasing the volume of work that must later be checked.

The useful question is not whether the organization uses the fashionable term. The question is what capability changed, how the result is measured, and what evidence demonstrates improvement.

Why Intelligent People Use Doublespeak

Doublespeak is not limited to dishonest people. It can emerge from incentives, fear, habit, or the desire to keep work moving.  If our company is culturally uncomfortable with contentious language, we may resort to doublespeak to soften how we describe the situation.

People learn which statements are rewarded. If the person who identifies a risk is treated as an obstacle while the person who promises an unsupported date is praised as decisive, the language will change. If every executive dashboard must be green, the meaning of green will become flexible. If reporting a failure produces punishment while concealing it produces time, problems will be renamed before they are solved.

The language becomes a protective layer between the work and management.

It may also grow from politeness. Teams do not want to embarrass a colleague, challenge a customer, or damage a supplier relationship. Diplomacy is valuable, but diplomacy should not erase technical meaning. We can treat people respectfully while describing conditions accurately.

Separating the person from the problem allows constructive conflict. Hiding the problem inside pleasant language prevents that conflict and delays learning.

The Physical World Does Not Understand Doublespeak

A product cannot be persuaded by a presentation. A tolerance stack does not respond to optimism. Software timing does not improve because the status report is green. A connector does not become compatible because the procurement system accepted the part number.

Eventually, the product encounters testing, production variation, system integration, customer use, and time. Those conditions audit the language.

If the organization has been saying “to seem rather than to be,” the difference appears as rework, warranty claims, delayed launches, expedited freight, field failures, supplier disruption, lost capacity, and damaged credibility. The cost of poor quality includes all the technical and business effort required to recover from a reality the organization postponed acknowledging.

Doublespeak does not remove a problem. It shifts the problem to a later point, when options are fewer and more expensive.

Replacing Doublespeak with Operational Language

The remedy is not bluntness for its own sake. It is precision. Leaders need language that preserves the information needed to make a decision.

Name the Condition

State what has happened without hiding it behind abstraction. “Three of five samples failed the thermal-cycle requirement” is more useful than “We experienced a validation challenge.”

Identify the Evidence

Separate what is known, what is inferred, and what is assumed. A conclusion without its basis invites false confidence.

Describe the Consequence

Connect the condition to the customer, product, schedule, cost, or next operation. Information becomes actionable when people understand what it can affect.

Identify Ownership and Authority

Passive language often removes the actor. “A decision was made” conceals who made it and whether that person had the authority to accept the consequence.

Put Boundaries Around Temporary Actions

A deviation, waiver, containment, or temporary change should have a defined scope, owner, expiration, and exit condition. Otherwise, “temporary” becomes another form of doublespeak.

Ask What Would Prove the Statement Wrong

Every confident claim should be open to challenge. What evidence would cause us to revise the forecast, reopen the decision, or stop the launch? A claim that cannot be tested is often positioning rather than management information.

These practices replace product development doublespeak with clear language about evidence, uncertainty, decisions, and consequences.

To Be Rather Than to Report

The inversion of North Carolina’s motto is useful because it exposes a temptation. Organizations can spend so much energy appearing aligned, innovative, on schedule, compliant, and in control that the description of the work begins to replace the work.  The project can appear on time, on target, and on budget, either as self-preservation or as the consequence of misplaced optimism.

Reports matter. Language matters. Presentations matter. But their purpose is to make reality more visible, not more comfortable.

Esse Quam Videri remains the better standard. Be capable rather than merely reporting capability. Understand the risk rather than renaming it. Verify the product rather than declaring it complete. Resolve the problem rather than improving the wording around it.

In business and product development, trust depends on the distance between what we say and what the system can actually deliver. The smaller that distance, the stronger the organization. The larger it becomes, the more likely we are practicing product development doublespeak—seeming rather than being.

For more information, contact us:

The Value Transformation LLC store.

Follow us on social media at:
Amazon Author Central https://www.amazon.com/-/e/B002A56N5E
Follow us on LinkedIn: https://www.linkedin.com/in/jonmquigley/
https://www.linkedin.com/company/value-transformation-llc
Follow us on Google Scholar: https://scholar.google.com/citations?user=dAApL1kAAAAJ