A review deck ranks features by coefficient size and leadership starts acting on the "strongest driver". Weeks later the lever moves and nothing changes downstream. Typical tell: one feature measured in big units (rupees, metres, seconds) sits at the bottom of the ranking with a tiny coefficient like 0.02, while a small-unit feature tops the chart.
A linear or logistic model fitted on raw, unscaled features — delivery-time, churn, or credit tables where columns mix counts (1–15 items), distances (1–12 km), and money (100–900 rupees). The model itself predicts fine; the damage happens in the meeting where someone reads the coefficient column as an importance ranking. Common in first review decks and intern analyses. Linked module: 1.3 (Linear & logistic regression).
A raw coefficient answers "what does one UNIT of this feature do", and units are not
comparable across features. Item count moving by 1 is a big share of its swing; order
value moving by 1 rupee is nothing — so the rupee feature's coefficient looks tiny even
when the feature matters a lot. Confirm the misread in two steps. (1) Print each
feature's spread: X_train.std() — if the spreads differ by 10x or more, raw ranking is
meaningless. (2) Refit on standardised features (StandardScaler) and compare rankings:
if the order changes, the deck's story was an artefact of units. A second, quieter
misread often rides along: presenting the top coefficient as a cause ("order value
DRIVES lateness") when the model only measured association on historical data.
Refit (or re-report) with scaled features and rank on the scaled coefficients — each one now answers "what does one typical swing of this feature do", which is comparable. Keep the raw model for per-unit stories ("each extra km adds 2 minutes") because those are true and useful; label the two tables clearly as per-unit versus per-swing. Rewrite every "drives/causes" sentence in the deck as "is associated with", and note that only an experiment (or a causal analysis) can support the stronger claim. Then re-brief the stakeholders who saw the wrong ranking — silent corrections leave decisions rotting.
Standard habit: whenever coefficients will be compared or shown to anyone, fit a
scaled pipeline (make_pipeline(StandardScaler(), model)) alongside the raw one.
Put the feature spreads in the appendix of any coefficient deck. Keep one fixed line in
review templates: "coefficients are associations, measured per typical swing". A
reviewer who asks "raw or scaled?" before reading any coefficient table catches this
failure in five seconds.
Q: "Your linear model gives order value a coefficient of 0.02 and item count 0.94. A stakeholder concludes order value barely matters. Respond." Strong answer: name the units problem (per-rupee versus per-item), propose scaling to compare per typical swing, show awareness the ranking can flip, and separately flag that even the scaled ranking is association, not causation. Mentioning that you would keep the raw coefficient for operational per-unit statements signals real practice, not textbook recall.