Description

A focused course, tailored for you

Payments Product Ops Discipline for Brazilian Neobanks

A working operations spine for a payments product team running PIX, card rails, and Bacen reporting at scale.

Your payments product team has a working backlog, a working release process, and a working dashboard. What it does not have is a working operations spine. The PIX dispute queue lives in Slack, the chargeback runbook lives in three different Notion pages, the Bacen reporting cadence lives in one analyst's head, and the postmortem from the last incident is a comment thread nobody closed.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Lead Product Operations at a Brazilian neobank is one of the hardest payments product jobs in the market right now. You sit between product managers who want to ship the next rail, engineers who want a clean spec, risk and compliance teams who want every change documented for Bacen, and customer operations teams who absorb the variance when any of the above slips. The product is real-time. The regulator clock is real-time. The customer's tolerance for a stuck transfer is measured in minutes. None of the tooling on the market was designed for that combination. The result is that product operations becomes a series of one-off rescues: a dispute queue that needs a runbook this week, a chargeback flow that needs a working SLA next week, a Bacen reporting deadline that needs a clean evidence trail by month-end. Each rescue works once. None of them compose into a system. The cost is not visible on any dashboard, but it shows up as senior engineers spending their afternoon in Slack instead of writing code, risk analysts re-deriving the same numbers four times a quarter, and product managers learning a new operations gap every release. This course is the operations spine for that job: the artefacts, the cadences, the operating model between functions, and the runbook structure that holds when a rail changes.

What you walk away with

A documented operating model between product, engineering, risk, and customer operations that survives a rail change.
A working dispute and chargeback runbook structure that holds for PIX, card rails, and cross-border flows.
A Bacen reporting cadence with the evidence trail an auditor can follow without a guided tour.
A product operations dashboard that names the metrics your function actually owns, not the ones inherited from product or engineering.
A hiring and onboarding plan for the next two product operations analysts you bring in.

The 12 modules

Module 1. What product operations owns inside a payments product

The first module draws the line. Product owns the roadmap, engineering owns the platform, risk owns the policy. Product operations owns the operating model that lets those three coexist under Bacen oversight. This module names the artefacts that belong to product operations specifically, the artefacts that belong to neighbouring functions, and the conversations where the boundaries get blurred. It ends with a one-page charter you can publish inside your own team.

Module 2. The PIX dispute queue as an operations problem

PIX disputes are a regulatory clock plus a customer-experience clock plus an engineering-bandwidth clock. None of the off-the-shelf ticketing tools were built for that combination. This module builds the queue structure from first principles. Who triages, who escalates, who closes, what evidence is captured at each step, what the SLA looks like in numbers you can defend to Bacen, and how the queue degrades gracefully when volume spikes around a payroll cycle or a holiday.

Module 3. Card rail chargebacks and the operations playbook that survives a scheme change

Mastercard and Visa change chargeback rules on their own cadence. The operations runbook needs to absorb those changes without rewriting itself every quarter. This module covers the chargeback lifecycle, the evidence capture standard, the reason-code mapping between your internal taxonomy and the scheme taxonomy, the second-presentment workflow, and the recovery-rate metrics product operations should own rather than inherit from finance.

Module 4. Bacen reporting cadences and the evidence trail

Bacen reporting is not a single deadline. It is a layered set of cadences: real-time obligations, monthly returns, incident reporting, and the ad-hoc requests that arrive without notice. This module maps the cadence onto a product operations calendar, names the evidence each cadence consumes, and builds the audit trail in a form that an external auditor can follow without you sitting next to them. The output is a reporting registry you can hand to a new joiner on day three.

Module 5. The operating model between product, engineering, risk, and customer operations

Most payments product issues are not single-function issues. They are operating-model issues that surface in one function because the others do not have anywhere else to put them. This module builds the cross-function operating model: the standing forums, the decision rights, the escalation paths, and the artefacts that flow between functions. It is opinionated about which decisions belong in product review, which in operations review, and which in a joint forum with risk.

Module 6. Runbook structure for a product whose rails keep changing

A runbook that assumes the rail is stable will be wrong the next time the rail changes. This module builds a runbook structure that separates what is true about the product from what is true about the rail. The rail-specific layer is updatable in a contained way, the product-specific layer is the operations spine, and the customer-facing layer is the contract you make with customer operations. The module ships with a template for each layer.

Module 7. Incident response inside a real-time payments product

Incidents in a real-time payments product are not webops incidents. They are regulatory incidents, customer-experience incidents, and operating-model incidents at once. This module builds the incident response structure that holds for that combination: the first-responder role, the communication tree to Bacen and to customers, the rollback decisions that belong to product operations rather than to engineering, and the postmortem format that produces structural fixes rather than action items nobody closes.

Module 8. The product operations dashboard nobody else can build

Product has a roadmap dashboard. Engineering has a reliability dashboard. Risk has a control dashboard. Product operations needs its own, naming the metrics that no other function tracks: queue health, evidence completeness, runbook freshness, cross-function handoff latency, and the cycle time from a rail change to a runbook update. This module builds that dashboard with metric definitions, owners, and refresh cadences.

Module 9. Customer operations as a downstream consumer of product operations

Every gap in product operations becomes a ticket queue in customer operations. This module builds the contract between the two functions: the artefacts customer operations consumes from product operations, the feedback loop that surfaces operating-model gaps before they become tickets, and the joint metric set that aligns the two functions on the same outcome. It is the difference between customer operations as a complaint channel and customer operations as a signal source.

Module 10. Hiring and onboarding the next product operations analyst

