The ultimate goal of product management is to build a product that incrementally meets the needs of users. If you can successfully create a loved product that meets the needs of users, you’re creating value and will ultimately capture value.
It is widely accepted that Product lies in between Business, Tech and Design.
I lead a product organisation at OPay that is structured around:
- Research
- Core Product (merchant and internal tools, mobile and technical integrations)
- Design (UI/UX)
My background and experience have given me breadth but I didn’t have as much depth on the tech side of things. Like I did at Switch, I would give high level thought leadership on desired functionality and API requirements, then someone else would flesh it out with all the tech speak.
However, in the last few weeks, I decided to dive into API specifications and data manipulation (hello SQL Babe) to build my muscle there.
I’m going to share a bit about my API specs experience so far. First, I’d send a shout out to the best teacher Bukolami Agboola. I feel fortunate that she’s on my team and a fantastic teacher.
What are APIs in the First Place?
API is an acronym, and it stands for “Application Programming Interface.” Essentially, products run on APIs. APIs are what make products work behind the scenes — they lend function to your product.
There are multiple types of APIs- internal APIs, public APIs and partner APIs. I’m going to share more about partner APIs in this article because the use case we will explore involves a 3rd party betting partner for OPay.
#engineering #software-development #api-specifications #product-management #json-web-token