It sounds progressive. It sounds like alignment. And it’s quietly destroying the one thing that makes CS effective.

Trust.

The moment a customer perceives their CSM as a salesperson, the relationship changes fundamentally. Technical buyers are especially attuned to this. Engineers have been burned by vendor relationships that prioritized extraction over value. They can smell a pitch from three slides away, and once they do, you’ve lost something you can’t get back.

But here’s the part nobody says out loud: the best CS orgs drive more expansion revenue than sales-led models, not less. They just do it differently.

The Problem With Sales-Led Expansion

The standard playbook goes like this: CSM has a good relationship with the customer, so CSM should leverage that relationship to drive upsells. QBR becomes the venue for the pitch. Renewal becomes the forcing function for the expansion conversation.

This logic is backwards.

You’re converting a trust asset into a transaction, and you can only do that once. The champion, who used to be candid about what was broken, now hedges because they know the CSM has a number to hit. The engineering lead who used to pull you into architecture discussions stops inviting you because the last three conversations ended with a pricing conversation.

The revenue shows up short-term. The trust doesn’t come back.

I’ve watched this scenario play out at dozens of companies. The teams that grafted sales motions onto CS relationships saw an initial bump in expansion revenue followed by a slow, steady decline in NRR. Teams that took a different approach, one rooted in technical depth, consistently outperformed.

The Framework: Architecture-Led Expansion (ALE)

Expansion in technical products follows a predictable pattern: deeper integration leads to more use cases, more use cases lead to more users, more users create more value, and more value creates natural commercial expansion.

Your job is to accelerate that progression. Not to pitch upgrades.

ALE has four components:

1. Map the Whitespace Architecturally

Most expansion conversations start with "What else can we sell them?” ALE starts with "What does their full technical environment look like, and where else could our product add value they haven’t considered?”

This is a fundamentally different lens. You’re not looking at your product catalog and matching features to a customer. You’re looking at their architecture and identifying gaps where your product is the natural solution. The difference is subtle but critical: one feels like selling, the other feels like consulting.

At GitHub, the CSMs who drove the most expansion revenue were the ones who could diagram a customer’s entire development workflow and identify the friction points our platform could eliminate. They never pitched. They solved problems that happened to require additional capabilities.

2. Plant Seeds Through Problem-Solving

When a customer raises a challenge in a TVR or a support interaction, solve it. And if the solution naturally involves capabilities beyond their current plan, demonstrate rather than sell.

“We actually have a way to handle that” is the most powerful expansion sentence in CS. It positions the capability as a solution to their problem, not a product you’re pushing. The customer experiences it as help, not a pitch.

The key word is “naturally”. If you’re contorting every support interaction into an upsell opportunity, you’re doing sales-led expansion with extra steps. ALE only works when the connection between their problem and the additional capability is genuine.

3. Enable the Champion to Sell Internally

Your technical champion already believes in the product. They don’t need to be convinced. They need ammunition.

The Champion Enablement Package is the most underused tool in CS. Instead of you selling to their leadership, you equip your champion to make the case internally. This works for three reasons:

• Credibility: An internal advocate is more trusted than an external vendor.

• Context: They know the political landscape, the budget cycles, and the objections.

• Ownership: When they champion the expansion, they own the outcome, which means they’re invested in making it successful.

You have to build the package around their narrative, not yours. Architecture diagrams should show the current vs. proposed state. Three talking points framed around their business priorities. They fill in a simple ROI framework with their own numbers. Anticipate objections with suggested responses. Map a timeline to their budget cycle.

Every component should be something they can present as their analysis, not something that looks like it came from your marketing team.

4. Trigger-Based Expansion Conversations

Certain technical milestones naturally create expansion opportunities. Hitting usage thresholds. Completing initial integration. Adding a new team. Architectural reviews. Production deployments that change the scope of the implementation.

Consider incorporating these triggers into your operating model rather than depending on CSM intuition or renewal timelines.

The distinction between vanity signals and real expansion signals is critical. A green health score tells you the customer is happy. Expansion signals tell you they’re ready. Most CS teams only instrument the first metric. ALE requires you to instrument both.

The Two Failure Modes

Failure Mode 1: Stealth Sales

This scenario is where a CS team adopts ALE language but keeps running a sales-led motion underneath. The CSM “maps the whitespace,” but the whitespace map is really just a territory plan. They “enable the champion,” but the enablement package is a sales deck with the logo removed.

Technical buyers see through the charade immediately. If your champion enablement package has your product name in the header and your competitive positioning in the talking points, it’s not enablement. It’s a brochure.

The test: Could your champion present this material without mentioning your company name and have it still be valuable? If not, it’s not enablement.

Failure Mode 2: Passive Waiting

The opposite failure. The CS team is so afraid of being perceived as sales that they never proactively surface expansion opportunities. They wait for the customer to ask. They wait for renewal. They wait for the champion to figure out on their own that more capabilities exist.

ALE isn’t passive. It’s proactive problem-solving that creates natural pull. You’re solving problems, demonstrating capabilities, and equipping champions. The expansion conversation is a consequence of excellent technical partnership, not an agenda item you’re avoiding.

The One Metric That Matters

If you adopt ALE, the metric you track changes.

