When the Dashboard Says ‘Go’ and Your Gut Says ‘No’: The Petrov Check for Founders

Founder judgment vs. data, knowing when to override the dashboard, and the decisions that don’t fit in a spreadsheet.

The metric that condemned us was clicks-to-submit. It was high and climbing. Accenture — the prime contractor on a large Canadian federal government implementation — compiled the pilot feedback into a formal assessment and the verdict was clear: our expense management module was the problem. Too many clicks. Too long to complete. The recommendation: redesign two modules.

The data said redesign. It was entirely wrong.

We immediately wanted to talk with the client directly. Accenture said no.

That’s how large government contracts work. The prime manages the client relationship. Secondary vendors stay at arm’s length. You get the feedback filtered, summarized, and delivered with a conclusion. In this case, the conclusion was: your product is broken, fix it.

But something felt off. My team knew the product. We’d seen it deployed in other organizations. The workflow Accenture was describing — generating all the complaints — didn’t sound like our product. It sounded like something else using our product’s name.

We couldn’t go to the client, so we went a different route.

We had a senior consultant from the implementation who had moved to our R&D team. She still had a relationship with the department lead — the person who configured the system. We prepped her carefully. She knew the department head was on shaky ground politically; the pilot wasn’t going well and the pressure was escalating. This wasn’t a conversation where you say “you set it up wrong.”

She engaged him on commercial best practices — how other organizations configured the same tool and the workflow looked like when it was built for digital instead of rebuilt from paper.

He didn’t flip immediately, but it opened a crack.

What she brought back validated the instinct. The department responsible for configuring the system had recreated their paper-based workflow inside a digital tool. Every manual step, redundant approval, and legacy checkbox from the old process was reproduced in software, adding clicks. The click count measured a problem with the implementation, not the product. They’d paved the cow path.

More conversations followed. Prototyping the new workflow could look like. Walking stakeholders through the difference between “the software is broken” and “we configured the software to behave like a paper form.” The department head came around — not because we told him he was wrong, but because he could see the better version side by side with what he’d built. Eventually they reconfigured and redeployed. The new workflow cut the steps by 38% — without changing any product code. The same employees giving brutal pilot feedback agreed: this was better and easier than the manual process.

The Man Who Ignored the Highest-Confidence Alert in History

I recall that experience every time I hear Stanislav Petrov’s story.

On September 26, 1983, a Soviet lieutenant colonel sat alone in a bunker south of Moscow, monitoring the Oko satellite early-warning system. It lit up: five U.S. intercontinental ballistic missiles, inbound. Thirty layers of verification. Confidence level: highest. He was supposed to report the launch. His superiors would authorize a retaliatory strike. Hundreds of millions would die within the hour.

Petrov had minutes. He reported a system malfunction. A false alarm.

He was never completely certain he was right.

His reasoning was almost entirely intuitive. Five missiles didn’t match American first-strike doctrine — a real attack would be hundreds of warheads, not five. The satellite system was barely a year old. Ground-based radar showed nothing. None of this was proof. But together, it was enough doubt.

Petrov had a civilian engineering background. His colleagues were career military, trained to follow protocol. His instinct — to question systems and probe for failure modes — kept him from passing the alert up the chain. Sunlight reflecting off high-altitude clouds had fooled the sensors. The system worked as designed but was completely wrong.

When You Can’t Get to the Ground Truth

Petrov had minutes. We had weeks. The common thread isn’t urgency — it’s that both systems were designed to prevent you from checking their accuracy.

Petrov couldn’t call Washington. He had to decide based on what he could observe from inside the bunker. We couldn’t call the client. We had to find a side channel — a senior consultant, a lunch, a conversation that shouldn’t have happened — to see what the filtered data wasn’t showing us.

This is the part that rarely makes it into the “trust your gut” advice. It’s not just about having the courage to disagree with the numbers. It’s about doing the unglamorous work to find the evidence your current system isn’t surfacing. Gut instinct told us something was off. But the consultant’s relationship, careful prep, and patience to let a defensive department head come around on his own terms turned a hunch into something actionable.

These are Petrov moments. The system says one thing. Your pattern recognition says another. And you have to choose — knowing you might be wrong.

The Most Dangerous Metrics Are the Wrong Ones

This isn’t an argument against data, but against data as religion. There’s a difference between being data-informed and being data-imprisoned.

Earlier in my career, I would have taken Accenture’s write-up at face value and started redesigning. I trusted the data because it was easier to defend in a meeting than a hunch. I got burned — shipping redesigns that solved the wrong problem — before I learned to ask a different question: not “what does the data say?” but “what is the data actually measuring?”

Petrov’s system had thirty verification layers. Highest confidence. Precisely, catastrophically wrong.

Build a Petrov Check Into Your Process

Pick one metric your team treats as gospel. The number driving decisions, reported to investors, that everyone assumes is pointing in the right direction.

What would have to be true for this metric to be lying to us?

Not slightly off. Actively misleading. What scenario would make this number improve while the business is getting worse?

Build a “Petrov Check” into your monthly review. A standing agenda item — ten minutes, max — where someone is assigned to argue against the dashboard. Rotate the role monthly across product, support, and sales to avoid one person’s soapbox. Their job isn’t to be right. Their job is to show up with one hypothesis for how a key metric could be misleading and one piece of evidence from outside the dashboard — a user conversation, a session replay, or a raw data slice that challenges the aggregation. If the dissenter presents a plausible failure mode plus one corroborating observation, run a cheap test before making an irreversible decision. A week of investigation. A handful of user calls. Whatever it takes to check if the system is telling you the truth.

The broader decision rule: override the dashboard if you can articulate a specific failure mode for the metric, have at least one corroborating observation from ground truth, and your next move is a reversible, bounded test — not an irreversible bet. That’s the line between “trust your gut” and recklessness. Petrov didn’t just feel uneasy. He could name why the data didn’t fit: wrong attack profile, new system, no ground radar confirmation. His next move — reporting a malfunction — bought time. It didn’t launch missiles in the other direction.

After the Canadian project, this became instinct on my team. Whenever a client showed us bad metrics and a confident diagnosis, the first move was: show us the workflow. Let us see what the data is measuring before we accept its meaning.

The Job’s Loneliest Part

Petrov was never rewarded. The Soviet military reprimanded him for not following protocol. He lived in a small apartment outside Moscow for decades before a journalist found him.

The hardest decisions feel like that. You won’t get credit for the avoided disaster — the redesign you refused, the pivot you didn’t make. The counterfactual is invisible.

That’s the job. The dashboard is a tool, not a boss. Your judgment — the pattern recognition from years of watching actual outcomes versus the predicted numbers — is the unique value.

Trust judgment to question the system. Respect reality to verify.

Petrov was right. But he didn’t know that when he picked up the phone. He just knew something didn’t add up.

That’s usually all you get.
_____________

If you’re a software founder looking to turn your idea into a successful startup, Wildfire Labs can help you get there in just 6 months. Check out our program at https://wildfirelabs.io to learn more about our proven process, expert mentors, and the development resources we provide to help you build and scale your company. If you have any questions or need assistance with your startup, don’t hesitate to reach out to us at info@wildfirelabs.io.