👋 Hi, it’s Kyle and welcome to Growth Unhinged, my weekly newsletter exploring the hidden playbooks behind the fastest-growing startups.

Readers know I love sharing practical AI GTM workflows. But most of these have been top-of-funnel use cases like smarter outbound plays or inbound lead qualifying. Today I’m excited to bring you the perspective of Dee Kapila, the senior director of customer success at Fin.

Dee’s entire team has become AI-first in 2026. She walks through how she uses Claude Code as a GTM operator and her reflections on how GTM leaders can enable AI adoption. Keep reading to the end for an AI workflow that finally gave Dee her Sundays back and how to copy it yourself.

At the start of this calendar year, Fin's data engineering team provided unfettered access to a data layer they had built on top of Anthropic's Claude. That's right. No limits, no token rations, no express mandate from on high.

Claude4Data, or C4D as we all refer to it internally, was a simplified, pre-packaged installation the engineering team felt would give the power of Claude to non-technical teams who, in the words of my data engineering colleague Andrii Yakovenko, "need to build things just as urgently as engineers do." The engineering team packaged C4D for quick installation and rolled it out without much fanfare. Six months later, I can't imagine going back to doing things the way I was before.

In the time it took to write this piece, our customer-focused teams – customer success (high touch, scaled, and digital), CX Programs (customer education, community etc), Services, Solutions and Ops – started pursuing more sophisticated use cases and churning out even more creative builds. By the time you read this piece, we will have leapt forward even more.

Here is a rundown of how we enabled the team, a few examples of what we’ve built, and a deep dive into how I automated a task that previously took me two hours every Sunday.

I first invited Andrii to do a two hour master class and suggested the agenda shared below. We added some projects from across Fin’s R&D organization and some from GTM that the team could look at for inspiration ahead of the class. Then we nailed down pre-reqs the team would need, set up a Slack channel for Q&A, and scheduled the master class, getting it on the team’s calendars in advance, ensuring no all hands etc would interfere with the 2 hour block. Easy!

From there I asked my team to complete the following pre-reqs, which shouldn’t take you long to set up on the backend, especially if your org is already supportive of AI upskilling. These pre-reqs took the team one hour, tops.

This led to our two hour master class on becoming AI-first. Here’s the actual Google Doc with the agenda Andrii and I aligned on for the initial master class.

I kicked off the class with a brief overview of the power of these tools, demos of my first builds, inspiration from across the org and then handed it over to professor Andrii. We spent 30-40 minutes on the session content before getting into the hands-on/building part.

My biggest piece of advice as you set up something similar for your team is spend the majority of the time hands-on! It's crucial. By the end of the session, everyone on the team had built something. We had a few things to troubleshoot async after (yay aforementioned Slack channel), but for the most part setup was quick, time-to-first-product was fast, and the team was able to branch out to multiple use cases on their own after this. Two weeks later Andrii hosted office hours (I recommend keeping an office hours session at 1 hour and offering 2 or more to hit all your time zones) where people could drop in and ask him questions or troubleshoot any blockers they were running into (ie. an MCP connector not working). By this point, we had someone on the team who had built and published 100 things on the company Claude for Data (C4D) repository. 100!

Of course a lot of this was exploratory, testing, trying, and not all builds were adopted, but success at this stage is absolutely quantity. Get familiar with the tools, what they can do, and how far you can go. Seeing my team be a mini-Claude code factory was enthralling.

Andrii and I plan refresher sessions every so often, just for my team. This is on top of the high level enablement Anthropic and Fin already provide. It speeds up innovation when you get to building in your own domain so definitely supplement scaled education provided by Anthropic and your org with your own team-specific builds so you can zero-in on your own problems and needs.

I'd describe the team’s enablement journey in the following three phases though they did not feel this clean or linear in the moment: Initial adoption, Maturity, Optimization.

The success org has published thousands of builds across our C4D repository. The team has built apps, skills, agents, workflows, automations. I’d say the main batches of builds fall across three categories,(1) data, reporting and insights, (2) customer-facing solutions, and (3) operations.

A few examples:

