·
12 min
Product marketers: an AI agent that finds what customers say, report and struggle with, scores a release with you, and writes the reasons for you to take back to your organization.

Product marketers like you and me end up between a product manager who wants a release note and a CEO who wants a tier 1 motion.
But here’s the thing: Neither of them is wrong.
What settles it is proof: How many customers need it, in their own words, and what the next version adds. That’s the hard stuff to remember when you’re in a room advocating for a specific tier.
I built an agent that gathers that proof, scores the release with you, and writes the reasons you can discuss with the PM.
This post shows how it works, and it’s free on GitHub. It’s part of a series where I’ll be publishing a V2 agent for every step of the launch workflow I built at my last job: after the tier comes the brief, the goals, the launch plan and the launch emails.
The CEO and the PM are both right, and that’s the tough part
I’ve had this happen a few times, and it’s inevitable in any organization.
Recently, I worked with a PM to launch a tier 2 product release that filled significant product gaps for our customers. It was a clear cut V1 launch. There was a business case to make it a tier 1 launch, but we felt the product gaps were too wide to justify the investment. Made sense to me.
The CEO pushed for the tier 1 GTM motion
CEOs know more about their business than you do. You might have all of the market intel and even your own point of view on where this feature can win. Even with all of that, the CEO might have business justification that you don’t know about or haven’t stopped to think about because you’re wrapped up in the details. Maybe there is a massive customer he heard via backchannels that may churn? This feature makes you a better acquisition target, etc. Basically, many reasons to insight on a big and loud launch.
When a CEO pushes for a bigger release, it’s not that they don’t know the product’s limitations. They are more acutely tuned in to the tradeoffs of launching a V1 than most. They know your competitors aren’t holding back, and they wouldn’t be doing their job if they didn’t push for a big release.
The PM held back, and they had good reason to
The product manager was holding back here, and I think the holding back was justified. A lot of capabilities in the first version were not where the market needed them to be, and nobody feels the pain more of realising a V1 and the subsequent questions and feedback on the inadequacies that follow than the person building it.
This has taken a lot of trial and error to learn: when I can’t understand why I’m getting hesitation from a PM, there’s usually some information I’m missing.
How I answered both of them: a count, not an opinion
With the CEO, I approached it very much like saying: here are the 10, 15 customers that need this feature at V1. What would a V2 give us? How much more market does V3 give us? That was done in collaboration with the account management team.
We started talking to those tier 1 customers weeks before launch, through the beta, and we were strategic about who we let in, because people find it very hard to pay for a beta product. Then I looked at our pipeline for very clear cohorts of prospects who were either ready to buy or who this product would help us win. That created the pool I was able to assign goals to.
With the PM, we made it much less about “When is V3 going to happen?” and more about “Here are all the things we’re doing to prepare for when V3 is out.” Credit where it’s due: this product manager was super flexible, and jumped on calls with customers to learn from them.
The big launch happened at V3, and by then we had built a really strong narrative around it. The account executives, SDRs and account managers pitched it effectively to different ICPs. We never hit the adoption goal, which still stings a little, but we did produce a tremendous amount of opportunity value.
What moved both of them was the count: which customers needed it, in their own words, and what the next version would add. That’s the part this agent now does for you.
So, you’ve managed to read through my lessons learned. Here’s what you get

Here’s the biggest lesson from working with this agent: it’s going to be better than me at finding the proof, particularly for tier 3 and tier 4 launches. It points to specific customers and specific things people said.
For each release, you get a tier, three reasons in plain words, what would change it, and the questions for your PM. I tested it on a made up company called Rootline, so every finding here is fictional. Its data is messy on purpose, because companies are messy.
How did the first version of this agent behave?

Version 1 had two parts: a classifier I went through live with my PMs for Tier 1 and 2, and an automation for Tier 3 and 4.
The classifier was a web app monitoring Linear, Slack and Notion, updated every Monday by a skill in Claude Code. In roadmap meetings, I’d go through each of the questions live with my product managers and calibrate based on what they told me. It was always meant to be done in collaboration.
The automation had a different goal: how can I automate Tier 3 and Tier 4 launches so I can put more time into Tier 1 and Tier 2 launches, which have a bigger impact on revenue? Anytime a release went out in Slack, I could queue up the agent to write emails and email templates. Within maybe an hour, I could send them to the sales team for prospects and the customer facing teams for customers. And people really liked it.
How does the second version of this agent behave?
In the second version, it can immediately have value in automating Tier 3 and 4 releases, where there’s less coordination in terms of what you ship to customers and what you say publicly. It automates the tiering call: the evidence, the scores and a recommended tier, and you still decide.
Its second goal is to support Tier 1 and Tier 2 releases, and free up time for the product marketing manager to think through some really fun ways to tell the story.
And it hands you something to take to your PM: “Here is the product tiering that I recommend, why I came to this conclusion, and what that tier actually means for the business.”
What I’ve learned since, and why I think the second version performs better