Sales-led expansion tracks expansion revenue per CSM, which is a number that incentivizes CSMs to push. ALE tracks champion-initiated expansion rate, the percentage of expansion deals where the customer reached out first or the champion drove the internal business case.

A healthy ALE motion should produce a champion-initiated rate above 60%. If most of your expansion is still CSM-initiated, you haven’t shifted the model, you’ve just relabeled it.

The Prompt Library

Two prompts and one agent workflow to operationalize ALE in your CS org.

Prompt 1: Whitespace Analyzer

Analyze this customer's current product usage and technical environment to identify expansion opportunities that are architecturally natural — not forced upsells.

Current state:
- Products/modules currently using: {list}
- Current usage volume and trends: {data}
- Known technical environment: {stack}
- Teams currently using the product: {teams}
- Integrations in place: {integrations}
- Problems they've raised in the last 6 months: {support themes}

Identify:
1. Adjacent use cases where the product could solve problems they're currently handling with other tools or manual processes
2. Teams or departments that would benefit but aren't currently using the product
3. Technical milestones they're approaching that naturally create expansion conversations
4. The single highest-probability expansion opportunity and a recommended approach that feels helpful, not salesy

Prompt 2: Champion Enablement Package Builder

My technical champion at {customer_name} wants to expand our product to {new use case/team/capability}. They need to make an internal business case to their leadership.

