Update AI Search Mingguan: Cara Memisahkan Perubahan Produk dari Perubahan Standar

Jumat sore, grup kerja digital biasanya sudah mulai tenang.

Lalu seseorang mengirim link.

“Google update AI Mode.”

Lima menit kemudian:
“OpenAI update shopping.”

Sepuluh menit:
“MCP ada release baru.”

Lalu seseorang menulis:
“Berarti strategy minggu depan berubah semua?”

Tidak.

Kalimat “AI update” menutupi terlalu banyak kategori.

Perubahan produk tidak sama dengan perubahan standar.

Perubahan UI tidak sama dengan perubahan measurement.

Release model tidak sama dengan protocol migration.

Kalau weekly review mencampur semuanya, tim akan selalu merasa ada fire.

Padahal sebagian update cukup dibaca.
Sebagian perlu test.
Sebagian perlu engineering ticket.
Sebagian perlu migration plan.

Cara paling praktis adalah membuat dua jalur sejak awal:

PRODUCT TRACK

dan

STANDARD / INFRA TRACK.

Bukan karena keduanya tidak berhubungan.

Justru supaya hubungan mereka bisa dibaca dengan benar.

Apa itu product change?

Product change adalah perubahan pada experience atau capability yang disediakan platform.

Contoh:
AI Mode mendapat feature baru.
ChatGPT menambah shopping flow.
Google menambah Search agent.
Ads Manager menambah bidding option.
Perplexity menambah surface commerce.

Product change terutama menjawab:
“User sekarang bisa melakukan apa yang sebelumnya tidak bisa?”

Impact-nya biasanya ada di:
user behavior,
distribution,
marketing,
content,
conversion,
UX.

Contoh sederhana.

ChatGPT product discovery menjadi lebih kaya.

Retail team perlu cek:
apakah product data lengkap,
apakah catalog fresh,
apakah product identity konsisten.

Tidak otomatis perlu protocol migration.

Itu product impact.

Apa itu standard change?

Standard change mengubah contract atau rule teknis yang dipakai antar-system.

Contoh:
MCP 2026-07-28.
A2A v1.0.
C2PA 2.4.

Standard change menjawab:
“Apakah dua system masih berbicara dengan aturan yang sama?”

Impact-nya lebih dekat ke:
interoperability,
versioning,
security,
conformance,
migration,
data model.

Kalau MCP menjadi stateless, UI user mungkin terlihat sama.

Di belakang layar, architecture bisa berubah signifikan.

Itulah kenapa product dan standard tidak boleh ditimbang berdasarkan seberapa visible bagi user.

Perubahan yang tidak terlihat bisa punya blast radius lebih besar.

Ada kategori ketiga: platform policy

Crawler rule.
Ads policy.
Search eligibility.
Spam policy.

Ini bukan pure product dan bukan technical standard.

Tetapi dalam weekly review, masukkan ke jalur yang owner-nya paling relevan.

Crawler policy bisa masuk Infrastructure/Governance.
Ads policy masuk Product/Commercial.
Search spam policy masuk Search Governance.

Tujuan taxonomy bukan membuat akademik.

Tujuannya menentukan siapa harus bergerak.

Buat weekly review 30 menit

Tidak perlu meeting dua jam.

Setiap item harus punya format tetap:

What changed?
Source primer?
Category?
Impact?
Owner?
Action?

Misalnya:

Google Search Central menambah guidance generative AI.

Jenis update-nya: Product/Search guidance.

Impact: SEO/content.

Action: review mythbusting section, hapus project llms.txt khusus Google.

Owner-nya: SEO lead.

Atau:

MCP 2026-07-28 final.

Jenis update-nya: Standard.

Impact: production MCP.

Action: architecture gap analysis.

Owner-nya: platform engineering.

Dua update.
Dua jalur.
Dua owner.

Jangan kirim semuanya ke marketing.

Cara mengidentifikasi product update

Ada beberapa signal.

Bahasanya sering:
launching,
rolling out,
available,
new feature,
now you can,
new experience.

Source-nya:
product blog,
release notes,
help center,
announcement.