One of our CSMs built an attribution model for our scaled workshops, showcasing impact over time on each accounts’ instance after participating. We were overjoyed because it is so hard to build attribution models in GTM outside of marketing. You don’t typically have the army of analysts marketing teams have, modeling is more complex in terms of inputs and the diversity of work a CSM executes, and so on.

Isolating workshops as a use case, then focusing on a clear time horizon and a shortlist of metrics was the key here. Then, we validated the approach with our data team, who were eventually able to run a cohort analysis further showcasing how impactful the workshops were against control groups that didn’t attend them. This helped us understand that we were underestimating the impact of the workshops and, along with customer feedback to validate the demand, we were able to increase the number of offerings.

One CSM built a simple interactive heat map app breaking down where the customers in their book of business were located so that they could select the best locations for our in-person workshops. What I love the most about both of these examples is how quickly the CSMs went from asking a question to generating an app that helped them find an answer, and immediately executed a decision or next step. Powerful insights and immediate utility are a winning combo.

Our customer education team built a certification program with hands-on labs that help learners test their Fin and AI skills in playground style environments, guiding them along the way. One of our multimedia designers also built custom teleprompting software in Claude and saved the team the cost of several licenses for software that was best in class but still didn’t meet our edu team’s specific needs. It was much more user friendly, particularly when we invited customers on set to share their learnings on Fin Academy.

One of our CSMs has built skills that autopopulate requests for him to approve before official submission in Salesforce. He created a feature request skill that extracts structured feature requests from Gong transcripts, Slack threads, support cases, emails and meeting notes. Raw conversations that go straight into submission-ready formats have saved him a ton of time and shortened timelines. He’s also created engagement request skills that help speed up the process of requesting other GTM resources like solutions architects, trainers or services leads.

My biggest Claude Code use cases are bucketed across three main categories: inspecting my business, running my business, and prototyping. A few examples from my world:

I start my week in my personal cockpit. This is a simple dashboard that gives me a pacing update across all our customer segments so I can see how my team is tracking against growth targets and where we are with accounts up for renewal this quarter. I have a section that flags risks and aggregates the latest sales/CSM comments on mitigation, and a section that pulls status updates from my CX programs teams who manage their workstreams in Coda. By the time I finish my morning coffee, I know what needs my support or attention, and can jump in to action top priorities.

I’m currently building a customer pulse section that summarizes product feedback themes, program sentiment, interesting insights from Gong calls, Slack account channels, etc. Building this as an early adopter got me requesting MCPs and features from our data engineering team that are in heavy use today across the org and I gotta say that is some real street cred, thankyouverymuch.

In addition to this report, I run my entire weekly ops review through an app I built in Claude. The app helps me run offense on the biggest growth vectors in our segment, helps us uncover low performing cohorts (aka Lowhorts) and also helps us assess which areas to focus more resources in. You can learn more about this review here. All these result in clear next steps, more targeted conversations, and faster execution.

My team manages platforms like our community forum, Fin Academy, and more. Whenever we are building a customer-facing asset, webpage, or app, we generate prototypes in Claude to review and discuss. It's so much easier to communicate and co-build when you’ve got a high fidelity visual starting point. I often share my vision with my team or cross-functional partners this way, and I can communicate feedback more accurately this way as well. With Claude Design, generating assets in accordance with Fin's brand is fast and high quality so we have reduced the number of small, irritating requests we may have for our brand team.

Eager to give it a go? Here is how I built a simple weekly narrative update that helped me reclaim Sunday evenings by automating a two-hour weekly reporting task.

Every Sunday evening I used to spend about two hours pulling numbers fromSnowflake and Tableau, doing mental math on pacing, and typing up a narrative Slack update for my team. It wasn't hard work — but it was repetitive, error-prone, and it drained the time I could have spent actually thinking about what the numbers meant or focusing on something more high impact for Monday morning business reviews.

So the goal was a self-contained HTML page I could publish internally, plus a preformatted Slack summary I could paste into our team channel with one click.

No other MCPs were needed. The HTML rendering is done entirely by Claude Code
writing a single index.html file with embedded CSS — no build step, no
JavaScript framework, no chart library.

The first version was produced using the following rough prompt:

That's it. One prompt, iterated over a couple of sessions to get the formatting and narrative tone right.

