QBRs Are Where Relationships Go to Die
You’re burning your champion’s political capital one slide deck at a time.
You want to know a dirty secret that every CS leader knows but nobody wants to put in writing? Your customers hate your QBRs. Your CSMs hate preparing them. And the standard format (a 60-minute slide deck reviewing usage metrics the customer already has access to) is actively making the relationship worse.
Think about what you’re actually asking your champion to do. They had to block an hour on their calendar. They probably had to pull in their boss or a peer. And now they’re sitting through 45 minutes of “here’s your adoption data” that they could have pulled from a dashboard in 30 seconds. You’re not providing value. You’re consuming their political capital to justify your own existence.
Technical buyers feel this harder than anyone. Engineers evaluate vendor relationships on two criteria: do you respect my time, and do you make me smarter? A QBR that reads back their own data fails both tests. Every single time.
This is the second post in a series on rebuilding Customer Success for technical products. Same format as last time: challenge something the industry treats as settled, offer a framework to replace it, and hand you the prompts to operationalize it this week.
The Problem: 60 Minutes of Nothing
Here’s what a standard QBR typically looks like.
Slide 1: company logos and “partnership overview.”
Slide 2: usage metrics with a green arrow pointing up.
Slide 3: support ticket summary.
Slide 4: NPS score.
Slide 5: “roadmap preview” that’s really just a marketing slide from the last product launch.
Slide 6: “open discussion” where everyone checks their phone.
Your champion sat through all of that and walked away with nothing they didn’t already know. Worse, they now have to justify to their boss why that meeting was worth the time. If they can’t, they stop accepting the invite. And you just lost your most important access point into the account.
Here’s what really happens after a bad QBR: your champion starts declining meetings. Not because they’re unhappy with the product, but because you’ve trained them to expect that every interaction with your team is a waste of time. That’s a self-inflicted wound.
The irony is that most CS teams treat QBR attendance as a health metric. “They showed up, so the relationship is fine.” No. They showed up because they felt obligated. The moment they stop feeling that obligation, you’ve already lost.
The Framework: The Technical Value Review (TVR)
I think the fix for these sorts of QBRs is to kill the format entirely and replace it with something designed for how technical buyers actually think.
Let’s call it the Technical Value Review. Here’s what makes it different.
No slides up front. Use a shared working document that both sides can edit. Send it to the customer 48 hours before the meeting. Let them add context, correct assumptions, and flag what they actually want to talk about. By the time you sit down together, half the meeting’s work is already done.
No usage reviews. They have dashboards. They know their numbers. If you’re spending meeting time reviewing data they already have, you’re telling them you have nothing better to offer. Stop it.
Three sections only. Everything in the document fits into one of three buckets:
1. Architecture Alignment. How has their technical environment changed since last time? New services, new teams, infrastructure shifts, reorgs. And given those changes, how should their use of your product evolve? This is the conversation that positions you as a technical partner instead of a vendor. You’re thinking about their architecture, not your renewal.
2. Roadmap Intersection. No one really wants a product marketing pitch. What customers really want is a specific mapping of what’s coming on your roadmap to their stated priorities. “You told us last quarter that observability across your microservices fleet is a priority. Here’s what we’re shipping in Q3 that directly addresses that. And here’s what we need your input on before we finalize the design.” That’s a conversation worth having.
3. Risk and Technical Debt. What’s fragile in their current implementation? What would you recommend they invest in before it becomes a support ticket? This is the section that builds trust faster than anything else in CS. You’re proactively telling them where the problems are, before they find out themselves.
30 minutes max. If you can’t deliver value in 30 minutes with a pre-shared doc and three focused sections, more time is not the answer. Better preparation is.
Why This Works for Technical Buyers
The TVR format works because it matches how engineers already operate. They read docs before meetings. They want the pre-read to be substantive, not a teaser. They hate slides. They evaluate people based on technical depth, not polish.
When you show up to a TVR and say “we noticed your API call patterns shifted last month, and given your migration to Kubernetes, here’s how we’d recommend restructuring the integration,” you just proved three things: you understand their architecture, you’re paying attention to how they use the product, and you have an opinion about how they should evolve. That’s a relationship. A slide deck with a green usage arrow is not.
The other thing the TVR does is shift the power dynamic. A QBR is something you do to the customer. A TVR is something you do with them. The shared doc means they have agency. The architecture section means they’re bringing knowledge to the table too. The roadmap section means their input actually shapes what gets built. They leave the meeting feeling like a partner, not a captive audience.
The Prompt Library
Three prompts to start running TVRs this week. Same drill as last time: pull data from your systems, fill in the brackets, and run them.
Prompt 1: TVR Prep Document Generator
Use this to build the shared working doc you’ll send to the customer 48 hours before the meeting.
You are preparing a Technical Value Review document for a meeting
with {customer_name}. Using the data below, create a concise shared
working document (not slides) with three sections.
Customer context:
- Industry: {industry}
- Primary use case: {use case}
- Technical environment: {stack details}
- Recent changes in their environment: {any known changes}
- Your product's recent releases relevant to them: {releases}
- Known implementation risks or technical debt: {risks}
- Their stated priorities for this quarter: {priorities}
Format the document as a collaborative working doc with:
1. Architecture Alignment (what's changed, what should evolve)
2. Roadmap Intersection (what's coming that matters to them,
questions to ask)
3. Risk & Technical Debt (what to address proactively)
Keep it under 2 pages. Use technical language appropriate for an
engineering audience. No marketing speak.
Try this: Run it for your most important renewal this quarter. Send the output to the customer as a shared doc and ask them to add their context before the meeting. Watch what happens when they show up having already engaged with the material.
Prompt 2: QBR-to-TVR Converter
Already have a QBR deck built? Don’t start over. Feed it to this prompt and let it strip out the filler.
I have a traditional QBR deck that I need to transform into a
Technical Value Review format. Below is the content from my current
QBR slides.
Current QBR content:
{paste slide content}
Remove all usage metric reviews, NPS references, and relationship
management filler. Extract the genuinely valuable insights and
restructure them into the TVR format:
1. Architecture Alignment
2. Roadmap Intersection
3. Risk & Technical Debt
Flag any content from the original QBR that has no place in a TVR
and explain why it was cut.
Try this: Take the last QBR deck you delivered. Paste the content in. The prompt will tell you exactly how much of your current format is filler versus substance. Most teams find it’s about 70/30 in the wrong direction.
Prompt 3: Post-TVR Action Item Synthesizer
The meeting’s done. Now turn your notes into an action plan within 2 hours.
Here are my notes from a Technical Value Review meeting with
{customer_name}.
Meeting notes:
{paste notes}
Generate:
1. A summary email to send to the customer within 2 hours (concise,
action-oriented, no fluff)
2. Internal action items categorized by: CSM follow-up, Product
feedback to log, Engineering/support escalation
3. Any state transition signals detected during the conversation
(refer to the state-based model: Onboarding, Expanding,
Steady-State, At-Risk, Recovering)
Try this: Use it after your next customer meeting. The state transition detection in item 3 connects back to the framework from the first post in this series. You’re not just taking notes. You’re feeding the system.
The Bottom Line
The QBR was designed for a world where customers couldn’t access their own data and the CSM was the only window into how the account was doing. That world doesn’t exist anymore. Your customers have dashboards. They have product analytics. They don’t need you to tell them what they already know.
What they need is someone who understands their architecture, has an opinion about where it should go, and is willing to flag risks before they become problems. That’s a Technical Value Review. It’s shorter, sharper, and it actually makes your champion look good instead of wasting their time.
Kill the deck. Share a doc.
This is the second post in a series on rebuilding Customer Success for technical products. If you missed the first one, start here: Your Health Score Is a Horoscope. Subscribe at michaelpgoetz.substack.com if you’re building CS for people who build software.