Pertanyaan utamanya:
siapa user yang mendapat?
di market mana?
plan apa?
fungsi apa?
apa yang berubah dari journey?

Product update sering punya availability constraint.

US-only.
Beta.
Subset user.
Enterprise only.
Selected merchant.

Ini penting.

Jangan membuat global strategy dari feature yang target audience Indonesia belum bisa pakai.

Catat availability.

Cara mengidentifikasi standard update

Bahasanya:
specification,
version,
breaking changes,
deprecated,
removed,
conformance,
migration,
protocol.

Source-nya:
official specification,
changelog,
standards body,
technical steering group.

Pertanyaan utamanya:
versi production kita apa?
apa yang berubah?
backward compatible?
deprecation window?
security impact?
test apa?

Standard update tidak selalu butuh immediate rollout.

Kadang ada 12 bulan migration window.

Tetapi ia hampir selalu butuh owner kalau standard itu ada di production.

Bagaimana dengan MCP 2026-07-28?

Ini contoh bagus.

Di level product, user mungkin tidak melihat apa-apa.

Di level standard:
core stateless,
extension framework,
authorization hardening,
formal deprecation,
client primitive tertentu deprecated.

Kalau weekly review hanya membaca “MCP update besar”, hasilnya terlalu vague.

Buat checklist:

Apakah kita menggunakan MCP?
Jika tidak: Watch.

Jika iya:
versi apa?
feature apa yang dipakai?
ada deprecated dependency?
migration urgency?
security review?

Baru tentukan action.

Bagaimana dengan A2A v1.0?

Sama.

Kalau tidak punya agent-to-agent system, tidak perlu immediate project.

Kalau punya implementation v0.3, stable v1.0 adalah migration signal.

Product team tidak perlu hafal Agent Card field.

Mereka cukup tahu:
“interoperability layer kita punya major version baru.”

Engineering mengurus detail.

Bagaimana dengan C2PA?

C2PA 2.4 menambah AI Disclosure, format embedding, dan perubahan provenance lain.

Buat media company yang sudah pakai Content Credentials, itu standard update aktif.

Buat SaaS yang tidak memproses asset provenance, mungkin hanya Watch.

Ini inti weekly filtering:
relevance dulu, detail kemudian.

Ada satu jebakan: product update sering membawa standard dependency

Misalnya commerce experience berkembang.

Di baliknya bisa ada product feed atau protocol.

Search agent berkembang.

Di baliknya ada structured data, booking provider, atau emerging commerce protocol.

Jadi jalurnya bisa bertemu.

Tetapi urutannya tetap beda.

Product team berkata:
“User sekarang bisa melakukan X.”

Infra team berkata:
“Untuk support X secara reliable, kita butuh Y.”

Jangan dibalik.

Kalau tidak ada use case, tidak perlu membangun protocol hanya karena ada.

Weekly review juga harus punya status warna sederhana

Green: no action.

Blue: watch.

Yellow: test.

Orange: plan.

Red: production risk.

Sebagian besar item harus green atau blue.

Kalau semua orange, tim sedang overreacting.

Contoh minggu normal:

Google AI Mode UI update:
Blue.

Search Console generative report rollout:
Yellow untuk analytics team.

ChatGPT Ads market expansion:
Blue atau Yellow tergantung market.

MCP security change:
Orange kalau production affected.

A2A minor SDK update:
Green kalau tidak dipakai.

C2PA new guidance:
Blue untuk publisher.

Hasilnya satu screen.

Bukan 40 tab.

Ada satu role yang penting: update editor

Bukan editor artikel.

Orang yang mengkurasi perubahan.

Ia bisa SEO strategist, product ops, atau technical program manager.

Tugasnya bukan tahu semuanya.

Tugasnya membuang noise sebelum meeting.

Sebelum weekly review, ia cek source primer.

Kalau update hanya rumor, tandai Rumor.

Kalau blog pihak ketiga, cari announcement asli.

Kalau screenshot feature tanpa docs, tandai Observation.

Ini mengurangi misinformation.

Contoh:
seseorang mengirim thread “Google wajib llms.txt”.

Update editor buka guidance resmi.

Google mengatakan file khusus seperti llms.txt tidak diperlukan untuk Search dan diabaikan Google Search.

