Coachability, Feedback, and Humility Questions

Direct answer

Feedback that challenges a core assumption stings more than a detail-level correction because it threatens the whole plan you've invested in, not one line of it. The discipline is separating "how much work I've put in" from "whether the assumption is actually still true," and evaluating the challenge on evidence rather than on how costly it would be to admit you're wrong.

Structured elaboration

1. Reacting personally in the moment. Name it, at least to yourself, that a core-assumption challenge feels bigger than a detail challenge because more is genuinely at stake: sunk time, a plan already communicated to others. That recognition helps you avoid conflating "this is uncomfortable" with "this is wrong."
2. Evaluating whether it's right. Go back to why you made the original assumption, what evidence or context it was based on, and ask whether the challenger has new information or is reading the same information differently. This is different from a detail-level fix, since you may need to re-derive from the assumption forward rather than patch one component.
3. What changes. Ranges from a full pivot, if the assumption really doesn't hold, to a scoped adjustment, if part of it holds and part doesn't, to a respectful, evidence-based defense of the original assumption, if it genuinely still holds. The size of the challenge doesn't automatically determine the size of the correct response.

Worked example

I proposed a caching layer built on the assumption that read traffic was overwhelmingly for recent data, that most requests hit the last 24 hours. A colleague challenged that core assumption directly, arguing a meaningful chunk of traffic was from a batch reporting job pulling much older records, which would make my cache design ineffective for a large share of real traffic. My first internal reaction was defensive, since the whole design rested on that assumption. I went back to the actual traffic logs rather than my memory of them, and the challenge held: a substantial share of read volume was from that older-data batch job, which I'd missed because I'd looked at request count by hour and hadn't separated it by data age. That changed the design meaningfully, not just a tuning parameter: I split the cache into a hot-recent tier and a separate warm tier sized for the batch job's access pattern, instead of one undifferentiated cache.

Trade-offs and pitfalls

Treating a core-assumption challenge as automatically requiring a full scrap-and-restart is as much a mistake as reflexively defending the original assumption; sometimes checking the evidence confirms the assumption was right and the challenge was based on a misunderstanding, and defending it calmly with the evidence is the correct, non-defensive response. The amount of prior investment in the original plan is not evidence about whether the assumption is true, and letting sunk cost drive the evaluation is the single most common failure mode here. Re-deriving from the challenged assumption forward, rather than only patching downstream symptoms, is what separates a genuine reassessment from a surface fix that leaves the same flawed foundation underneath.

Direct answer

I reach for a small set of question types depending on what's actually missing from the feedback: what specifically prompted it, what a good outcome looks like, and whether there's a concrete example I should be checking against. Which one I lead with depends on whether the feedback is missing a trigger, a target, or a test case.

Structured elaboration

"What specifically led to this?" I use this when the feedback names a symptom without a cause, like "this feels slow" or "the messaging is off." It surfaces the underlying observation the person is reacting to, which is usually more actionable than the summary they gave you.

"What would a good version of this look like to you?" I use this when the direction is vague but the person clearly has something in mind, like "make this more strategic" or "this needs to feel more polished." Rather than guessing at their mental model, I ask them to describe the target directly, since two people can read the same vague word very differently.

"Is there a specific case or example I should make sure this handles?" I use this when the feedback sounds like it's reacting to a particular instance rather than a general pattern, like "this broke for me" or "a user complained about this." A concrete example is the fastest way to convert a vague complaint into something you can actually verify you've fixed.

A fourth, quieter tool: paraphrasing what you think they meant and asking them to confirm or correct it, useful any time you're not fully sure which of the above three questions even applies yet.

Worked example

A stakeholder says a report "doesn't feel complete." I could ask any of the three: "what specifically feels missing, is it a metric, more context, or something else?" (surfacing the trigger), "what would a complete version include, in your view?" (surfacing the target), or "is there a specific decision you were trying to make with this that the report didn't support?" (surfacing a concrete case). In this instance I'd probably start with the third, since "doesn't feel complete" often really means "didn't help me decide something," and that question gets at the actual gap fastest.

Trade-offs and pitfalls

Asking every question at once, rather than picking the one that fits the specific gap in the feedback, can overwhelm the person and make simple feedback feel like an interrogation. Relying on the same single question every time, regardless of what's actually missing, means you'll sometimes ask for a concrete example when what was actually missing was a definition of "good," which doesn't move the conversation forward. And treating the clarifying question as the end of the interaction, rather than following through on what the answer reveals, wastes the value of having asked at all.

Direct answer

The head of sales told me directly in a quarterly business review that our roadmap "looked like a list of things engineering found interesting," not a plan tied to why customers actually renewed or churned. That comment forced me to question an assumption I had been building the whole roadmap on: that closing feature gaps with competitors was what kept customers. Digging into churn interviews proved the assumption wrong, which led me to shift the strategy toward onboarding investment instead of feature parity, get every function aligned behind that shift, and track whether it actually moved retention over the following quarters rather than just declaring victory after one good month.

