Pola Pikir Platform dalam Manajemen Produk API

Bukan rahasia lagi bahwa pandemi secara signifikan memperkuat kebutuhan organisasi untuk merangkul strategi digital-first. Transformasi digital yang telah diprioritaskan demi tujuan organisasi lainnya bergeser ke depan dan ke tengah dalam semalam, dengan urgensi yang belum pernah terjadi sebelumnya. Menurut Survei Global McKinsey 2020 para eksekutif, perusahaan mempercepat tingkat di mana mereka mendigitalkan operasi internal dan memperluas portofolio produk digital selama beberapa tahun, meskipun ada tantangan signifikan yang ditimbulkan oleh COVID-19.

Inti dari transformasi digital ini adalah integrasi, yang difasilitasi oleh antarmuka pemrograman aplikasi (API). Setelah dianggap hanya sebagai "pembawa pesan" atau "perantara" yang mentransmisikan data antar sistem perangkat lunak, API sekarang diakui sebagai "jaringan ikat" ekosistem digital, menawarkan integrasi tanpa batas dan peluang bisnis bagi organisasi yang membangun dan memanfaatkannya. Karena potensi unik yang diwakili oleh API, manajer produk yang mengawasi pengembangan mereka harus mengadopsi pendekatan yang membuka nilai laten mereka, pendekatan yang menekankan fleksibilitas dan ekstensibilitas untuk memastikan pengalaman integrasi yang sempurna.

Melakukan Lebih Banyak Dengan Lebih Sedikit

Bahkan sebelum tahun yang belum pernah terjadi sebelumnya, nilai API bagi organisasi telah didokumentasikan dengan baik, dan ekonomi API telah berkembang pesat selama beberapa waktu. Untuk memahami lanskap integrasi saat ini, akan sangat membantu jika menelusuri asal usul filosofi Best of Breed (BoB). Sebelum tahun 1990-an, vendor perangkat lunak memasarkan solusi suite perencanaan sumber daya perusahaan (ERP) yang berusaha memecahkan berbagai tantangan organisasi. Semakin lama, suite ini dianggap tidak praktis dan tidak praktis, karena gagal menangani kasus penggunaan khusus organisasi. Akibatnya, vendor mulai membangun alat yang lebih terfokus yang memecahkan tantangan untuk satu area fungsional, alih-alih suite yang lebih besar yang mencoba melakukan segalanya untuk semua orang. Perusahaan menyambut gagasan untuk memilih dari berbagai alat yang lebih kecil dan lebih khusus dan mulai mengumpulkan koleksi solusi individu yang paling sesuai dengan kebutuhan khusus mereka.

Menghubungkan Titik-titik

Saat pendekatan BoB mulai berkembang, integrasi menjadi bagian penting dari strategi produk. Alat yang hebat dalam memecahkan masalah untuk satu area bisnis harus dapat berintegrasi dengan baik dengan produk BoB lain yang kemungkinan akan digunakan di sampingnya. Pertimbangkan HubSpot, perangkat lunak penjualan dan CRM yang diterapkan oleh organisasi untuk melacak dan mengoptimalkan jalur penjualan dan hubungan pelanggan mereka. HubSpot siap terintegrasi dengan perangkat lunak BoB lainnya seperti DocuSign (tanda tangan digital), Twilio (pemberitahuan email/SMS), dan Zendesk (dukungan pelanggan) tanpa memerlukan pengembangan tambahan dari tim teknik pelanggan.

Kebutuhan akan alat pelengkap untuk menyambungkan satu sama lain dengan mulus disertai dengan pergeseran industri ke arah merangkul keterbukaan daripada membatasi interaksi antar sistem. Di suatu tempat di sepanjang jalan, jumlah integrasi yang didukung produk menjadi metrik yang layak untuk pemasaran.

Proposisi Platform

Namun, nilai sebenarnya dari integrasi melampaui kemampuan mereka untuk mengoordinasikan alat dan sistem yang berbeda. Yang terbaik, API adalah mekanisme kolektif untuk mengubah produk menjadi platform. Produk, menurut definisi, adalah alat yang memiliki aplikasi tertentu; maka "aplikasi." Mereka terbatas dalam kemampuan mereka untuk menciptakan beberapa proposisi nilai dan, dengan perluasan, beberapa aliran pendapatan. Platform, di sisi lain, menambah nilai dengan cara yang berbeda: dengan menyediakan lapisan infrastruktur di mana banyak produk dapat dibangun.