Thread selesai.

Tidak perlu debat 30 menit.

Source hierarchy harus jelas

Tier 1:
official specification,
official docs,
official release notes,
official platform blog.

Tier 2:
maintainer statement,
conference talk resmi,
vendor engineering post.

Tier 3:
reputable analyst,
media,
community.

Tier 4:
social post tanpa evidence.

Action besar tidak boleh dibangun dari Tier 4.

Kalau hanya ada rumor, statusnya Watch.

Ini rule yang sangat murah dan sangat efektif.

Weekly review juga perlu melihat tanggal event, bukan hanya tanggal artikel

Kadang media baru menulis hari ini tentang feature yang sudah diumumkan bulan lalu.

Kalau tim hanya melihat publish date, mereka merasa ada update baru.

Catat:
announced,
released,
available,
deprecated effective date.

Standard migration sangat sensitif terhadap tanggal efektif.

Product rollout juga.

“Launching” bukan selalu “available in Indonesia now”.

Apa output weekly review?

Bukan summary.

Action register.

Contoh:

1. Search Console generative report
Action: analytics tambah view ke dashboard.
Owner-nya: Rina.
Due: Rabu.

2. MCP final
Action: cek dependency pada session ID.
Owner-nya: platform.
Due: Jumat.

3. ChatGPT shopping update
Action: no action, market/use case belum prioritas.
Owner-nya: none.

4. Google mythbusting
Action: stop internal proposal special AI markup untuk Google.
Owner-nya: SEO.
Due: immediate.

Empat item.
Selesai.

Kalau tidak ada action, weekly review tetap sukses.

Tim tidak perlu menciptakan kerja untuk membuktikan mereka mengikuti AI.

Ada satu hal yang harus dihindari: “update theater”.

Deck bagus.
Timeline penuh.
Logo banyak.
Tidak ada keputusan.

AI bergerak terlalu cepat untuk theater.

Setiap update harus berakhir pada salah satu dari lima kata:

Ignore.
Watch.
Test.
Plan.
Do.

Kalau belum bisa dikategorikan, belum cukup dipahami.

Product change menjawab apa yang user bisa lakukan.

Standard change menjawab bagaimana system harus berinteraksi.

Policy change menjawab apa yang boleh atau eligible.

Measurement change menjawab apa yang bisa kita lihat.

Empat kategori itu sudah cukup untuk sebagian besar weekly review.

Di Jumat sore berikutnya, grup kerja kembali ramai.

Ada tiga link baru.

Kali ini update editor membalas:

“Google feature: Watch.
OpenAI commerce: Test untuk retail.
MCP changelog: Plan, production kita affected.”

Tidak ada panic.

Tidak ada “SEO mati”.

Tidak ada meeting darurat.

Satu hal lagi yang perlu dipisahkan adalah update dokumentasi dan update behavior.

Kadang platform mengubah documentation karena ingin menjelaskan behavior yang sebenarnya sudah berjalan. Kadang docs berubah karena behavior baru memang baru diluncurkan. Dua situasi ini tidak identik.

Kalau Google memperbarui guidance tentang generative Search, cek bagian “what changed” dan alasan perubahan. Search Central punya update log yang membantu membedakan clarification dari feature release.

Kalau OpenAI mengubah help article ads, cek apakah itu policy baru, rollout baru, atau hanya wording yang diperjelas.

Untuk standard, changelog lebih penting lagi.

Satu paragraph blog bisa merangkum perubahan besar, tetapi migration harus merujuk ke spec dan changelog.

Weekly review karena itu sebaiknya punya field tambahan:
Behavior changed?
Docs changed?
Both?

Kalau hanya docs clarification, action bisa berupa memperbaiki internal understanding.

Kalau behavior berubah, test.

Kalau contract berubah, migration review.

Ini membuat tim tidak bereaksi berlebihan pada setiap edit dokumentasi, tetapi juga tidak meremehkan clarification yang membatalkan asumsi lama.

Hanya tiga keputusan.

Itu tanda organisasi mulai matang menghadapi AI Search.

Bukan karena perubahan melambat.

Karena classification-nya membaik.