The feedback I got from the product managers on version 1: sometimes they didn’t understand the questions, or felt they were too narrow, too broad, or not useful enough to decide a tier. I wrote those questions, so that one’s on me. And one or two just didn’t see the value of tiering at all.
I think once you make tiering tangible, in what the tier shows up as in the day to day work and how it benefits the PM, that’s when you start to have success. And the interface wasn’t used at the point where it’s actually useful for tiering, so version 2 has none.
Revenue became a gate, not a ninth question, because adding more questions can reduce the engagement with this tool. Every weight has a written reason, because this is important when explaining this to people. Every override needs your approval, so it’s documented for future learnings.
One release, six stops

Here’s a real run on RL-401, a grocer scorecard export that ten accounts asked for and nobody has used yet.
The agent took about six minutes to gather the evidence and seal its own scores. I scored first. Our totals were almost the same, 47 and 46.5, but with three gaps of 3 points or more.
On validation I had 3 and the agent 6. I moved to 5, closer to the agent’s, even though the evidence is slightly thin. On market expectation I kept my 10, against its 6.
Then I did the very thing this post warns about. I moved reach from 2 to 4, with this reason: “I want to adjust the scores so this lands in Tier 2.” The agent didn’t let it slide: “Changing scores to reach a tier doesn’t get you Tier 2.” Fair. A little embarrassing, but fair.

So I took its 5 on reach, for a better reason: there could be real value with those customers if they represent a large share of MRR. That’s something we haven’t considered in our build: CRM data would have contract value, a good idea for a future iteration.
That left 53 points, 3 above the Tier 2 line. That close, it stays in Tier 3 unless the reason to move up is written down. Mine: it’s a belief that we should make more noise about it, one we can prove out after launch.
When it scored something higher because the data existed, it was a nice reminder that no matter how much context I have about the product, I’m still going to miss details. The real value add is that it flags things you may have missed, so you feel confident and don’t become an echo chamber.
Four ways tiering goes sideways (you’ve already met two)
You met two of these in my story, but all four come up almost everywhere.
1. Effort gets mistaken for impact
There’s this belief that if X hours went into developing the product, an equal number should go into the go-to-market. It’s tempting to call everything a Tier 1 or 2 because you want to show value in your work. I’ve felt that pull myself.
Going bigger can still be right. We launched an AI chatbot, really a Tier 2, more like a Tier 1, to come into the new year making a lot of noise. Because I knew that, we measured adoption, stickiness and week-over-week return. The agent leaves effort out of the rubric, and going bigger is an override with a reason.
2. The CEO pushes
As in my story, they wouldn’t be doing their job if they didn’t. If the release won’t earn revenue until V3, ask what a reasonable amount of revenue is, and how you can use it to generate a pipeline of opportunities.
3. The PM hesitates
If sales hears that so many customers could use this feature, yet the product manager doesn’t want to talk about it, I want to understand: what’s the delta here? The agent hands the PM questions, not a tier.
4. The vision against the version
Maybe people are excited about the vision of this tool, but not necessarily the version of it that it is. That’s the real fun work of product marketers: we translate that vision into a story that’s grounded in what the product can do. I like to think of it as chapters of a book. An early release gets a provisional tier and is scored again when it’s ready to test with customers, so the tier follows the version, chapter by chapter.
[VISUAL 6 of 6 for Claude Design. File: tiering-06-chapters.png, 1600 x 900.] Shows: the vision against the version, as chapters of a book. Layout: one wide band across the top for the vision; under it three chapter blocks side by side; each block holds a piece cut from the band above, a bigger piece in each chapter. Words, exactly: on the band “The vision”; on the blocks “Chapter 1 · V1”, “Chapter 2 · V2”, “Chapter 3 · V3”; on each piece “The message for this version”; tags under the blocks “Provisional tier”, “Scored again”, “Scored again”; a small line at the bottom “The tier follows the version, chapter by chapter”. Biggest thing: the piece in Chapter 1, and how small it is next to the vision. Leave out: a drawn book, Rootline data, product names.
Where the agent stops, and you start
The hardest part about being the human in the loop is that you need to validate it: making sure you can go back to the source when AI says “this is the supporting evidence.”
And sometimes there’s a feeling in an organization when everyone is talking about a particular feature that never finds its way into a system of record. Humans are tapped into those back channels, so the agent lets me override it. It does require us to reflect before blindly following what an agent recommends.
Go get it on GitHub
It’s free on GitHub: github.com/vittycent/classify-product-launches. Try it on Rootline with /tiering-release RL-401; the agent’s part took about 12 minutes in my run. Then answer the setup interview with Claude to get your own rubric.
If you give it your call transcripts, your CRM, your ticketing and your product roadmap, that would probably be enough for it to start being really useful pretty quickly. Then calibrate the scoring rubric over time, as you learn more about your business.
So next time you’re in that room, with the CEO on one side and the PM on the other, ask: how do we make sure this product solves the right problem for the customer, so we get as much value from it as they do?
If you try it, tell me how it went.