Product operations does not scale by adding generalists. It scales by adding analysts who can hold a queue, a runbook, and a regulator obligation in their head at the same time. This module covers the role definition, the interview structure that selects for the right pattern of judgement, the onboarding plan that gets a new analyst productive in four weeks rather than four months, and the team structure that lets the function grow without rebuilding itself.

Module 11. Working with risk and compliance without becoming a second risk function

Product operations is adjacent to risk and compliance, and the worst outcome is that the two functions duplicate each other. This module names the line. Risk owns policy. Compliance owns adherence. Product operations owns the operating model that produces the evidence. The module builds the standing forum, the artefact handoffs, and the escalation path that keeps the three functions distinct and complementary rather than redundant.

Module 12. The 90-day rebuild plan for a product operations function that has been patched too many times

Most product operations functions in Brazilian fintech today are the accumulation of one-off rescues. This module is the rebuild plan. Week by week, what to inventory, what to rewrite, what to retire, what to hand back to product or engineering, and what to keep as the operations spine. It ends with a 90-day plan you can publish inside your own team and a checkpoint structure for the executive sponsor.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

The PIX dispute queue currently triaged in Slack: modules 2, 7, and 9 rebuild it as a working operations queue with a defensible SLA.

The Bacen reporting cadence held in one analyst's head: modules 4 and 11 turn it into a registry with an evidence trail an auditor can walk.

The chargeback flow that breaks every time a card scheme updates its rules: module 3 builds the rail-agnostic runbook layer.

The next two product operations analysts you need to hire: module 10 is the role definition, interview structure, and onboarding plan.

What you get with this course

Twelve written modules in the Art of Service learning environment.
Downloadable templates for every module: the operations charter, the queue structure, the runbook layers, the Bacen reporting registry, the product operations dashboard spec, the hiring scorecard, the 90-day rebuild plan.
Worked examples drawn from real Brazilian neobank product operations situations, anonymised.
A hand-built implementation playbook generated against your specific product surface, delivered alongside course access.
30-day money-back guarantee.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours of purchase, your account in the learning environment is provisioned.

The hand-built implementation playbook for your specific product surface is delivered alongside the course access.

All twelve modules and templates are available immediately. The course is self-paced.

The 30-day money-back window starts on the day of access.

Before and after

Before

Product operations runs as a series of one-off rescues. The PIX dispute queue lives in Slack, the chargeback runbook lives in three different Notion pages, the Bacen reporting cadence lives in one analyst's head, and the postmortem from the last incident is a Google Doc with unresolved comments. Senior engineers spend their afternoons in Slack instead of writing code, and every new joiner learns the function by absorbing tribal knowledge for three months.

After

Product operations runs as a documented spine. The dispute queue has a structure and an SLA you can defend to Bacen. The chargeback runbook separates the rail-specific layer from the product-specific layer. The Bacen reporting cadence lives in a registry an external auditor can follow. The operating model between product, engineering, risk, and customer operations is on one page. A new analyst is productive in four weeks. The senior engineering team is back in code.

What happens if you do not address this

The cost of leaving product operations as a series of patches is not visible on any dashboard. It shows up as engineers in Slack instead of code, as risk analysts re-deriving the same numbers four times a quarter, as customer operations absorbing variance that should never have reached them, and as product launches that slip because nobody owned the operating model question. The hidden cost compounds quietly until a Bacen finding, a PIX outage, or a scheme audit forces the rebuild under deadline pressure. Doing the rebuild now, on your own cadence, is the cheaper path.

Who it is for

You lead product operations for a payments product at a Brazilian neobank or large fintech. You sit between product, engineering, risk, compliance, and customer operations. You are accountable for the operating model that lets a payments product ship safely under Bacen oversight, not just for one launch but for the cadence of launches that follows. You have been doing this long enough to know that the bottleneck is not tooling. The bottleneck is the discipline of the operations layer, and you want a course that respects that.

Who this is NOT for. This is not for product managers writing their first PRD, not for engineering managers running platform reliability, and not for risk officers writing Bacen policy. It is specifically for the product operations function that has to make all three of those work together inside a payments product.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. About 14 to 18 hours of reading across the twelve modules, plus the time you choose to spend adapting the downloadable templates to your specific product surface. Most buyers complete the reading inside two weeks alongside their day job.

Why $199 is the right number

The alternative is the path most product operations functions are already on: piece together fragments from generic product management courses, generic ops-leadership content, and the Bacen circulars themselves. That path works for the first product launch and stops working the moment you have two rails, three reporting cadences, and a customer operations team asking for a contract. This course is the operations spine built specifically for that next stage, in the Brazilian payments context, with the per-buyer implementation playbook that adapts it to your actual product surface.

FAQ

Is this course specific to Brazil or generic payments product operations?

It is specifically built for the Brazilian payments product context. The PIX module, the Bacen reporting module, and the operating-model module are written for a neobank or fintech operating under Bacen oversight. The card rail and incident response modules are broadly applicable, but the examples are drawn from the Brazilian market.

Does the course assume my product is already live?

Yes. The course is for product operations functions inside a live payments product. If you are pre-launch, the runbook and operating-model material is still useful but the chargeback, dispute, and reporting modules will run ahead of where you need to be.

What does the hand-built implementation playbook actually contain?

It is a per-buyer document built against your specific product surface. It takes the templates from the course and adapts them to the rails you actually run, the reporting cadences you actually owe, and the team shape you actually have. It is delivered alongside course access.

Is there a refund if it does not fit?

Yes. 30-day money-back from the date of access.

How is the course delivered?

As written modules inside the Art of Service learning environment, with downloadable templates and worked examples, plus the hand-built implementation playbook delivered alongside course access.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.