I was recently reflecting on past decisions—both minor and monumental. A decision can be as mundane as selecting an electronic component or as significant as launching a full-scale business and product development initiative. Either way, hidden assumptions eventually reveal themselves and bite you or your team in the back.

Sometimes the big decisions are easier to navigate, even when new evidence surfaces later. But often, a minor decision carries an oversized impact—like a component making it all the way through design, compliance, and manufacturing, only to go End-of-Life (EOL) six months later.

The things you didn’t know were unknowns weren’t failures of intelligence—we are all smart people in these rooms. They were failures of information completeness. The difference matters.

I started reflecting on this after reading a recent study: https://pmc.ncbi.nlm.nih.gov/articles/PMC11463766/

The study explores what the authors call ‘The Illusion of Information Adequacy.’ It’s closely linked to Andy Grove’s advice that ‘only the paranoid survive,’ or the corporate tradition of appointing a devil’s advocate. But ‘illusion’ is an apt term—it captures a deeply human flaw, much like Errare humanum est. Being human doesn’t make it any less costly when hidden assumptions bite a project.

That sympathetic view does not change the fact that this illusion can be time-consuming, costly, and outright harmful.

What the Research Shows

Researchers gave participants a scenario: deciding whether two schools should merge. One group received the full material, while a comparison group received roughly half the arguments.

Both groups rated their information as equally adequate, and both felt equally capable of making the call. In fact, the group with half the information was, on average, slightly more confident.

The uncomfortable part of this finding is that people don’t experience the gap. The person with half the picture doesn’t feel like they have half the picture. They feel like they have enough. The decision proceeds.

If the result is good, nobody scrutinizes the original reasoning. If it fails, corrective action becomes an expensive nuisance.

Making the Blank Spaces Visible

Organizations excel at this blind spot. A strategy gets executed, something goes wrong, a retrospective is logged into a document canvas—and there it stays. Almost nobody goes back to ask: Which assumptions did we miss when we made this call, and which of our explicit beliefs turned out to be wrong?

The study offers one encouraging finding: when participants were later shown the full set of arguments, most revised their view toward the middle. New information does move people—when it arrives in a legible form.

Information arriving as noise—a buried Slack message, an uncaptured meeting comment—doesn’t close the gap; it adds to it.

The practical question isn’t how to eliminate uncertainty, which is impossible. It’s how to make the assumptions behind a decision visible before the outcome rewrites everyone’s memory of what they thought at the time.

If this pattern sounds familiar in your own product or management decisions, we are building tools specifically designed to make these implicit assumptions visible early before they become costly surprises. If this sounds like a challenge your team faces, explore how we’re solving it and register for the Ainolabs beta program.

Fact, Faith, and the Space Between

Companies, and people, like to think their beliefs update the moment new evidence arrives with a clean patch, applied and closed. In practice, belief revision is closer to correcting a course at sea than installing a software update. You don’t jump straight from “the chart is wrong” to “recalculate everything.” You nudge the heading, watch what happens, and only reluctantly admit the original bearing was off.

Errare humanum est, to err is human. The phrase leaves out the more interesting part: to err, to see the evidence directly, and still find a reading of events where the original belief was basically sound. That reframing is not a bug in human cognition. It’s the default behavior of any system, human or organizational, that has a stake in being right.

Belief sits on a spectrum. At one end is empirical fact — unyielding, indifferent to preference. A depth sounder reports a number regardless of how committed you are to today’s course. At the other end is something closer to faith — decisions made and ventures started with evidence that is, by any honest accounting, insufficient. Most operational life, and most enterprise decision-making, happens in the space between these two poles, and I’d argue that’s not a design flaw. It’s where robust action actually gets made.

A Fact is difficult to argue with. It is not necessarily a comfortable or easily palatable, but one can’t dispute it.

Empirical fact is necessary and generally unpleasant to accept and process. A quarterly number does not care about the narrative built around it. This is a useful fixed point everything else gets checked against but on its own it offers no guidance about what to do next. Fact tells you where you are. It doesn’t tell you where to steer.

Most day-to-day decisions run on heuristics, not derivations — pragmatic shortcuts that let an organization function without re-deriving first principles every morning. “Fast delivery wins deals” is a heuristic belief. So is “the second cheapest wine is fine.” These aren’t beliefs held with high confidence so much as operational defaults nobody has bothered to interrogate, because interrogating every default would be its own form of paralysis.

What happens when a fact and a belief collide?

