“This Feels Wrong” Is the Beginning, Not the Argument

In the fast pace of a startup, many decisions need to be made in a short time, ideally through very short discussions.

When there is agreement, that is the happy path: simple and short.

But when there is hesitation, doubt, or disagreement, the situation becomes more interesting.

Being able to quickly explain why you disagree, the reasoning behind it, and why it matters to the decision is harder than it looks.

I’ve started thinking about it as a sequence:

Each step does something different.

1. Intuition: “This feels wrong” is useful — to me

The first step happens quickly and sometimes naturally. It’s something like a gut feeling of: something feels wrong.

An architecture feels fragile. A metric looks too good. An assumption seems stronger than the evidence behind it. A decision feels like it could create a problem later.

Experience can make that intuition useful. Sometimes “this feels wrong” is compressed pattern recognition: I’ve seen enough similar systems, experiments, or failures that something doesn’t fit.

I did research for years, and there the next step was relatively natural: look at the data, perform another experiment, check the math, or discuss it with colleagues.

We might disagree about why something “felt wrong,” but we shared a lot of context. We had similar technical language, methods, data, and ways of testing whether something was true.

Working in a startup has made me realize how much I took that shared context for granted.

The decisions are also different. A problem is rarely purely engineering, research, or commercial. Several dimensions show up at the same time:

• How does this affect the client?
• Are the costs sustainable?
• Is the accuracy sufficient for the use case?
• Is another experiment worth the time?
• What are we giving up by doing this instead of something else?

The people answering those questions may also come from very different backgrounds: engineering, business, customers, security, compliance.

So something that looks obviously risky to me may not look risky at all to someone else.

And that is reasonable.

They don’t have the chain of technical experience and assumptions that produced my reaction. In the same way, someone with years of customer or commercial experience may immediately notice something in a negotiation that I completely miss.

This has made me much more conscious of the distance between:

This feels wrong.

and:

Here is the problem.

They are not the same thing.

Intuition is a private signal. It tells me that there may be something worth examining, but it doesn’t yet tell anyone else what the problem is.

It is enough reason for me to investigate. It is not enough reason for someone else to agree.

2. Reasoning: first, I have to understand my own concern

The first step isn’t communication.

It’s reasoning.

If I say:

I don’t like this architecture.

I haven’t actually explained anything, including to myself.

Why don’t I like it?

Maybe after thinking about it, I get to:

This design couples two things that are likely to change independently. If one changes later, we may have to migrate the other with it.

Only after I understand that chain of consequences can I really externalize the concern.

And sometimes this process reveals that my original intuition was wrong.

That’s important.

The goal isn’t to find a sophisticated justification for my initial reaction. It’s to figure out whether there was actually something behind it.

So the first transformation is:

I later found a similar idea in practices such as Architecture Decision Records: writing the reasoning down doesn’t just preserve it; the act of drafting can clarify the thinking and surface different points of view.

Externalizing the reasoning is part of testing it.

3. Synthesis: then I have to find the actual problem

Reasoning can easily produce ten valid concerns.

That doesn’t mean I should communicate all ten.

With enough shared context, I could enumerate the problems and probably arrive at the core issue through discussion. But as shared context decreases, that becomes increasingly inefficient. I need to do more of that synthesis myself.

I can’t assume the other person will reconstruct the core issue from the same details I would.

For example, maybe I have thought through architecture, APIs, customer configuration, migration, backward compatibility, and deployment.

But the thing that actually matters to the decision is:

This turns a future change into something we may need to handle customer by customer, instead of once centrally.

This is the part I increasingly think of as synthesis.

That is a much smaller statement.

It isn’t less rigorous. It is the result of doing the work required to figure out which part of the reasoning actually matters, and to whom.

I’ve had to learn that explaining everything I know about a problem is not the same as explaining the problem.

4. Translation: then I have to find the right language

This is the part that is often described as “technical people learning to speak business.”

I think that’s partially true, but incomplete.

Translation isn’t just removing technical words.

The harder problem is finding a representation of the issue that gives us enough shared understanding to reason about the decision together.

The same underlying technical concern could be expressed differently depending on who needs to make the decision.

To an engineer, an architecture diagram may be the clearest representation.

To someone thinking about the business, the important point may be:

We can save time now, but if we need to change this later, we may have to coordinate that change separately with every customer.

To a customer, the relevant consequence may be:

This choice could make a future change require coordination with your team.

The underlying issue hasn’t changed.

The representation has.

That’s different from simply removing technical language.

I think of it more as:

Sometimes that requires an example. Sometimes a diagram. Sometimes numbers. Sometimes simply describing the consequence is enough.

The goal is not to make the problem sound simple. Simplicity should be a consequence of doing the reasoning, synthesis, and translation well.

The goal is to preserve what matters while requiring less shared context to understand it.

That is what makes the communication efficient.

Shared understanding is the goal

After thinking about this, I found that part of what I was describing is already well established in product thinking: shared understanding — giving a team enough common context to reason and make decisions together.

What interested me was the work that sometimes has to happen before shared understanding is possible.

Especially when the starting point isn’t a well-formed argument. It’s just:

Something about this feels wrong.

Getting from there to shared understanding may require reasoning through the intuition, finding the core issue, and then finding a representation that works across different backgrounds.

So shared understanding isn’t necessarily about communicating more. Sometimes quite a lot of intellectual work has to happen before there is something useful to communicate.

Every step can fail

There is a different failure mode at every step.

• I can fail at reasoning and never get beyond: “Trust me, this feels risky.”
• I can fail at synthesis and present twelve technically correct concerns without making clear which one actually matters.
• I can fail at translation and explain the right problem in language that requires my background to understand.
• Or I can translate too aggressively and produce a simple, compelling explanation that no longer represents the actual technical problem.

That last one matters too.

Good communication isn’t making everything simple.

It’s deciding what complexity can be removed without changing the decision.

This has changed how I think about expertise

So maybe expertise isn’t only about being able to notice things other people don’t — although that certainly matters.

In a heterogeneous team, private insight has limited value.

The harder responsibility is taking something that exists initially as intuition and making it inspectable by others, especially those who don’t share my background.

The goal is not that they automatically agree with me. It is that they can disagree with the actual reasoning instead of having to accept or reject my intuition.

And sometimes, once I’ve made the reasoning explicit, someone with a different background points out an assumption I got wrong.

That’s not a failure of the process.

That’s the reason for doing it.

Research taught me to make claims inspectable through evidence.

Working across engineering, business, and customers is teaching me that getting to an inspectable claim can itself require several steps: understanding why I believe it, finding the part that actually matters, and finding a language in which we can both reason about it.

“This feels wrong” can be valuable.

But it is the beginning of the work, not the argument.

Related thinking

• ProductPlan, How Do I Build Shared Understanding? — on shared context and creating common understanding across product teams.
• Sherif Mansour, Product Managers Make All the Decisions… Right? — on shared understanding as a way to improve decision-making across teams.
• Martin Fowler, Architecture Decision Record — particularly the idea that writing decisions does not merely preserve reasoning; it can help clarify it.