I have asked engineers why we need another database change. I have asked ML teams how training data was prepared. Neither question makes me the engineer in the room.

The purpose is not to prove that I can follow the technical conversation. It is to understand when a technical decision starts changing the product.

The useful boundary is not “technical versus non technical.” It is implementation choice versus product consequence.

Do not challenge implementation for sport

Whether an engineer prefers one library, internal pattern or deployment mechanism is usually not where product leadership adds value. Interfering there can slow the team and create exactly the kind of mistrust PMs complain about later.

But if a choice creates permanent customer configuration, makes a market impossible to serve, changes data behaviour, adds a migration obligation, or determines whether a promised workflow can exist, it has crossed the boundary.

Now the product leader needs to understand the consequences.

The database question

If someone tells me a database change is necessary, my first instinct is not to say no. It is to ask what became impossible with the existing model.

That question often reveals the product assumption hiding underneath the architecture. Maybe multi tenancy requires a different identity model. Maybe a new workflow breaks an old ownership assumption. Maybe we are introducing complexity because a single customer request has quietly become a platform decision.

Once that connection is visible, we can make the product trade off consciously.

The ML question is similar

“How was the training data prepared?” sounds technical. But the answer can define who the product works for, which cases fail silently, and what kind of claim the business is justified in making.

If the training population is narrow, the product consequence may be narrow performance. If labels were produced under conditions customers will not reproduce, the product consequence may be fragile real world behaviour.

Those are not only modelling concerns. They determine the promise.

The boundary I care about

I challenge the reasoning when a technical choice changes customer capability, future flexibility, commercial promise or irreversible cost.

Four questions before I step in

01

Does this choice materially constrain a future product decision?

02

What alternatives were considered, and what made them unsuitable?

03

What product assumption makes this technical choice necessary?

04

Am I challenging the consequence, or am I trying to do someone else’s job?

Technical curiosity is useful. Technical theatre is not.