This is the interesting failure mode. When solid evidence contradicts an operating assumption, the instinct is rarely to revise the assumption outright. More often there’s a quiet renegotiation of the terms — the conditions were unusual, the data’s noisy, the miss was really a deliberate trade-off. This is worth naming plainly, because it’s exactly the mechanism a belief-management discipline exists to interrupt: not to punish the original assumption, but to make its correction cheap enough that renegotiating reality stops being the easier option. Beliefs can turn into identity markers, faith.. That is one more notch on the continuum between “facts” and “faith”. In that case a belief stops being a claim about the world and starts being a stake in who someone is.
Correcting a forecast is trivial.
Correcting a belief that’s become entangled with a person’s judgment, role, or track record is not. That is  why belief systems that assign ownership without assigning blame matter. The goal isn’t to strip beliefs of their owners. It’s to make revising a belief cost the owner nothing more than the revision itself.
Correcting “faith” is just about meaningless as it is possibly harmful to a human and at the very least next to impossible. In religious terms, there are converts, but that is a rare breed. Faith is practically immutable, and when facts contradict faith – vae factis.

Faith, and the decision to leave the dock anyway

At the far edge, the evidence runs out and the decision gets made regardless. No venture, campaign, or product launch is backed by proof sufficient to remove all doubt — if it were, someone would have already done it, and there’d be no advantage left in doing it now. This isn’t irrational so much as structurally unavoidable: robust action, by definition, has to commit before the picture is complete.

None of this is an argument for eliminating the messier end of the spectrum in favor of the clean one. A company that only acted on certainty would rarely act at all.

The more useful question, for a person or an organization, isn’t where on this spectrum do you sit.
Instead, it is to know where you stand at right now, or are you fooling yourself that you practice pure logic and fact-based management.

Once you know that it is easier to consider possible changes and improvement in the true spririt of continous learning, retrospectives, after-action reviews and post mortems. You may end up managing your beliefs instead of being driven by assumptions.

Managers Are Gamblers and Accountants Are Historians

Robust action under uncertainty is recommendable. Yet, how are facts, beliefs, opinions, expectations and so forth similar and different and how to separate the essential from the unlikely to reach that set of Robust action alternatives and ultimately the plan and action?

When someone in a product or strategy meeting says, “I believe this feature will increase customer demand by 20%,” what are they actually doing?

Depending on who you ask, they are either issuing a data-driven prediction, placing a speculative bet, making an educated guess, or simply manifesting their hopes into the universe.

There is a wide collection of future-facing words. Inside an enterprise, these words mean wildly different things depending on which floor you sit on.

Product planning often includes suggestions like adding a new dashboard widget or other pet feature will increase customer demand by 20%.

The statement sounds precise, authoritative, and completely grounded in strategic foresight. In reality, it is likely to be a personal hunch into the quantitative dialect of executive decision-making.

Tech companies run on these future-facing claims and suggestions, yet rarely acknowledge what they actually are. Depending on who looks at the proposal, the exact same statement qualifies as a user-centric vision, a risky engineering distraction, or a binding revenue commitment. Words like belief, expectation, forecast, and bet get tossed around inter-changeably, blurring the line between empirical certainty and optimistic guesswork.

Before an organization can make sound decisions, it should clarify these words and concepts. Managing product development isn’t about scrubbing away unproven ideas to chase absolute certainty, but about recognizing that every roadmap is inherently built on assumptions.

Understanding how different teams make and process those assumptions is where robust action planning and effective leadership can begin.

The Enterprise Lexicon of Unproven Truths

Every corporate role translates the language of the future through its own functional lens. When a product manager speaks of a belief, they describe a deeply felt product vision anchored in user empathy and qualitative customer feedback. The engineering lead hears that same word as an unsourced hypothesis destined to force scope creep late on a Friday afternoon, while the sales director immediately converts it into next quarter’s baseline quota.

Expectations carry a similar dual meaning across the org chart. Company leadership issues an expectation as a polite euphemism for a non-negotiable directive, whereas middle management absorbs it as a rapidly ticking deadline. When finance builds a forecast, they assemble a complex statistical model across dozens of spreadsheet tabs, while the operational teams treat that exact forecast as corporate astrology wrapped in business casual.

Strategic bets reveal a fundamental divide in risk perception across executive tiers. A chief executive views a bet as a bold, visionary move that demonstrates market leadership to investors and the board. Conversely, a line manager sees that same bet as a high-stakes coin toss where heads guarantees business as usual and tails triggers an organizational restructuring.

Finally, the weight of an opinion depends entirely on who voices it in the room. When the highest-paid person in the conference room states an opinion, the surrounding team often accepts it as settled science. When anyone else offers an opinion without supporting data, colleagues instantly flag it as a risky political stance.

Managing Beliefs Instead of Pretending They Are Facts

Successful product leadership requires managing uncertainty rather than disguising it behind corporate jargon. When teams frame a future feature as a guaranteed fact, they construct rigid development roadmaps around pure illusion. Product managers achieve far better outcomes when they treat every forward-looking statement as an explicit hypothesis.