Structured elaboration

Let a hard comment reopen an assumption instead of defending the roadmap. My first instinct was to explain why the roadmap made sense, since I had reasons for every item on it. The more useful move was to separate the tone of the comment from its content: even delivered bluntly, "this doesn't map to why customers stay" is a testable claim about the strategy's foundation, not just an opinion about my competence.

Go find out whether the assumption is actually true. I did not take the comment at face value any more than I had taken my original assumption at face value. I went back to churn interview notes, support ticket themes, and usage data to check what was actually correlated with renewal versus cancellation, rather than assuming either "the roadmap is fine" or "the head of sales is right" without evidence.

Turn the corrected assumption into a specific strategic change. Once the data showed onboarding friction, not missing features, was the stronger driver of early churn, I did not just add an onboarding project to an already full roadmap. I reprioritized: several feature-parity items moved down, and onboarding investment became the top strategic bet for the next two quarters, with the reasoning made explicit so it read as a strategy shift, not a schedule tweak.

Get real alignment across teams, not just a roadmap update. A strategy shift only works if engineering, design, and customer success are actually building toward it, not privately still working the old plan. I walked each team through the churn data directly, not just the conclusion, updated the team's quarterly objectives to reflect the new priority, and worked with customer success specifically since they owned the onboarding experience most closely and needed to be a real partner in defining the fix, not just informed of it afterward.

Track long-term impact, not a single good data point. Retention shifts show up slowly, so I set up a standing view of onboarding-stage churn and net revenue retention (NRR, the percentage of recurring revenue kept and expanded from existing customers over a period, excluding new customers) that I reviewed over multiple quarters rather than checking once right after launch and calling the change validated.

Worked example

The comment landed in a quarterly business review: our sales lead said the roadmap read like an engineering wish list, not a retention strategy, and pointed out that we kept losing renewal conversations on the same theme regardless of which features had shipped that quarter. I had been assuming feature parity with a specific competitor was the main lever on retention, since that was the most common ask surfaced in sales calls. Reviewing churn interviews and support tickets directly, instead of secondhand sales summaries, showed a different pattern: customers who churned early rarely cited a missing feature, they cited never getting fully set up and confident using the core product in their first month.

I reprioritized the roadmap, moving several planned feature-parity items down and making an onboarding overhaul the top strategic priority for the next two quarters, and presented the underlying churn data, not just the new plan, to engineering, design, and customer success so the shift made sense to everyone rather than looking like a reaction to one meeting. Customer success became a direct partner in defining what a better onboarding experience needed to include, since they saw the friction firsthand. I updated the team's quarterly objectives to center onboarding-stage retention as the primary metric, and kept a standing view of that metric across the following quarters rather than checking once. Over that period, onboarding-stage churn trended down, from roughly 18% of new customers churning in their first 90 days to about 11%, and net revenue retention improved alongside it, and sales conversations about renewal started referencing onboarding experience less often as an objection, which was the signal that the strategic shift, not just the feature list, had actually changed the underlying customer experience.

Trade-offs and pitfalls

The clearest pitfall is reacting to a strong opinion by pivoting the strategy without checking whether it is actually true; the sales lead's comment was the trigger to investigate, not the evidence itself, and treating it as evidence would have been just as much a mistake as ignoring it. A second pitfall is announcing a strategy change without giving teams the underlying reasoning, since a roadmap reshuffle that arrives without context reads as reactive and erodes trust in the planning process itself. I also try to avoid declaring a strategic bet successful too early; a single strong month can be noise, and long-term product strategy changes need to be evaluated over a longer horizon than the immediate reaction to the feedback that prompted them.

Direct answer

I treat "the design caused this" as a hypothesis to test, not a fact to accept or reject on the spot. I respond to stakeholders by acknowledging the drop and committing to a fast, structured investigation, then look at both design and non-design causes with data before deciding whether to roll back or iterate, and I close the loop with a concrete timeline.

Structured elaboration

Step 1: acknowledge and stabilize. I confirm the drop is real, not a tracking artifact, and tell stakeholders "I see it too, here is how I am going to investigate, expect an update by a specific date," rather than debating blame before there is any data.

Step 2: investigate design causes. I look at funnel-step-by-step drop-off (a conversion funnel tracks what fraction of users complete each step toward a goal; comparing before-and-after the redesign at each step shows exactly where users are newly dropping off) to isolate which step regressed, then review session recordings or heatmaps for that step to check whether a control moved, got harder to find, or a new step was added.

Step 3: investigate non-design causes, in parallel, not as an afterthought. A tracking or analytics bug shipped alongside the redesign that miscounts events, a backend or performance regression that slowed that specific step, an unrelated external factor such as seasonality or a pricing change that shipped the same week, or a shift in which users the redesign reached compared to before.