The workings.md file that Claude generated alongside the report captured all the sourcing logic and assumptions so I could reproduce it later without re-explaining everything. I'm on v67 of this now and have used it for over three quarters straight. Below is a prototype that illustrates the structure of the simple initial app.

Be specific about your tables upfront. Don't say "pull resolution data". Instead say which table, which columns, which filters. Claude can explore schemas, but you'll get to a working report faster if you already know your data model.

Include the targets in the prompt. My targets aren't in Snowflake. Rather than building a separate config file, I just state them directly. They only change at quarter boundaries, so the maintenance cost is near zero.

Your prompt should ask Claude to "write a narrative paragraph covering..." <— this is what turns a query result into something readable. Claude computes the pacing math (QTD / target, days remaining, forecast) and writes it in plain English with color-coded status indicators.

Claude generated a workings.md alongside the report that documents every data source, filter, assumption, and known gotcha. When I come back next week (or next quarter), I don't have to reverse-engineer anything. Managers, I suggest that you look at the workings files of important reports your team shares with you so you can coach them. Provenance matters across the board!! Ancient kingdoms have been brought down because somebody was crafty in a prompt and used the wrong data source or tried to manipulate outcomes via their prompt.

The "Copy for Slack" button generates a pre-formatted rich-text summary that pastes cleanly into Slack with bold text and status emoji intact. One click, paste, done. No formatting, emoji adding etc. I wanted the whole painstaking thing to be 5 minutes tops. The Slack message is exec-friendly with just the headlines and key trends. The full HTML gets published to our internal report gallery for anyone who wants the detailed tables. To keep things mobile friendly for folks on the go, attach a pdf or screenshot of the full page.

You don't need my exact tables or team structure. The pattern is:

BTW - I had Claude remind me of my initial prompt and number of iterations so I could detail the above section.

My first app was hardcoded. I had to prompt Claude to update it. It started taking longer as the report grew. I chunked the report into tabs and asked for more frequent updates to the exec tab. Then I outgrew the above.

I went to my data team and they helped me figure out which elements of the report I could move away from a hard-coded model, so that the data just refreshed as the page was refreshed. This minimizes the amount of botsitting you need to do for hard refreshes. I scheduled the full update to a weekly Monday morning 7am refresh. Donezo!!

The report will continue to evolve — I have a backlog I keep on my to-do list app and whenever I can, I add a feature, clean something up, mess with the design, bring in new data etc. I’ve also asked it to start generating slides for QBRs. In full transparency, I change the output completely, but I do this because I find that I am a better editor than a first draft generator, and because the app reminds me of changes over time in the numbers which make for interesting QBR fodder.

To drive meaningful change, you have to have skin in the game, lead from the front, and authentically push and support your team. Being a player/coach here is valuable and you'll only be a good player and good coach if you build yourself. Your mindset has to shift with AI. You need to be okay struggling, feeling stupid, and pushing through until you have an artifact or have reached your desired output. That is what success feels like with this stuff.

It's not magic, it is leverage. But you need to invest time and for every 20-25 build experiments you'll have one major breakthrough. That's the key with the "player" part. Doing the thing but understanding the overall process. Then you can do the coach part: what's working and what's not, coach and be coached, understand how your management layer is adopting and transforming their teams and workflows, and be genuinely curious what everyone in your orbit (direct reporting line, peers, C-Suite, customers) thinks are good vs bad use cases and why. You're not going to understand what to agentify if you aren't in the muck yourself.

Now let’s talk about being a good coach. You're building, you're looking at others' builds. You need to develop a form of editorial taste for AI. The only way to do this is to wade through the possibilities to understand what will drive value today, what is vaporware, and what has future promise.

Think like a writer or a film critic here. Film critics watch film after film and can break down genres, styles, tech specs, and every detail of a film. In Sol Stein's book Stein on Writing, Stein discusses seminars at Columbia University dedicated to close examination of single works and intentionally sitting through badly written plays to "witness coughing and squirming in the audience, to have ears up like a rabbit to catch what didn't work, to observe how little tolerance an audience has for a mishap, ten seconds of boredom breaking an hour-long spell." ←develop this for AI.