First, teams must explicitly calculate the financial and operational cost of being wrong before committing resources to a feature. Second, product organizations must design the smallest possible experiment that can validate or invalidate the core assumption in market conditions. Finally, leadership needs to define the exact metrics that will force the team to abandon a failing bet before sunk costs accumulate.

Effective management never eliminates beliefs in favor of rigid historical data. Strong leaders practice deliberate belief management by converting vague optimism into testable bets, using current discovery cycles to manufacture future facts.

Why Fact-Based Management Won’t Save Your Product

Modern product organizations elevate fact-based management to absolute gospel. Executives urge teams to move fast, rely exclusively on telemetry, and purge human intuition from decision-making. While fact-based decision-making sounds disciplined and risk-averse, it masks a fundamental reality: facts exist exclusively in the past.

A fact represents an event that has already occurred and can be and was measured.  Analytics platforms log facts, engineers measure them, and finance teams audit them.

Facts deliver total reliability and zero variance, yet they remain entirely incapable of dictating what a team should build tomorrow. Operating strictly on fact-based management does not produce foresight; it delivers perfect 20/20 hindsight wrapped in a dashboard.

Facts serve as historical bookkeeping entries for accountants, historians, and post-mortem reviews. Conversely, beliefs, expectations, and strategic bets form the core material of future product development. Beliefs can include topics that are hard or impossible to measure – yet.

Product managers operate squarely in that unwritten future, making the deliberate management of unproven beliefs their primary responsibility. Facts are necessary, but they do point to the past – like horseless carriage versus automobile.

Ultimately, navigating the unknown isn’t about eliminating speculation—it’s about managing it with rigor. While historical data tells us where we’ve been, growth requires taking calculated leaps into what comes next. Ainolabs provides tools to help people and organizations structure, track, and evaluate decisions under uncertainty.

Ground future bets in systematic evidence and continuously refine assumptions based on past learning, and you can transform fluffy guesses into a continuous engine for intelligent strategic planning, robust action and execution.

This post was written and drawn with the help of generative AI tools.

Companies – probably anyone – would like to make informed, robust decisions in the face of uncertainty that result in reasonable outcomes in all or most plausible future scenarios. In other words strategic, flexible measures that accomplish immediate goals while deliberately preserving long-term options.

Jagged intelligence refers to the uneven performance of AI models. They excel in some tasks, but may hinder human effectiveness in others. I saw the phrase in an New York Times article, and read the background study mentioned there.

Human consciousness has been tied with thinking ever since and possibly before the utterance Cogito, ergo sum. With AI systems, some psychologists have paid closer attention to the actual thought process and suggest that the process is at least as important as the outcome of thought. Doubt, mistakes, learning from experience are essential and so the adage should be I doubt, therefore I think, therefore I am.

Jagged intelligence and doubt and thought processes that can be explained are necessary for robust decisions. Decisions that are made while taking into account the limitations of the thought processes will end up more robust when future events fold in unexpected ways.

Ainolabs Belief Management, or Cognitive Fitness tools are built to help collect, capture, articulate and handle doubt and to illuminate peaks and valleys of jagged intelligence. Perhaps they can reveal the occasional black swan waiting in the darkness.

The previous posts have been about architecture, system design, complexity, computational cost, and other technical and intrinsic matters about building autonomous systems.

This installment focuses on the people, and what beliefs, assumptions, expectations could mean to enterprise employees. Their work, incentives, business success, and company performance under uncertainty is discussed.

The result is an approximate guideline and system design for building Ainolabs Cognitive Fitness tool. The internals is expressed “Belief management”; that probably will be replaced with something less theoretical, e.g “Cognitive Fitness” or “Decision Intelligence” . These should connect to user outcomes instead of epistemology.

Please let me know if this piece or any other is complete non-sense. If it is not – enjoy!

Beliefs, assumptions, scenarios expectations, and other similar expressions refer to possible futures events with some scope, time, likelihood, and potential outcomes and results.

A company’s World Model should be populated with such information. We call those beliefs, and propose that they are entered in a Belief Manager. This potential system component is outlined in the attached next entry of the Ainolabs architectural components.

The previous post about autonomous systems discussed World Models in a narrow domain. My goal is to outline, understand and eventually build automated workflows in enterprise environments. The following discussion about Enterprise World Models, Belief Management and Robust Actions v.s. perfect foresight is the next conceptual step

I have spent time in figuring out how the general CMLS architecture would apply to workflows in an enterprise. To get to an understanding I ended doing intellectual – or at least mental – circles and spirals, and needed to start from basics. So here are a few pages of a students journey through enterprise and a bit of technical architecture and design views about how to design an autonomously driving vehicle or how to automate an enterprise workflow.

The text is in an attachment. I don’t like the constraints and defaults of WordPress for slightly more serious work.