Asianet News: AI workflows for an eight-language newsroom

The newsroom and the job

From June 2022 to June 2025 I was Senior Product Manager at Asianet News Media Network, and I solely owned the product roadmap across its eight languages. The roadmap’s job was content expansion, and the thing in the way was the newsroom’s own tooling. Each language had a desk, and every desk worked in a legacy CMS where a story’s headline, slug, tags, SEO metadata and social card were made by hand.

That puts a hard ceiling on a newsroom. A desk publishes as much as its editors can produce, and the only lever on output is more people.

Who I was building for

My primary users were desk editors in eight languages. Each of them answered for what went out under the masthead in their language. They had good reason to distrust a tool that could put words in their mouth, and no patience for one that added steps on a breaking story. A feature that made review slower would lose, however clever it was.

The second user was the reader, and most readers reached us through Google Search and Discover. That fact came back when we chose a model vendor.

Sequencing: the CMS first

The obvious roadmap was to bolt AI features onto the old system and show early wins. I sequenced it the other way round. The team rebuilt the CMS from zero to one first, and the AI workflows went on top of the new foundation.

My reasoning was about placement. An AI suggestion helps only if it shows up in the field the editor is already looking at, at the moment they make that call. Retrofitting that into the legacy screens would have meant working around them on every feature. Rebuilding first gave each AI capability a natural home in the editor’s flow, and it left a foundation for later products.

Where AI stops

On the new CMS, the team shipped four AI workflows:

Quick drafts grounded in source content from partner properties, so the model transformed an existing reference instead of composing from nothing.
Cross-language translation, so a story that had already cleared one desk could seed drafts for the others.
Suggestions for titles, slugs, tags and SEO metadata.
Automated social creatives.

The line I held was the publish decision. Every AI-assisted draft was approved by that language’s editor before publishing, with no exceptions and no end date. That rule settled the trust question on day one, because nothing reached readers without sign-off from the person accountable for that language. It also shaped what we built. Since an editor reviewed everything, AI output had to be cheap to review, which pushed us toward grounded drafts and single fields an editor could accept or replace at a glance. Adoption followed desk by desk.

I’ve written up the design logic behind those boundaries in When constrained generation beats open generation, and why the approver had to be a native editor of that language in Language is product, not localization.

Choosing Gemini

We ran the newsroom capabilities on the Google Gemini API, for two reasons. The first was cloud-partnership economics: our infrastructure already ran on Google Cloud, so staying on one stack made commercial sense. The second was alignment with where our traffic came from. A newsroom that depends on Search and Discover for most of its readers has a reason to build close to that ecosystem.

Single-vendor dependence is a real cost. For a publisher whose distribution already ran through Google, I’d make the same call again.

Formats, KPIs and leadership

Alongside the newsroom tooling, I launched content-format products 0→1, increasing traffic 30% and contributing 6% incremental ad revenue.

I also partnered with leadership on the product vision, the KPIs and the roadmap. A KPI is only useful if every language counts it the same way, so I simplified data tracking across the organisation as part of the same work.

The debate platform I advised against funding

One project ended with me recommending we stop. We built a working AI real-time avatar debate platform for a Google editorial grant bid. The grant was not awarded, which left a plain choice between funding it ourselves and walking away.

I quantified the real-time voice and avatar compute economics and recommended against self-funding it. Rendering avatars and syncing voice in real time is expensive, and that cost recurs every time someone uses the product. Set against that, the return didn’t hold up. The platform never launched to users, and I don’t describe it as a launch. It’s here because shelving a working prototype on unit economics is a decision I’d make again.

Outcomes

Editorial output tripled over the period, counted as published pieces across formats (articles, web stories and the rest).
The work supported a period in which users grew 130%, measured as DAU and MAU across all eight languages. Other changes landed in the same period, so I don’t claim that growth for the CMS alone.
Content-format products increased traffic 30% and contributed 6% incremental ad revenue.

Decisions I’d defend

Rebuild the CMS before adding AI. A suggestion needs a home in the editor’s flow.
That language’s editor approves every AI-assisted draft. Accountability stays where the masthead puts it.
Ship AI output in reviewable units. Grounded drafts and single fields, each quick to accept or replace.
Pick the model vendor for the business you’re in. Cloud-partnership economics and alignment with where our traffic came from.
Stop a working prototype when the economics fail. Once the grant was declined, the debate platform had no funded path.

What I’d do differently

Fix the measurement window before rollout. “Tripled over the period” is true and loose. I’d pin a baseline window per desk before launch, so the before/after holds up without me narrating it.
Use the desk-by-desk rollout as an experiment. Users grew 130% while plenty else changed. Holding one desk back for a defined window would have cost that desk some speed and told me how much of the growth was ours. I’d pay that price now.
Price the prototype before building it. I quantified the debate platform’s compute economics after the grant fell through. Run at the start, the same cost model would have put the self-funding answer on the table before the build.
Report acceptance next to output. The headline number was a count of published pieces. Acceptance rates per field and per language would show which suggestions editors trusted and which they rewrote. Scoring quality before anything publishes is the habit I now run on motomotar.

Outcomes are as stated on my résumé; attribution for user growth is shared with other changes in the period.