|
| 1 | +- This is a framework for product managers conducting user interviews. |
| 2 | +- Problem: |
| 3 | + - feedback interactions are metastable due to their critical nature |
| 4 | + - without a process to guide it, divergence into conflict is the default |
| 5 | +- |
| 6 | +- The purpose of a feedback framework is to |
| 7 | + - make it safe for feedback to occur |
| 8 | + logseq.order-list-type:: number |
| 9 | + - ensure the feedback is extracted successfully |
| 10 | + logseq.order-list-type:: number |
| 11 | + - guide the conversation towards convergence and unity of understanding, and away from divergence/conflict |
| 12 | + logseq.order-list-type:: number |
| 13 | +- |
| 14 | +- A healthy feedback frame is marked by two powerful phrases: |
| 15 | + - **"Thank you for the feedback"** (vendor -> user) |
| 16 | + logseq.order-list-type:: number |
| 17 | + - this establishes safety (establishes you the vendor as a safe person) so that a vulnerable conversation can occur. The user is sticking his neck out in criticizing you and your product, they are in a position of vulnerability (and anticipating that you might whack them). We have all experienced failed encounters where feedback was not well received and the relationship was consequently damaged. |
| 18 | + - this is for you as much as them; it prompts you into a listening frame of mind and away from the default defensive stance (your biological survival instinct). |
| 19 | + - **"That's right"** (user -> vendor) — reflective listening |
| 20 | + logseq.order-list-type:: number |
| 21 | + - "That's right" is the goal, your job as the interviewer is to get the user to say this |
| 22 | + - The phrase serves as a handshake or checksum that the message has been correctly received as opposed to ignored or corrupted in transmission. |
| 23 | + - Listen, repeat what you hear, converge gap to zero, until person confirms with “that’s right." It takes more than one loop. At this point the loop has converged to a fixed point. Congratulations, the interview has completed successfully! Say thank you again and that you will use what you learned to inform your roadmap, end the call, you are done! |
| 24 | + - (Consider also the opposite, a divergent conversation. If a feedback conversation diverges, the user leaves damaged and will never speak to the vendor again. Analogously, when a marriage diverges, the result is divorce.) |
| 25 | +- |
| 26 | +- Example of turning around an actively failing conversation: |
| 27 | + - [https://clojureverse.org/t/electric-clojure-a-signals-dsl-for-fullstack-web-ui/9788/20?u=dustingetz](https://clojureverse.org/t/electric-clojure-a-signals-dsl-for-fullstack-web-ui/9788/20?u=dustingetz) |
| 28 | + - Thank you for the feedback → you’re right → acknowledge → refute central point → answer with numbers |
| 29 | + - User reply: “Okay, I see. ... ... Oh wow. By that description of electric, it’s much more thought out than I had first anticipated.” |
| 30 | + - [https://news.ycombinator.com/item?id=31219819](https://news.ycombinator.com/item?id=31219819) |
| 31 | + - We appreciate your concern -> you’re right → acknowledge -> refute central point with data |
| 32 | + - User reply: “This is a fair criticism!” |
| 33 | + - (Bomb diffused without detonation! Prospective user feels acknowledged for their contribution! Bravo!) |
| 34 | +- |
| 35 | +- **"That's right" vs "You're right"** — they are not the same thing |
| 36 | + - "That's right" is a listening checksum, it is how you confirm that you have understood correctly which lets the user feel heard |
| 37 | + - "You're right" is a magic compliance extraction tool for disarming an antagonist |
| 38 | +- |
| 39 | +- Anti-patterns |
| 40 | + - long responses |
| 41 | + - **quote-replies** (instead, **Refute the Central Point**, c.f. Paul Graham [How to Disagree](https://paulgraham.com/disagree.html)) |
| 42 | + - You don’t need to quote reply and address every little thing. Find the big thing, quote just that, and address it in 3 sentences. |
| 43 | + - **fast disagreeable replies** (fast supportive replies are okay) |
| 44 | + - people want to feel heard, their experience acknowledged |
| 45 | + - over-explaining |
| 46 | + - explaining at the wrong level |
| 47 | + - counterarguments |
| 48 | + - PAUL GRAHAM: "Counterargument is contradiction plus reasoning and/or evidence. When aimed squarely at the original argument, it can be convincing. But unfortunately **it's common for counterarguments to be aimed at something slightly different**. More often than not, two people arguing passionately about something are **actually arguing about two different things**. Sometimes they even agree with one another, but are so caught up in their squabble they don't realize it." https://paulgraham.com/disagree.html |
| 49 | + - absolute take on subjective topic |
| 50 | + - note: the user is allowed to do this in feedback frame, because you are asking them to express themselves. The vendor is NOT, you must be magnanimous! This is an asymmetric frame! |
| 51 | + - avoiding the zoom call |
| 52 | + - did you just spend 5 hours thinking about and typing up your rebuttal? How do you know you even rebutted the right thing? With body language, you'd have realized your mistake in the first 10 seconds. If it's not worth a zoom call it's not worth the rebuttal either |
| 53 | + - "well actually" https://www.recurse.com/social-rules |
| 54 | + - definition: "(conversation) used to introduce a contrary opinion" |
| 55 | + - defensive statements and other self-defense responses |
| 56 | + - dismissive statements and other expressions of judgement |
| 57 | + - the word "No" has no place here, it is a judgement and this is a judgement free zone |
| 58 | + - |
| 59 | +- |
| 60 | +- The problem with longform written communication |
| 61 | + - emails, forum posts, inline comments on a document are **terrible mediums for feedback** |
| 62 | + - it’s too slow to have error correction feedback loops, inevitably the train goes off the rails and then keeps going a while longer before anyone notices, destroying everything it touches before exploding in a ball of fire |
| 63 | + - slack DMs are still too slow ("User is typing a response..."), slack generates negative encounters that could have been positive, and wastes a bunch of time to boot - see [[The Myth Of Async Communication]] |
| 64 | + - feedback via body language is immediate and realtime and prevents the train from going off the rails |
| 65 | +- |
| 66 | +- Vendor is the dominant party, user is the subordinate party |
| 67 | + - responsibility for solicitation of feedback, and therefore the frame, is fully on the vendor |
| 68 | + - if the user attempts to establish a feedback frame unsolicited, that is unsolicited feedback |
| 69 | + - vendor mindset: **magnanimous** ("generous, understanding, tolerant") |
| 70 | + - the user is allowed to be confused, the vendor is not |
| 71 | + - the user is allowed to be frustrated, the vendor is not |
| 72 | + - the user is allowed to express irritation or annoyance, the vendor is not |
| 73 | +- |
| 74 | +- The feedback protocol does NOT require the vendor to agree with the feedback, only that they **hear** it |
| 75 | + - the goal is only to extract and capture the feedback in a way that does not damage the vendor/user relationship (lest the user churn or turn into a detractor) |
| 76 | + - the user does not need you to agree with their feedback, **they only want to feel heard** |
| 77 | + - analysis is a separate step, it can happen offline. |
| 78 | + - It is imperative that analysis DOES NOT occur during the feedback extraction call, because that can lead to a defensive or dismissive tone from the vendor. **If the vendor becomes defensive or dismissive, the feedback frame is immediately poisoned and no further communication can occur.** You have failed! |
| 79 | +- |
| 80 | +- Analyzing feedback |
| 81 | + - During the offline analysis stage, if the vendor doesn't agree with the feedback, that's fine, but be careful: all humans suffer cognitive bias. |
| 82 | + - You may not be understanding, or be ready to understand: |
| 83 | + - "Communication usually fails, except by accident" |
| 84 | + - "What we wish, that we readily believe." — Demosthenes |
| 85 | + - Or you may be avoiding or deflecting something that you are not ready to face: |
| 86 | + - "Every failure has a moment where you saw it and looked away. That moment is the reason" |
| 87 | + - As a rule of thumb, if you hear something three times, there's something there. |
| 88 | +- |
| 89 | +- How to Disagree? **Irrelevant**, disagreement has no place in feedback frame, it leads to divergence, conflict, discord. |
| 90 | + - PAUL GRAHAM: "Even as high as DH5 we still sometimes see deliberate dishonesty, as when someone picks out minor points of an argument and refutes those. Sometimes the spirit in which this is done makes it more of a sophisticated form of ad hominem than actual refutation." |
| 91 | +- |
| 92 | +- Why feedback matters? Because it generates market learnings -> user alignment -> growth |
| 93 | + - The goal of all startups is growth. (The opposite of growth is stagnation.) |
| 94 | + - Growth is generated by user alignment. |
| 95 | + - User alignment is guided by feedback. |
| 96 | + - |
| 97 | + - "Crossing the Series A Chasm" |
| 98 | + - Most startups get stuck between seed (value hypothesis validation) and Series A (growth hypothesis validation). Often, seed stage founders are building a product with themselves in mind as the Ideal Customer Persona (ICP) and their early adoption comes from innovators who share the founders mindset closely. But the market of innovators is small, and once saturated, growth will stall, because **the needs and expectations of the next concentric circle of adoption are fundamentally different** ([source](https://www.duetpartners.com/crossing-the-chasm-from-seed-to-series-a-2/)). |
| 99 | + - This is typically tackled by crafting a [[Positioning statement]] to help bring the product/market/customer into better focus. |
| 100 | + - At the seed stage, which we are exiting, we were still in the fog of war with a rapidly evolving hypothesis as we experiment and invalidate various concepts (which segments failed, which succeeded, how can we segment the market on various characteristics in order to isolate the successful use cases where we want to double down). |
| 101 | + - Ratcheting the clarify of the position statement and using that to align product roadmap to clearly defined market segments is how you produce the next concentric circle of adoption. |
| 102 | + - This is an iterative process that can take years, and is repeated at each order of magnitude of growth (10^3 users, 10^4, 10^5, 10^6, ...) |
| 103 | +- |
| 104 | +- See also |
| 105 | + - [[Powerful Phrases]] |
| 106 | + - [[Frames and frame collisions (communication)]] |
0 commit comments