Skip to content

Why Card Products Can’t Ship Like AI Products - ProductFTW #80

And What PMs Should Do About It

🙏
ProductFTW is made possible in part by our paid subscribers. If you’re one of them, thank you. If you’re not, please consider supporting ProductFTW (who knows, maybe you can expense it!)

My friend sent me a link to Lenny Rachitsky's podcast with Cat Wu, who leads product for Claude Code, and the conversation stuck with me for two reasons. First, I kept thinking about whether the way AI teams ship products translates to card products. Second, I kept coming back to this idea of “product taste” and why it is so hard to define.

A quick summary of the conversation: Anthropic has reduced its shipping cadence from months to weeks to days, and that is redefining what they look for in PMs. They want people who can see problems early, move quickly, and build even when the product is not fully there yet. The emphasis is less on perfect execution and more on judgment. Can you pick the right problems, iterate fast, and know what matters as the technology catches up?

While listening, I kept thinking: Can card products actually move at that pace, and can they afford to trade off perfection?

Image of a slide comparing what is it like to ship a card product vs an AI product including timeline, key steps, systems involved, customer experience, and change cycles.
Asked AI to make a photo about why card products can’t ship like AI products… and it shipped in 12 seconds. 💀

Where this breaks in cards

In AI, there is a growing acceptance that you can ship before everything is fully polished. You can build products that do not yet fully work and iterate as the technology improves.

In card products, I think that tradeoff is more nuanced.

Parts of that model translate well. Engineers can move faster with AI. Problem identification is faster. User feedback loops are faster. Alignment across product and engineering can be faster. A lot of the operational overhead, such as writing tickets or summarizing research, can be streamlined.

You can absolutely move faster and accept imperfection in certain areas. Performance might not be perfect. Edge cases might not all be covered. The UI might not be fully polished. Those are acceptable trade-offs if they do not impact trust or violate regulations.

What you cannot risk is correctness and clarity. Core flows need to work. A user needs to be able to repay their card. Interest needs to be calculated correctly. Disclosures need to be clear and accurate. Anything that touches money movement, fairness, or user understanding has a much lower tolerance for imperfection.

So the question is not whether cards can move fast. It is where you can afford to be imperfect and where you cannot.

The Compliance Bottleneck

📝
Quick disclaimer before we go further: I am not in compliance. This is coming from building fintech products and learning where things get flagged, not from writing the rules myself. This is about product decisions and tradeoffs. This is not legal advice.

In fintech, especially in card programs, most meaningful changes must pass through internal controls and external oversight before going live. If you are changing something users actually feel, there is a good chance it needs review. That could be internal compliance, risk, or approval by the sponsor bank or partner. Even small changes can raise questions about language, disclosures, fairness, or user impact. Someone has to read or interact with what you plan to ship and decide whether it introduces risk or misleads the user.

There are exceptions. If you are adding something adjacent to the core financial product, you can often move quickly. A new feature that sits alongside the card or account experience is usually cleaner. Once you are inside core flows, the constraints tighten quickly.

These constraints create a structural bottleneck. Teams can speed up everything leading up to a release, but the final steps still depend on human review. I do not think that will disappear anytime soon. These are decisions that require interpretation and judgment. AI will help, but, in my experience, full automation feels far off.

The result is a growing mismatch. Product and engineering can generate more ideas, test more concepts, and prepare more changes than ever before. Compliance and partner review cannot scale at the same rate. The backlog builds and the system slows down at the exact point where speed matters most.

What do you do about it?

One shift is toward fewer, higher-confidence bets. If review is the constraint, it does not make sense to flood the system with low-signal ideas. The bar for what gets pushed forward should be higher, not lower.

Another shift is investing more in pre-alignment. The fastest teams in fintech are not skipping compliance. They are bringing compliance in earlier. They are shaping ideas with the constraints in mind, rather than treating review as a final step. This reduces rework and shortens the path to approval.

This is also where product taste becomes more important, not less.

What product taste actually means in fintech

Back to Lenny’s podcast: Cat talked about product taste in a way that is worth unpacking. At a high level, “product taste” is knowing what the right user experience should be, what feels most intuitive and delightful, and how to sort through a long list of requests to decide what is actually worth building. It is also about seeing patterns in how people use or even abuse your product today, and applying that information to shape what the product should become over time.

That framing resonated with me because it matches what I have seen in strong PMs. They can look at a messy set of inputs and quickly identify what matters. They make good calls on what to prioritize, how to build it, and how it should feel for the user. They are not just executing.

In fintech, I think product taste has an additional dimension.

Good fintech PMs don’t just know about what is best for the user. They also understand regulatory boundaries and decide whether a bet is worth taking within those constraints. Good taste includes knowing when something is likely to get flagged, when it is worth pushing anyway, and when to reframe the solution entirely so the product can actually ship.

These skills are hard to teach and even harder to measure. It feels less like a checklist and more like a compass. When everything is ambiguous, product taste points you toward the right call.

One thing I found interesting is that teams like Claude Code are not framing AI as a way to reduce headcount. They are using it to raise the bar.

Even as AI automates more of the day-to-day work, product does not become less important. It becomes more important. You still need to define who you are building for, which problem actually matters, and which highest-value use cases are. AI can help you execute faster, but it does not decide what is worth building.

If anything, the role shifts further toward judgment. When the cost of building goes down, the cost of building the wrong thing goes up. That is where strong product thinking shows up.

Product taste is about PMs making better decisions in a world where you can move faster than ever.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Fintech Product Management Field Guide — ProductFTW's writing on what makes building card, payment, and banking products different.

Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]
Subscribe
Start typing to search...