API membuka saluran bisnis baru dengan memanfaatkan keahlian pihak ketiga yang memanfaatkannya. Pengembang konsumen dapat merancang aplikasi real estat yang menggunakan API Tempat Google Maps untuk membantu pencarian rumah pengguna, atau mereka dapat memanfaatkan API Penerbangan Skyscanner dan API Hotel Expedia untuk membuat situs ekowisata yang berspesialisasi dalam perjalanan ke lokasi tertentu. Pengembang dan mitra eksternal ini mendapatkan keuntungan dengan mendapatkan akses ke data dan layanan yang ada yang dapat mereka sesuaikan untuk bisnis mereka, dan pemilik API seperti Expedia memperluas jangkauan mereka dan memonetisasi peluang yang tidak akan ada jika mereka terus, katakanlah, hanya mencantumkan hotel di produk mereka.

Menjadikannya Modular

Untuk pemimpin produk, mengembangkan strategi API yang sukses memerlukan perubahan pola pikir dari pemikiran produk ke pemikiran platform. Ini berarti membangun produk dengan cara modular dan terbuka yang memungkinkan fungsionalitasnya digabungkan kembali dan yang memprioritaskan fleksibilitas untuk pengembang yang mengonsumsi. Pikirkan sistem rak IKEA, yang dapat dibeli, dirakit, dan disesuaikan oleh pelanggan dengan berbagai cara untuk memenuhi berbagai kebutuhan. Manajer produk API yang baik melihat API apa adanya: alat untuk menskalakan bisnis dan mengembangkan kemitraan yang berharga. Mengenali potensi ini berarti menerapkan praktik terbaik untuk memastikan adopsi.

Menyenangkan Pengembang

Jika ada satu pilar dasar dari strategi API yang solid, itu adalah pengalaman pengembang (DX). Untuk integrasi API, manajer produk "pelanggan" perlu senang dengan pengembang yang mengonsumsi. Ini adalah pengguna yang akhirnya menelepon/berintegrasi dengan API, mitra potensial yang dapat membantu mewujudkan visi produk-ke-platform. Memberi label pengalaman mereka "DX" alih-alih "UX" mengakui bahwa mereka bukan pengguna akhir biasa—mereka jauh lebih mahir secara teknis. Untuk berempati dengan mereka, penting untuk memahami kebutuhan dan harapan khusus mereka.

Praktik terbaik

Berikut ini, meskipun tidak berarti mewakili daftar yang lengkap, adalah praktik penting untuk membangun API tingkat pertama yang memastikan pengalaman integrasi yang bebas gesekan dan konsisten, dapat diprediksi untuk pengembang yang mengonsumsi. Manajer produk harus mendekati perancangan API dengan cara yang skalabel, mendefinisikan kerangka kerja praktik terbaik dan menerbitkannya sebagai dokumen yang dapat dirujuk oleh tim saat membuat API baru.

Konvensi penamaan dan titik akhir yang konsisten

Menetapkan konvensi penamaan yang konsisten untuk titik akhir API yang secara jelas mengidentifikasi sifat dan tujuan API menghilangkan ambiguitas dan berkontribusi pada DX yang positif dan dapat diprediksi. Yang terbaik adalah memilih URL dasar umum untuk semua API dan kerangka kerja untuk URL tambahan yang menghindari jargon dan singkatan. Nordic API menawarkan daftar tip yang berguna untuk penamaan titik akhir.

Struktur respons keberhasilan dan kegagalan yang terperinci

Pengembang menginginkan dan mengharapkan objek data dan kode status yang sudah dikenal untuk respons sukses dan gagal. Itu berarti kode status 2xx untuk skenario sukses, kode 4xx untuk kegagalan sisi klien, dan kode 5xx untuk kesalahan sisi server. Namun, spesifisitas adalah kuncinya. Panggilan ke API "kirim email" yang hanya mengembalikan respons 4xx tanpa informasi tambahan membuat pengalaman pengembang yang buruk, karena itu hanya mengonfirmasi bahwa kesalahan ada dalam permintaan klien tanpa memberikan informasi tambahan tentang apa yang sebenarnya salah.

 { "status": 400, "message": "incorrect request" }

Sebaliknya, respons yang menawarkan detail spesifik dalam format yang dapat dibaca manusia dan dalam bentuk kode kesalahan unik dapat membantu pengembang dengan cepat memutuskan cara memperbaiki skenario kesalahan, menulis kode untuk mengatasi masalah, dan mencoba lagi panggilan API.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Untuk DX yang optimal, struktur respons dan kunci yang mengkomunikasikan status harus konsisten di seluruh API. Misalnya, bidang kode kesalahan di atas harus selalu disebut sebagai "kode" di setiap API, bukan "kode" di beberapa API dan "Kode kesalahan" di API lainnya.