Context:
- Champion's role: {title}
- Current deployment: {what they're using today}
- Proposed expansion: {what they want to add}
- Their leadership's likely concerns: {concerns}
- Budget cycle timing: {when}

Create a champion enablement package:
1. A one-page architecture diagram description showing current state vs. proposed state
2. Three talking points framed around their business priorities (not our product features)
3. A simple ROI framework they can fill in with their own numbers
4. Anticipated objections and suggested responses
5. A recommended timeline that aligns with their budget cycle

Agent Workflow: Expansion Signal Monitor

You are monitoring a portfolio of accounts for natural expansion signals. Review the following data weekly and flag accounts showing expansion readiness.

Portfolio data:
{structured account data including usage, support, engagement}

Expansion signals to detect:
- Usage approaching tier thresholds (>80% of current plan)
- New teams or users being added organically
- Support questions about capabilities not in their current plan
- Integration with new tools that suggest evolving use cases
- Champion promotions or role changes that increase their influence
- Positive references to the product in external channels

For each flagged account, specify:
1. Which signal(s) triggered the flag
2. Recommended expansion conversation approach
3. Timing recommendation (act now vs. nurture)
4. Whether to engage directly or equip the champion

This is Post 4 of a 5-part series: Rebuilding Customer Success. Next up: the scaling problem nobody wants to talk about and why the answer isn’t more headcount.

If these frameworks and prompts are useful, subscribe for the final post and the complete prompt library that comes with it.

Engineers would rather not be trained. They want to solve their problem. They’ve already read your docs. They Googled your API. They probably found a GitHub thread where someone had the same edge case they’re worried about. What’s standing between them and production isn’t knowledge. It’s friction.

The fastest path to value isn’t a webinar series. It’s removing every obstacle between the customer’s intent and their first meaningful outcome.

The best onboarding for technical products doesn’t look like customer success. It looks like developer experience design.

The Framework: Time-to-Architecture (TTA)

Stop measuring time-to-value. It’s vague, difficult to define, and almost impossible to benchmark consistently. Replace it with time-to-architecture: the elapsed time between contract signing and the customer having your product embedded in their production architecture in a way that would be painful to remove.

TTA is a real number. It’s measurable. And it predicts retention far better than any satisfaction survey.

Four principles:

1. Outcome-first onboarding: Start with "What are you trying to accomplish?" not “here’s how our product works.” Most CSMs start onboarding by walking through feature menus. Technical buyers tune out immediately. Map their stated goal to the fastest implementation path before you touch a single slide.

2. Progressive complexity: Get them to a working integration in hours, not weeks. One integration that works in production is worth more than a 12-module training course that ends with “now let’s schedule the kickoff.” Think about how the best developer tools work: Stripe's accepting a payment in 5 minutes, Twilio’s first SMS, and Vercel’s first deploy. The entire UX is designed around the moment of first success. Your onboarding should be no different.

3. Architecture anchors: Deliberately help customers integrate in ways that create healthy dependencies. Not lock-in for its own sake, but genuine architectural value that makes your product load-bearing. An integration that sits on the edge of someone’s stack is easy to remove. One that sits in the middle of their data pipeline is not. Guide them toward the middle.

4. Self-service with instrumentation: Let technical users move at their own pace. Forcing them into a CSM-led process every step of the way is friction, not service. Build docs, quick starts, and templates that make self-direction the path of least resistance, but instrument the journey so you know when someone is stuck, stalled, or going down an implementation dead end.

Why CSMs Keep Getting Onboarding Wrong

There are two failure modes I see frequently.

The first is feature tourism. The CSM walks the customer through every part of the product in the first few sessions, covering things the customer won’t need for six months. By the time they actually need something, they’ve forgotten the walkthrough. Meanwhile, you've missed the opportunity when they're most eager to act quickly.

The second is milestone theater. The onboarding plan has 14 steps, each marked complete when the customer sits through a meeting. But meeting attendance isn’t progress. The only milestone that matters is whether this thing is in production. Everything else is a process.

The underlying problem in both cases is that the onboarding is designed around the vendor’s comfort, not the customer’s intent. CSMs want a structured sequence they can report on. Engineers want to ship something.

What TTA Changes

When you organize onboarding around time-to-architecture, a few things shift.

First, kickoff calls change. Instead of “let’s review the onboarding timeline,” the first call is, "What does your production architecture look like today, and where does our product fit?” That’s a conversation technical buyers actually want to have.

Second, success milestones become real signals. “Completed module 3” tells you nothing. “First API call in production” tells you a lot. “Product embedded in two workflows” tells you you’re probably going to retain this account.

Thirdly, CSM time is allocated to the edges. A significant portion of onboarding effort is often directed towards customers who are likely to understand it on their own. TTA instrumentation shows you who’s actually stuck so you can deploy human attention where it changes the outcome, not where it provides the appearance of service.

The Prompt Library

Prompt 1: Onboarding Path Generator

A new customer just signed. Based on their profile, design a personalized onboarding path optimized for minimum time-to-architecture.

Customer profile:
- Company size: {size}
- Technical maturity: {low/medium/high}
- Primary use case: {use case}
- Existing tech stack: {tools and platforms}
- Decision maker role: {title}
- Implementation team: {who's doing the work}
- Success criteria stated during sales: {criteria}

Generate:
1. The single fastest path to a working production integration (target: under 2 weeks)
2. Three milestone checkpoints with specific observable signals that confirm progress
3. Potential friction points based on their stack and maturity level
4. Recommended self-service resources to send before the kickoff call
5. Questions to ask in the kickoff that a traditional onboarding script would miss

Prompt 2: Onboarding Friction Detector

Review the following onboarding data for customers who started in the last 90 days. Identify where TTA is breaking down.

Onboarding data:
{structured data: customer, start date, current milestone, days at each stage, support tickets opened, CSM touchpoints}

Analyze:
1. Which stage has the longest average dwell time?
2. Are there segments (by company size, use case, or stack) that consistently stall?
3. What support ticket patterns emerge during onboarding?
4. Which customers reached production integration fastest — what did they have in common?

Recommend 3 specific changes to the onboarding process that would reduce average time-to-architecture.

One Metric to Add This Week

If you’re not tracking TTA today, start with a proxy: days from contract signed to first production API call (or equivalent for your product). Pull the last 90 days of new customers. Segment by company size and technical maturity. Find the outliers (the customers who got there fast) and figure out what they had in common.

That pattern is your new onboarding template.

This is the third 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.

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.

Health scores are the horoscope of Customer Success. Vague enough to feel true. Updated too slowly to be useful. And they exist mostly to make the person reading them feel like they understand something they don’t.

This is the first post in a series where I’m going to challenge things the CS industry treats as settled, offer a framework I’d actually use, and hand you the prompt library or agent workflow to put it into practice. No theory without tooling. Here we go.

The Problem: Performative Dashboards

You know how these things get built. Take a handful of inputs (NPS, support ticket volume, login frequency, maybe a CSM gut-feel rating), throw some weights on them that somebody argued about in a meeting, and produce a composite number. Green, yellow, red. Board deck looks great.

Now ask a CSM what they’re supposed to do when an account turns yellow. You’ll get a shrug. Or worse, they’ll send a check-in email. The score told them something changed but not what, not why, and definitely not what to do about it. It’s a summary of stuff that already happened pretending to be a prediction.

But here’s the part that really gets me. The deeper failure isn’t that the score is wrong. It’s that the score trains your team to manage numbers instead of managing customers. CSMs figure out how to game the inputs. Leadership starts trusting the dashboard more than the people closest to the accounts. And the signals that actually predict churn (deployment logs, API call patterns, the day a champion updates their LinkedIn) those never make it into the model. Too hard to quantify. Too messy to weight.

I’ve watched a team spend months arguing about whether NPS should be 15% or 20% of the composite score. While that was happening, a strategic account quietly ripped out the integration because their internal champion left and nobody noticed. Health score was green the whole time.

The Framework: Signal-Based Customer State Detection

The answer isn’t a better health score. It’s scrapping the whole concept.

Replace it with a state machine. Customers aren’t a number on a 0-100 scale. They’re in one of a handful of states at any given time:

• Onboarding: Still implementing, clock is ticking on time-to-value

• Expanding: Rolling out to new teams, adding integrations, usage climbing

• Steady-State: Stable, not growing, not shrinking. Coasting.

• At-Risk: Usage declining, integrations getting pulled, champion gone quiet

• Recovering: You’ve intervened, re-engagement is underway

The thing that matters isn’t the state itself. It’s the transitions. When a customer moves from Expanding to Steady-State, that means something. When they slide from Steady-State to At-Risk, that’s not a yellow dashboard. That’s a fire drill with a specific playbook attached to it.

Three ideas make this actually work in practice:

1. Flip from lagging to leading indicators.

Most health scores are built on data that tells you what already happened. NPS is how someone felt last quarter. Ticket volume is what already broke. You need the stuff that tells you where the account is headed: deployment velocity, feature adoption curves, how deep the integration goes, how often the champion is engaging. Forward-looking, not rearview mirror.

2. Trigger playbooks off state transitions, not score changes.

“Score dropped from 82 to 71” is meaningless. Nobody knows what to do with that. But “this account just moved from Expanding to Steady-State”? Now you’ve got something. Schedule an architecture review. Find the next expansion use case. Get back in front of the exec sponsor. That’s a to-do list, not a guessing game.

3. Treat technical depth as your best retention signal.

This one’s specific to technical products, and it’s the hill I’ll die on. The best predictor of whether a customer stays isn’t their satisfaction score. It’s how tangled up your product is in their architecture. Count the integration points. I like to call them “retention anchors”. Look at API call diversity. Figure out how many of their internal tools depend on yours. A customer running 15 integrations with 4 internal tools built on your API? They’re not leaving. I don’t care what their NPS is. A customer with one shallow integration and a great NPS? They’re one executive decision away from rip-and-replace.

The Prompt Library

OK, so how do you actually start doing this? Here are three prompts you can run this week against real customer data. They work with Claude, ChatGPT, whatever you’ve got. Pull structured data from your CRM, product analytics, and support system, and feed it in.

Prompt 1: Customer State Classifier

This one replaces your health score for a single account.

You are a Customer Success analyst specializing in technical B2B SaaS.
Given the following customer data, classify this customer into one of
these operational states: [Onboarding, Expanding, Steady-State,
At-Risk, Recovering].

Customer data:
- Account age: {months}
- Product usage trend (last 90 days): {increasing/flat/declining}
- Features activated vs. available: {ratio}
- Support ticket trend: {increasing/flat/declining}
- Last executive sponsor contact: {days ago}
- Recent integration/API changes: {description}
- Contract renewal date: {date}

Classify the state and explain which signals were most determinative.
Then recommend the top 3 actions the CSM should take this week,
specific to the detected state.

Try this: Run it on your top 20 accounts and compare to what your current health score says. I’d bet money at least 3 accounts come back in a different state than your dashboard shows.

Prompt 2: State Transition Detector (Weekly Batch)

This is your new Monday morning portfolio review.

You are reviewing a portfolio of {N} accounts. For each account below,
compare their current signals to their signals from 30 days ago.
Identify any accounts that have shifted operational states.

For each state transition detected:
1. Name the transition (e.g., "Expanding → Steady-State")
2. Identify the 2-3 signals that drove the change
3. Flag urgency: routine, elevated, or critical
4. Recommend the specific playbook to execute

Account data:
{structured account data with current and 30-day-prior snapshots}

Try this: Use it to replace your weekly health score review. Instead of everyone staring at a dashboard trying to figure out what the numbers mean, you walk in with a ranked list of state transitions and a playbook for each one. The meeting goes from interpretation to execution.

Prompt 3: Health Score Audit

Run this once to find out where your current model is lying to you.

I'm going to share our current health score model. Analyze it for
the following failure modes:
- Lagging indicator dependency (signals that tell you what already
  happened)
- Vanity signal inclusion (metrics that feel important but don't
  predict outcomes)
- Missing technical depth signals
- Weighting that obscures rather than clarifies

Current health score model:
{paste your model: inputs, weights, thresholds, and any logic}

Provide a redesigned scoring approach using state-based detection
instead of composite scoring. Map each of our current inputs to
either: a state classification signal, a transition trigger, or
"remove: does not predict outcomes."

Try this: Paste your actual health score model in. Inputs, weights, thresholds, all of it. You’ll find out which signals actually predict outcomes, which ones are vanity metrics making you feel good, and how to restructure around state detection. Do it before your next QBR.

The Bottom Line

Health scores were built for a world where CS was an account management function and the main event was a quarterly business review. If you’re running CS for a technical product, where your customers are engineers, your value lives in their architecture, and retention comes down to integration depth, you need something that thinks in states and transitions, not weighted averages.

Kill the horoscope. Build a state machine.

This is the first post in a series on rebuilding Customer Success for technical products. Next up: why your QBR format is optimized for the wrong audience. Subscribe at michaelpgoetz.substack.com if you’re building CS for people who build software.

It’s been 9 months since I’ve published here. A lot has changed.

When I started this Substack, I was building a startup with AI tools and writing about that experience. Since then, I’ve taken on the SVP of Customer Success role at Drata, and the thing I’ve been thinking about most isn’t how to build software — it’s how to rebuild the way we run Customer Success for technical products.

Here’s what this publication is now:

I’m writing for CS leaders at technical SaaS companies. The ones whose customers are engineers, whose retention depends on architectural depth, and who are tired of frameworks designed for a different buyer.

Every post follows the same format: a challenge to something the CS industry treats as settled, an opinionated framework to replace it, and a prompt library or AI agent workflow you can run against real customer data that week.

Look out for the first post tomorrow. “Your Health Score Is a Horoscope” is focused on why composite health scores are performative dashboards and what to build instead.

If this new direction isn’t your thing, no hard feelings, unsubscribe link is below. If it is, I’m glad you’re here.

— Michael

Last week, Amazon quietly launched something called Kiro. Most people saw "another AI coding tool" and moved on. I almost did too.

But something in their launch post caught my eye: they weren't selling speed. They were selling thinking.

After five weeks of vibecoding my way through RallyCamp, shipping features fast but accumulating technical debt faster, this hit different. So I signed up, played around with it for a few hours, and discovered something that changed how I use Claude Code.

Here's the thing: you don't need Kiro to use their best idea.

What Kiro Actually Does

Kiro forces you to build in a specific order:

1. Requirements first (what problem are you solving?)

2. Design second (how will you solve it?)

3. Tasks third (what's the step-by-step plan?)

4. Code last (now execute the plan)

If you try to skip ahead, it literally won't let you. The AI refuses to write code until you've thought through the problem.

My first reaction: "This is going to slow me down."

My second reaction, after trying it: "Holy shit, this is exactly what I've been missing."

The Pattern Hidden in Plain Sight

Here's what fascinated me: Kiro uses Claude under the hood. The same Claude I've been using in Claude Code. The same Claude that's been happily building whatever half-baked idea I throw at it.

The difference wasn't the AI. It was the workflow.

So I did what any reasonable person would do. I tried to replicate Kiro's pattern directly in Claude Code.

My First Experiment

I had just run a codebase review on RallyCamp and discovered something horrifying: I had copy-pasted authentication code across 8 different API routes. Eight! The same security-critical code, duplicated everywhere.

Instead of my usual approach ("hey Claude, fix this mess"), I tried the Kiro way.

Step 1: Requirements

Create a requirements.md file for fixing code duplication issues. I have auth code copied 8+ times, validation error handling in 15+ places, and the same patterns repeated everywhere. Focus on why this is a problem and what the solution needs to achieve.

What came back surprised me. Instead of jumping to refactoring, Claude asked questions:

• What happens when you need to fix a security bug in the auth code?

• How many places could you miss?

• What's the blast radius if you get it wrong?

We went back and forth for 10 minutes. By the end, I had a requirements doc that clearly explained WHY this wasn't just about clean code, it was about security and maintainability.

Step 2: Design

Based on requirements.md, create a design.md file for the refactoring. 
Include the new architecture, where shared code will live, and how 
we'll migrate without breaking existing features. No code yet.

This is where it got interesting. Because Claude had the requirements context, the design actually addressed real risks. It suggested things like:

• Creating a phased rollout (security-critical auth first)

• Building comprehensive tests before touching anything

• Setting up feature flags for gradual migration

Stuff I would've learned the hard way after breaking production.

Step 3: Tasks

Break down design.md into specific implementation tasks in tasks.md. Phase 1 should be security-critical auth code. Each task should be independently testable. Order by risk and dependencies.

Now I had a roadmap. Not just "refactor everything" but a three-week plan:

• Week 1: Extract auth middleware, test exhaustively, migrate routes

• Week 2: Create validation handlers and unified API client

• Week 3: Extract shared schemas and utility functions

Step 4: Actually Build

Execute task 1 from tasks.md: Create lib/api/auth.ts with 
requireAuth() middleware. Reference the duplicated code patterns 
from the codebase review.

The code that came out was different. Better. It knew exactly what patterns to extract and why.

Why This Changes Everything

Remember my post about technical debt? About how AI builds code optimized for different constraints than yours?

This fixes that.

When you give AI the full context (requirements, design, architecture) it builds code optimized for YOUR constraints. Your security requirements. Your maintenance needs.

The auth refactoring? It touched 8 critical files. Zero bugs. Zero downtime. That's never happened with my "just fix it" approach.

Even better: the refactoring actually reduced the codebase by 1000+ lines. Turns out when AI understands the full picture, it doesn't just move code around, it finds better patterns.

The Real Magic: Thinking Time

Here's what I realized: The value isn't in the documents. It's in the thinking that happens while creating them.

When I'm writing requirements, I'm not just listing features. I'm discovering edge cases. When I'm writing design docs, I'm not just planning architecture. I'm spotting problems before they're expensive.

The AI helps with this thinking. It asks questions I don't think to ask. It spots patterns I miss. It's like pair programming, but for product design.

My Current Workflow

I still use Claude Code for everything. I just use it differently:

Monday: Think through the week's features. Create requirement docs for each.

Tuesday: Turn requirements into designs. Let Claude challenge my assumptions.

Wednesday-Thursday: Execute tasks. The actual coding is the easy part now.

Friday: Ship with confidence.

I'm building at the same speed, but with 90% fewer "oh shit" moments.

But Here's the Catch

This approach has one major downside: it's addictive.

Once you experience building with clarity (ie. knowing exactly what you're making and why) it's hard to go back to chaos mode. Even for quick experiments, I find myself writing mini-specs.

Last week, I spent 20 minutes spec'ing out a feature that would've taken 10 minutes to build directly. The feature took another 15 minutes to build with the spec.

Total time: 35 minutes instead of 10. But you know what I didn't spend time on? Debugging. Fixing edge cases. Rebuilding it when users complained.

You Don't Need Kiro for This

Look, Kiro seems cool. The interface is slick, the workflow is smooth, and having guardrails built-in is nice.

But you don't need it.

You just need discipline to think before you build. And if you're using Claude Code like me, you can start right now:

# Start a new feature the right way
claude "I want to add [feature description]. 
Let's start by creating a requirements doc. 
Ask me questions until you understand the problem space, 
then write requirements.md"

That's it. That's the secret. Make the AI think with you before it codes for you.

The Unexpected Benefit

Remember my "47 ChatGPT chats" problem? This solves that too.

Now I have one chat per feature, but it contains the complete journey: requirements → design → tasks → code. When I need to modify something weeks later, the context is all there. The thinking is documented.

My codebase has become self-documenting. Not through code comments, but through the thoughts that created the code.

What This Really Means

We're at a weird moment in software development. AI can build almost anything we can describe. The bottleneck isn't coding speed anymore, it's thinking speed.

The teams that win won't be the ones with the best prompts or the fastest AI. They'll be the ones who think before they build.

Kiro gets this. That's why they built an entire IDE around making you think first. But you can get the same benefit with any AI tool. You just have to choose to slow down in the right places.

Your Move

This week, try building one feature the Kiro way:

1. Requirements (what problem?)

2. Design (what solution?)

3. Tasks (what steps?)

4. Code (execute the plan)

Use whatever AI tool you prefer. The tool doesn't matter. The order does.

And if you're already using Claude Code, steal my prompts above. They work.

P.S. - That auth refactoring? Not only did it eliminate security risks, it made adding new API routes 10x faster. Now it's just requireAuth() instead of 50 lines of copy-paste. Sometimes thinking first pays compound interest.

The Reality Check

I’ve been a bit absent writing the last few weeks. That’s because I ran into something nobody mentions in the "build with AI" tutorials: shipping is just the beginning.

My prompt chain had worked beautifully. I'd gone from idea to working app in four weeks. The code looked clean, the features worked, and I was feeling pretty confident about this whole AI-assisted development thing.

Then I decided to add in some functionality to manage the waitlist for users.

And that's when I discovered technical debt I never saw coming.

The Illusion of Clean Code

Here's what AI-generated code looks like when it's fresh: organized file structure, descriptive function names, helpful comments throughout. It feels professional because AI is really good at making things look professional.

But looking professional and being maintainable are two very different things.

The first time I needed to modify a feature based on user feedback, I realized I was debugging code I didn't actually understand. Sure, I could read it. But reading code and understanding the architectural decisions behind it? Completely different skills.

The Hidden Costs of "Fast" Development

When you build with AI, you're essentially inheriting someone else's codebase from day one. Except that "someone else" is a system that makes decisions differently than you would.

AI optimizes for getting the feature working. You optimize for getting the feature working and being able to change it later when users inevitably want something slightly different.

This creates four types of technical debt that traditional coding tutorials never prepare you for:

1. The Black Box Problem

AI creates functions that work perfectly for the exact use case you described. But when you need to modify them, you realize they're doing multiple things at once in ways you wouldn't have architected yourself.

2. The Over-Engineering Trap

AI tends to build for scale and edge cases you don't need yet. My simple app ended up with enterprise-level complexity for features that could have been much simpler.

3. The Dependency Web

AI is great at leveraging existing libraries. Sometimes too great. What starts as a simple request can end up pulling in multiple dependencies that you'll need to maintain and debug.

4. The Context Gap

This is the big one. AI builds exactly what you describe, not what you mean. The nuances of your specific use case—the business logic that makes your app unique—often get lost in translation.

What Debugging Actually Looks Like

Debugging AI-generated code follows a predictable pattern:

First, you think it'll be a quick fix. The error message seems straightforward enough.

Then you realize the "simple" feature is connected to three other systems in ways that aren't immediately obvious.

Then you spend more time understanding the existing code than it would have taken to write the feature from scratch.

Finally, you either patch around the issue (creating more technical debt) or rewrite the section entirely.

The problem isn't that AI writes bad code. It's that AI writes code optimized for different constraints than yours.

The Two-Part Solution

After working through this with RallyCamp, I've developed an approach that actually works:

Part 1: The 80/20 Strategy

Let AI handle the first 80%—the boilerplate, standard implementations, and common patterns every app needs. But plan to rewrite the last 20% yourself: the business-specific logic that makes your app unique.

This gives you the speed benefits of AI without losing understanding of your core functionality.

Part 2: The Documentation Requirement

After AI generates any significant code, I run it through this prompt:

"Explain this code like I'm going to maintain it for the next two years. What does each major function do? What are the key dependencies? What assumptions are built into this logic? What would break if I needed to modify [specific functionality]?"

This creates a maintenance roadmap before you need it, not after something breaks.

The Real ROI

Was building RallyCamp with AI worth it? Absolutely. But not for the reasons I expected.

AI didn't eliminate technical complexity—it shifted when I dealt with it. Instead of spending weeks learning to code before building anything, I spent time learning to debug and refactor after shipping something real.

The value wasn't avoiding technical challenges. It was facing the right technical challenges with real user feedback driving the decisions.

What I'd Do Differently

Starting over, here's what I'd change:

1. Build one feature completely (including understanding and documentation) before moving to the next

2. Set debugging time limits—if I can't understand and fix an AI-generated issue in a reasonable time, I rewrite that section

3. Plan for iteration from day one—assume every feature will need modification based on user feedback

4. Document architectural decisions as I go, not after something breaks

The Mindset Shift

The biggest insight isn't about code—it's about expectations.

AI doesn't eliminate technical complexity. It relocates it from "learning to build" to "learning to maintain." Both are valuable skills, but they're different skills.

The founders who succeed with AI won't be the ones with the perfect prompts. They'll be the ones who plan for technical debt as a natural part of the process.

Because when your users need a feature modified, and they're waiting for the fix, the quality of your prompts matters less than your ability to understand and change the code that's already running.

Building with AI? I'd love to hear what technical debt you've discovered. Reply and let me know what surprised you most about maintaining AI-generated code.

ChatGPT Hell

You know that feeling when you have so many browser tabs open that the favicons disappear and you're just looking at a wall of gray rectangles? That was me four weeks ago, except worse. I had 47 ChatGPT chats open. Forty. Seven.

Each one was a different conversation thread about RallyCamp, my camping app idea. One tab for database design. Another for user authentication. Three separate ones just for different approaches to the scheduling system. I'd hop between them like a caffeinated squirrel, copying bits from one conversation, pasting into another, trying to remember which tab had that brilliant insight about Scout leader workflows.

11 PM, One Reddit Link

It was 11pm on a Tuesday when everything changed. I was scrolling Reddit, specifically r/vibecoding, when I found a thread titled "This is how I build & launch apps (using AI), even faster than before."

The thoughtfulness of the approach just blew me away. And it made a ton of sense to me. I had been treating ChatGPT like a better Google search, trying to learn all of the various roles and context myself. This approach was changing me from a do-it-all-yourself quasi-developer to an AI boss, something that was much more relatable to my recent real life work.

The commenter had linked to their workflow, but honestly, it was overwhelming. Pages and pages of complex prompts with variables and conditionals. I almost closed the tab, but something made me try a simpler version.

The 12-Word Prompt Factory

I opened a fresh ChatGPT window. Just one. And I started with the most basic prompt I could think of:

What are the top 5 most in-demand consumer topics for outdoor recreation apps?

Nothing fancy. No complex instructions. Just a question. But here's where it got interesting. Instead of diving straight into features or code, I took the AI's response and fed it into a second prompt:

Based on these market opportunities, give me 10 app ideas for Scout camping coordination.

Then I took the best idea from that list and wrote my third prompt. And this is where I almost fell out of my chair, because it was literally just seven words:

Create a product requirements doc for this app

Seven words. That's it. And ChatGPT spit out a comprehensive PRD that was better than anything I'd cobbled together across my 47 tabs.

Why Sequence Beats Complexity

But here's the thing. Those simple prompts worked because they were in sequence. Each one built on the last. The market research informed the ideation. The ideation informed the requirements. It was like... well, like a factory line.

Over the next few days, I refined this approach. My prompts got a bit more sophisticated, sure. But the core insight remained the same. Instead of having 47 conversations about 47 different aspects of my app, I had one conversation that flowed from market validation all the way to working code.

The first three prompts in my chain became the foundation for everything:

First, I'd validate the market. Not with some generic "is this a good idea?" question, but by researching actual consumer spending patterns and market trends. This kept me from building something nobody wanted.

Second, I'd generate technically feasible ideas based on that research. Not pie-in-the-sky features, but actual MVPs I could build with AI assistance.

Third, I'd refine the winning idea into a proper product strategy. Not just features, but user personas, go-to-market plans, the works.

What used to take me days of jumping between tabs now took hours in a single, focused session. More importantly, each output was connected. The technical architecture actually matched the product requirements. The product requirements actually matched the market opportunity.

Shipping RallyCamp in Four Weeks

Last week, I shipped the beta of RallyCamp. We've got a few friendly Scout leaders testing it since we are hitting prime camping season. All from a system that started with seven words and a Reddit post at 11pm.

The crazy part? My prompts are still pretty simple. Sure, they've evolved from those first seven words, but they're not the complex monstrosities I thought I needed. They're just clear, sequential instructions that build on each other.

I've been refining these prompts with each project iteration, and I've decided to share them. Not because they're perfect, but because they work. And because I remember staring at those 47 chats thinking there had to be a better way.

Steal My First Three Prompts

This week, I'm sharing the first three prompts in my chain. The ones that take you from "I have an idea" to "I have a validated product strategy." They're the foundation everything else builds on.

Next week, I'll share the prompts that turn that strategy into an actual technical plan. The week after that, the ones that generate working code.

But it all starts with these three. The same three that helped me go from 47 tabs of chaos to shipping actual software in four weeks.

We've been using AI wrong. Not because we need more complex prompts or better models. But because we've been treating each conversation like it exists in isolation, when what we really need is a system.

A chain where each link strengthens the next.

So yeah, that Reddit thread really did change everything. Not because it gave me the perfect prompts, but because it showed me that the perfect prompt doesn't exist. What exists is the perfect sequence. The right questions in the right order.

And it all started with closing 47 chats and opening just one.

P.S. If you want to try the prompts yourself, grab them here. Start with just the first one. See what market opportunity resonates with you. Then feed that into the second prompt. Then the third. Don't overthink it. The magic isn't in any individual prompt. It's in the chain.

The Before State

Five weeks ago, I'd just left GitHub after 4.5 years building Customer Success teams. My last serious coding attempt was basic Python for AWS automation—four years ago. I was that manager who understood how software worked but couldn't build it anymore.

Then I saw someone on Reddit mention they'd built an entire SaaS in a weekend using "vibecoding."

My first thought: "I’m not putting my data in there." My second thought: "...but surely I could figure out a better way?"

Week 1: The Gateway Drug

I started safe with Lovable. No code to write, just describe what you want. My prompt was ambitious for someone who'd been managing, not making:

"Create an interactive journey mapping tool that includes collaboration features, AI driven analysis and recommendations."

Five minutes. That's all it took.

I stared at my screen. This wasn't a mockup or wireframe. Forms worked. Buttons clicked. Data persisted. It even recommended next steps: "Connect Supabase for user accounts and data persistence."

What the hell is Supabase? Didn't matter. There was a button. I clicked it.

Suddenly I had authentication, a database, API endpoints—infrastructure that would've taken me weeks to set up properly. Working. In fifteen minutes total.

I actually said "holy shit" out loud. Then I immediately went upstairs to my wife’s home office: "I just built this thing in like 15 minutes and it mostly works. This is pretty transformational."

The weirdest part? After building my dream CS tool in 15 minutes, I realized... I didn't actually want to run a journey mapping company. When building becomes this easy, you can afford to be picky.

Week 2: Down the Rabbit Hole

If Lovable was gateway drug, ChatGPT Plus was the hard stuff. I bought the annual subscription (first of many AI subscriptions I'd impulse buy).

New idea: Website builder for local small businesses! ChatGPT turned interviewer:

• "What's your initial budget?"

• "Uh... zero dollars please?"

• "What's your technical differentiation?"

• "I... hmm."

It produced a beautiful business plan. Projected Year 1 loss: $19,000. Year 2 profit: $4,000 on a $100k investment.

The AI had just talked me out of my own startup idea. That's when I realized—AI isn't just a building tool. It's a thinking partner that doesn't care about your feelings.

Week 3: The Pivot That Stuck

"Fine," I told ChatGPT. "You tell ME what to build."

I fed it my background: AWS, GitHub, Customer Success, Cub Scout leader planning our annual campout (currently drowning in spreadsheets and SignUpGenius links).

It suggested five ideas. Number 5 caught my eye: "Outdoor Trip Planning & Community App."

"Surely someone's built this for Scouts?" I asked.

ChatGPT's research: "There's a significant gap in the market for group camping coordination specifically designed for youth organizations."

Three prompts later, I had:

• Market analysis

• Competitive landscape

• Revenue projections

• Even a name: CampSync (later RallyCamp)

But here's where everything shifted. Instead of stopping at the business plan, I kept going:

"Create a product requirements doc for this app" "Now create a visual style guide" "Show me the user flow for trip creation" "Write the API schema"

Each prompt built on the last. I wasn't just brainstorming anymore—I was systematically building a company.

Week 4: From Prompts to Patterns

The mess was real. I had 47 ChatGPT chats in a giant list. Projects in Replit, Cursor, and Lovable. Notes scattered across three apps.

That's when I found the Reddit thread that changed everything for me. Some anonymous genius had posted their prompt sequence for going from idea to PRD to code. The comments were gold:

"I use this flow: Business validation → PRD → API design → Schema → Frontend components" "Pro tip: Make AI write the prompts for the next stage" "I version control my prompts like code"

Wait. Version control... for prompts?

I spent two days organizing. Built templates. Created a system. Suddenly I wasn't just using AI. I was building a machine that built products.

Week 5: The Metamorphosis

This week started different. Monday morning, I:

1. Woke up to Claude Code having completed a complete overhaul of the tests for my authentication system

2. Asked Gemini to help me improve my prompts for the next feature I’m planning to implement

3. Drafted my content strategy to help build some awareness for RallyCamp

4. Built a new feature before lunch

The Uncomfortable Truth

Here's what nobody's talking about: We're speedrunning the entire startup journey. What used to take months now takes weeks. What took weeks now takes hours.

Traditional path: Idea → 6 months → MVP → 12 months → Revenue My path: Idea → 6 hours → Prototype → 5 weeks → MVP launch

This isn't because I'm special. I'm a mediocre coder who bought the right tools at the right time. The game changed, and most people don't know it yet.

In six months, everyone will be "vibecoding." The arbitrage opportunity is right now.

What Actually Happened

I didn't learn to code. I learned to think in systems and let AI handle the implementation. I didn't become technical. I became a non-engineer who can ship production code.

Most importantly: I stopped consuming and started creating. Every day, I wake up with the power to build anything I can describe.

Your Move

I'm documenting everything. Every prompt, every failure, every breakthrough. Not because I'm an expert, but because I'm five weeks ahead of you and the view from here is insane.

Next week: The exact prompt sequences that collapsed six months of work into six weeks. Including the Reddit thread that started it all.

But honestly? You don't need to wait. Open ChatGPT right now and type: "I want to build an app that solves [your actual problem]. Help me create a one-page business plan to validate this idea."

See you on the other side.

This Week's Download: "From Zero to Shipping: My 5-Week Prompt Evolution"

• My first terrible prompts

• The Reddit-inspired templates that changed everything

• Current prompt chains for business → product → code

• What I wish I'd known on Day 1

Drop a comment: What bad startup idea could AI talk you out of in 10 minutes?

P.S. - I've built two other entire apps during these five weeks. Killed them both. When building is this fast, you can afford to fail. More on that next time.