Regularly inspect both inputs and outputs. Look at workings files and trace provenance, build off of others' work, iterate on your work and look at changelogs where they are available. When you give feedback, ensure it is grounded in solving real problems. Be constructive and consider if something is AI for AI's sake or if it adds real value.

Your initial enablement is crucial to get started, but its also a great jumping off point for ongoing maturity. Peer2Peer communities speed up innovation and help each other troubleshoot and co-own apps together. Think about other opportunities to spark ideas and reinforce the AI-first culture that fit into the rhythm of your business.

For example, at Fin, we built mini hackathons, do regular demos of what our team has built at all hands and I ask my peers to come chat with and present to my team on special topics at our team meetings. I've got an always-on ask out to my frequent collaborator and partner in crime, Fin's Head of Research, Dr. Caitlin McCurrie to talk us through research, validation and data handling topics and next I'll ping my buddy and Kesha Mykhailov, Fin's Principal Engineer, to come talk about how observability teams use C4D. Andrii and I also connect periodically to discuss how to further support and enable the team.

Broad exposure to uses of AI and frequent chats about where you're stuck are the magic of this short phase of early AI adoption and make no mistake we are still super early. Share your mistakes, laugh at yourself – make it okay for people to fail. The world is in collective early build and we must try to trace its contours. The only way to do that is to encourage building and broad exposure to what AI can do in different domains.

Unfettered access is something I don't take for granted. Most orgs I know are starting the process with limits. But even if you're fortunate like we have been at Fin, your CFO will come for you eventually. But that's also a good sign something has cemented and taken hold. Fin has a Blueprint to help you get started, with a whole section on building an AI business case for support.

Today, our Customer Experience org (internally known as Solutions, Deployment & Success, or SDS), does everything from internal "run the business" use cases (operational reviews, forecasting, attribution modeling, voice of the customer analysis and actioning, Feature requests etc.) to external use cases (research and prep, interactive apps/presentations, success planning, feature request submission) to all the personal activities that drained our time (personal cockpits, reporting, billable hour timesheet tracking and submission, action items, call recaps, feedback synthesis).

On top of this we are building our own internal processes and apps that have already begun to embed these processes in our ways of working. Here are four such examples:

From first demo to long-term success, every team is supercharged by AI. At every stage, SDS teammates draw on that same system for the AI tools they need to do the job at speed, turning work that used to take days into hours. We'll build a single AI-native operating layer and one customer record, so each stage builds directly on the last instead of restarting inside its own team's silo. That shared foundation is what lets us move at exceptional speed, using AI to accelerate a customer's time to value at every step.

Our success organization has an AI Governance committee, led by one of our CSM leaders, Sam Wong. The group exists to turn AI innovation into shared leverage. It ensures the success org maintains a high bar, avoids duplicative builds, and has a trusted library of skills, standardized workflows, and continually maintains and updates this. The governance committee follows 4-week build cycles which include milestones like skill reviews, roadmapping and adoption reporting.

At Fin, digital success is both a segment and a strategy. It is the foundation for all customer success, extends across all segments, and covers pre and post sales, The foundational experience is a happy path that takes customers from launch, to scale and success, with the Fin flywheel driving analysis, training, testing and deployment of service agent.

If during this happy path customers fall off course, one of our Success Signals is triggered and launches a follow-up digital play to get them back on course. An example of a signal during the launch phase is if messenger is not set up by day 7. If the digital play doesn't work, or if the signal is risky enough, we pull in a field team member to intervene. That could be a CSM, or someone else on our GTM customer-facing team.

Conversely, a customer could indicate readiness to mature or expand. Success Signals trigger follow-ups here as well. A simple example here is if a customer wants to add on our Pro pack, which includes Operator (my personal favorite Fin product). Signals would fire off an educational experience helping them discover Operator and apply it across a specific use case.

Ground Truth codifies definitions of data maintained and updated by our Research and Data team (RAD). This ensures that when we ask a data question, the agent searched this semantic layer first, accessing the correct definition, pulling the right tables, filter, SQL patterns etc. It helps us avoid known traps before touching the data warehouse. You can read more here.

It's an exciting new era and its not at all too late to get started. This is a practitioner's era and our roles are ours to reshape. Join me and lets build something cool.