Batas tarif yang dapat dikonfigurasi

Batas tarif mengatur seberapa dapat diaksesnya API dengan menentukan berapa kali pengguna dapat memanggilnya dalam satu unit waktu. Batas tarif yang terlalu tinggi dapat membanjiri sistem dengan jumlah permintaan yang tidak dapat dikelola yang menurunkan kinerja, sementara batas tarif yang terlalu rendah dapat menyebabkan transaksi yang tertunda mengantre di sistem pengguna. Keduanya berkontribusi pada DX yang buruk. Saat merancang API, yang terbaik adalah mengizinkan batas tarif yang dapat disesuaikan berdasarkan kasus dan keadaan bisnis tertentu. Pelanggan bervolume tinggi, misalnya, mungkin benar-benar perlu memanggil API lebih sering.

Untuk menentukan batas kecepatan yang tepat, sebaiknya kelompokkan API terlebih dahulu ke dalam kategori yang berarti menurut frekuensi dan volume yang memanggilnya. Misalnya, API yang mengonfigurasi data pelanggan utama (pembuatan profil/akun) lebih jarang dipanggil dan dapat menangani batas tarif yang lebih rendah, sedangkan API transaksi (“buat pesanan”, “kirim email”) lebih sering dipanggil, yang memerlukan batas tarif yang lebih tinggi. Menetapkan kategori, atau tingkatan, untuk kasus penggunaan yang berbeda membuat API lebih andal dan skalabel. Untuk contoh batas kecepatan yang ditentukan dengan jelas, lihat dokumentasi API Slack.

Dokumentasi yang komprehensif

Dokumentasi berfungsi sebagai panduan pengguna untuk API. Ini dengan jelas mengartikulasikan kepada pengembang apa yang dilakukan API, bagaimana menggunakannya, dan apa yang diharapkan darinya. Dokumentasi yang baik ditulis dalam bahasa yang jelas dan dapat diakses, terperinci dan interaktif, dan menawarkan banyak demo dan cuplikan kode untuk membuat integrasi menjadi lebih sederhana. Dengan cara ini, memfasilitasi orientasi yang mudah dan Time to First Hello World (TTFHW) yang cepat, metrik penting yang menunjukkan seberapa cepat pengembang dapat berhasil memanggil API pertama mereka.

Dokumentasi harus dengan jelas mengidentifikasi bidang mana dalam permintaan API yang wajib dan mana yang opsional, serta panjang dan tipe data minimum dan maksimum untuk bidang tersebut. Pada dasarnya, itu harus mencakup semua yang diperlukan untuk menetapkan harapan dan menghilangkan hambatan untuk mengkonsumsi pengembang. Pengembang yang membuat skema basis data dalam sistem mereka, misalnya, tidak perlu lagi menyesuaikan panjang kolom dalam tabel karena dokumentasi tidak menentukan parameter.

Dokumentasi API dapat meningkatkan adopsi tidak hanya dengan menjadi referensi yang andal bagi pengembang yang mengonsumsi, tetapi juga dengan bertindak sebagai alat pemasaran untuk API itu sendiri. Seringkali, orang pertama yang menemukan dokumentasi API adalah pemangku kepentingan yang berhadapan dengan bisnis, yang menelusurinya selama fase awal evaluasi produk. Oleh karena itu, ini tidak hanya harus mencakup detail tentang elemen teknis API tetapi juga harus dengan jelas mengartikulasikan kasus penggunaan bisnis yang dimungkinkan oleh API.

Ada sejumlah alat di pasar yang dapat membantu menghasilkan dokumentasi API yang komprehensif. Meninjau contoh dokumentasi berkualitas tinggi, seperti Stripe, juga membantu.

Menyatukan Semuanya

Integrasi mewakili domain yang luas dengan banyak komponen, tetapi memahami prinsip-prinsip inti dari API yang baik adalah dasar untuk mengembangkan strategi yang solid. API jauh lebih dari sekadar konektor sistem. Mereka adalah blok bangunan jaringan digital yang luas dan kunci untuk membuka aliran pendapatan baru dan melepaskan nilai yang belum dimanfaatkan. Karena itu, strategi API yang sukses bukan hanya tentang membangun produk; ini tentang membangun potensi. Manajer produk API harus mengadopsi pola pikir platform dan memprioritaskan faktor-faktor yang akan memperlancar adopsi bagi calon mitra yang kemudian dapat menggunakan API mereka, mengintegrasikan, dan menjalankannya.