Welcome, Awesome Product Managers!
This interactive guide is your quick tour through the world of SDKs (Software Development Kits). Our goal is to equip you with a solid understanding of the SDK landscape so you can write even more killer requirements and collaborate effectively with our engineering teams.
Navigate through the sections using the menu on the left. Let's level up your product game!
What the Heck is an SDK? 🛠️
SDK = Software Development Kit
Think of it as a **pre-packaged toolkit** for developers. It gives them the building blocks (code libraries, tools, documentation, code samples) to integrate *our* awesome features into *their* applications, without having to build everything from scratch.
Analogy Time 🎂
Why bake a cake from scratch (grow wheat, mill flour, raise chickens) when you can use a cake mix (the SDK)?
It's all about helping developers make some serious dough, faster!
Why PMs Should Care:
Better SDK understanding → Clearer Feature Requirements → Smoother Development → Happy Engineers AND Happy Users! 🎉
SDK Flavors: Platform & Purpose
SDKs come in various "flavors" depending on where they run (the platform) and what they're designed to do (their purpose). Understanding these distinctions is key to defining features effectively.
SDKs by Platform (Where it Runs)
🌐 Web SDKs (The OG)
Target: Traditional websites (multi-page applications).
PM Lens: Features for standard website structures.
💻 SPA SDKs (Smooth Operators)
Target: Modern web apps (React, Angular, Vue.js) where the page doesn't fully reload.
PM Lens: Crucial for rich, interactive web experiences; consider dynamic content and client-side routing.
📱 Native SDKs (Powerhouses)
Target: Mobile apps for iOS (Swift/Objective-C) or Android (Kotlin/Java).
Deep integration with device capabilities (camera, GPS, etc.).
PM Lens: When you need tight hardware integration or a super-polished mobile-first experience.
Trying to get a Web SDK to use native device contacts? That's like asking it to `fetch` a miracle! It's just not its native tongue.
SDKs by Purpose (What it *Does*)
💂 Auth SDKs (The Gatekeepers)
Purpose: Primarily focused on user identity (login, registration, session management).
Answers: "Who are you, and can you come in?"
Typical Use: Often client-side (in the user's browser or mobile app).
PM Lens: How will users access features? What are the user authentication flows? This is your go-to for user-facing security.
🔑 Management SDKs (The Control Panel)
Purpose: Designed for programmatic administration and control of our platform/service on behalf of a customer or system.
Answers: "What can *your backend system* do with and to our platform at an administrative level?"
Typical Use: Often server-to-server.
PM Lens: Is this feature for end-users logging in, or for our customers to *manage their account/services with us programmatically*?
🤫 Let's Talk Secrets! (Focus on Management SDKs)
Management SDKs often deal with Confidential Clients. The big secret? The Client Secret!
- This is like a password for the *client application* (e.g., their server), not the end-user.
- It's used to securely obtain special access tokens for powerful Management APIs.
CRUCIAL: Client secrets MUST be kept secure on their backend. Never embed a client secret in a public-facing web app or mobile app!
Analogy: Auth SDKs are bouncers checking IDs. Management SDKs (with client secrets) are the venue owner's master keys – only for trusted parties who can *manage* to keep a secret!
✨ SDK Matchmaker
Got a feature idea? Describe it below, and let AI suggest the most suitable SDK types to consider.
The Future is Modular! (Slice & Dice!)
The way we build and offer SDKs is evolving. We're moving from a "one-size-fits-all" approach to a more flexible, modular one. This shift has significant benefits for both developers and us.
The "Old Way" (Monolithic SDK) 🧰
Imagine one giant toolbox. Developers had to take the *whole* thing, even if they only needed a tiny screwdriver.
What a weighty issue for their app sizes!
The "New Way" (Modular SDKs) 🧱
Think LEGOs! Developers can pick and choose *only* the specific feature modules they need (e.g., analytics module, user auth module).
Key Benefits of Modular SDKs
Why PMs Should Be Excited:
- Faster adoption of *your* new features!
- When defining a feature, think: "Could this be a neat, independent module?"
Your Superpower: SDK-Aware Requirements!
Your understanding of SDKs is a superpower! It allows you to write clearer, more effective requirements, leading to smoother development cycles and better products. Here are key things to consider:
Think About the "Where & What":
-
1.
Platform? (Web, SPA, iOS, Android) Any platform-specific behaviors or limitations to consider?
-
2.
Purpose?
- End-user authentication (→ Auth SDK focus)
- Backend/administrative control (→ Management SDK focus - will a client secret be involved?)
-
3.
Modularity? Could this feature be a standalone module? What are its dependencies?
Engage Early & Often!
Chat with the SDK teams! They're your partners in *code*.
Your clear understanding helps them build better, faster, and with fewer `// TODO: Ask PM for clarification` comments!
✨ Requirement Refiner
Describe your feature idea, and let AI help you brainstorm SDK-specific questions and considerations for your requirements.
Quick Recap & One for the Road!
You've covered a lot! Here are the main takeaways:
- SDKs are toolkits that simplify feature integration for developers.
- SDK Flavors vary by:
- Platform: Web, SPA, Native.
- Purpose: Auth (user identity) vs. Management (admin control, often needs that precious client secret).
- Modular SDKs are the future: offering flexibility, smaller app sizes, and faster updates.
Your SDK knowledge directly leads to better products!
"Why did the SDK break up with the API? It said, 'I just need some space... and a better contract!'"