Step 4: decide rollback versus iterate, based on what the investigation shows. If the cause is clearly one identifiable design element, a fast, targeted fix is usually faster and less disruptive than a full rollback. If the cause is unclear, severe, and revenue-critical, or a fix is not quick, I roll back first to stop the loss, then investigate and re-ship deliberately. If the root cause turns out to be non-design, a tracking bug or unrelated backend regression, rolling back the design would not even fix the problem, which rules that path out on the evidence.

Step 5: communicate the plan and timeline. I tell stakeholders what was found, what the fix is, or that a rollback is happening now while investigation continues, and give a specific date for the next update rather than leaving it open-ended.

Worked example

The checkout funnel's completion rate drops from 42% to 33% after a redesign. Step-by-step drop-off analysis shows the regression concentrates entirely at the payment-details step, nowhere else in the funnel. Design review of that step: a previously single-column payment form became two columns, and session recordings show many mobile users now have to scroll horizontally, effectively hiding the submit button. Non-design check, run in parallel: no tracking changes shipped that week, no backend latency regression at that step, no unrelated campaign or pricing change that week, and the drop is roughly even across new versus returning users, so it is not a segment shift either.

Conclusion: this is a design regression, isolated to mobile, at one specific step. Decision: not a full rollback, since the cause is now a specific, well-understood design element, but a targeted fix reverting that one step to a single-column layout on mobile while keeping the rest of the redesign, shippable within two days given the isolated scope. Communication to stakeholders: "the drop is real, it is isolated to the payment step on mobile due to a layout issue, not a tracking or backend problem. The fix ships by Thursday, and I will report the recovered conversion number Friday."

Trade-offs and pitfalls

Rolling back the entire redesign reflexively, when the cause is actually narrow, discards genuine improvements elsewhere in the funnel along with the one real problem. Investigating only the design, because that is what stakeholders are blaming, risks missing a non-design cause entirely, in which case even a full rollback would not fix anything. A full rollback buys speed and stops the immediate loss but resets any real gains the redesign made elsewhere; a targeted fix takes longer to diagnose but preserves those gains, and the right call depends on how time-sensitive and severe the drop is. Finally, going quiet during the investigation reads as either denial or incompetence to stakeholders watching a live metric drop, so a committed timeline for updates matters even before there is an answer.

Direct answer

Agreeing with feedback in the moment produces no evidence of anything; I only trust that I have actually incorporated feedback when I can point to a specific behavior change that shows up again later, checked against a written record rather than my memory of having nodded along.

Structured elaboration

The core problem with relying on memory is that people, myself included, systematically overestimate how much they have changed based on a single instance of trying. A concrete system fixes that:

• Keep a running feedback log. Every time I get substantive feedback, I write it down close to when it happens: the date, who gave it, what was said, and the specific change I am committing to. This is the same kind of artifact some people call a growth plan or retrospective notes; the exact format matters less than that it exists and gets updated in the moment, not reconstructed from memory weeks later.
• Tie each entry to something observable, not a vague intention. "Write tests before merging" is checkable later; "be more careful" is not. If feedback arrives too vague to turn into a checkable behavior, I ask a clarifying question before logging it, rather than logging something I cannot later verify.
• Revisit the log on a fixed cadence, not only when reminded. I check it weekly while it is short, and specifically before one-on-ones (1:1s, regular individual meetings with a manager) and ahead of performance conversations, where I use the log as raw evidence rather than trying to reconstruct the last few months from memory.
• Treat recurrence as the sharpest signal. If the same feedback shows up a second time, that is stronger evidence that the change did not actually stick than any amount of me believing it did; a recurrence gets escalated into a more concrete, checkable commitment rather than a repeated promise to try harder.

Worked example

A manager once told me my pull request descriptions explained what changed but never why, which made review slower for everyone. I logged it that day with the specific commitment: every PR description states the reason for the change, not just its contents. Two weeks later, reviewing the log before a 1:1, I checked my last several PRs against that commitment and found the "why" was present in most, but had slipped on one that was written under time pressure. That single recurrence told me the habit had not fully stuck yet, so instead of just recommitting verbally, I added a "why" field to the team's PR template, which turned the commitment into something the process enforced rather than something I had to remember unaided. I brought that log entry, including the slip and the fix, into my next 1:1 and later cited it in a self-review as concrete evidence of acting on feedback rather than just agreeing with it.

Trade-offs and pitfalls

It is possible to over-engineer the tracking itself into busywork, logging feedback in exhaustive detail without ever actually reviewing the log, which defeats the point. Conflating "I remember agreeing with it" with "I changed" is the exact failure mode this whole system exists to catch, so skipping the periodic review and trusting memory instead quietly reintroduces the problem. Tracking only critical feedback and never noting what is already working can also mislead, since it produces a lopsided, overly self-critical picture rather than an accurate one. Finally, a log that only gets opened right before a performance review, instead of on a regular cadence, provides much weaker evidence, since by then it is too late to correct course on anything that slipped months earlier.