Designing a Company-Wide Identity, Roles and Consent Platform for Flipkart Teams

Quick Overview

A technical product question about designing a shared user management system that many teams at Flipkart can build on, with scalability out of scope. It tests scoping, the needs of end users and internal teams, identity and permission models, interfaces, adoption and migration, privacy and success metrics.

Designing a Company-Wide Identity, Roles and Consent Platform for Flipkart Teams

Company: Flipkart

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

You are a product manager at Flipkart. Many teams across the company need to manage users, and you are asked to design a user management system (UMS) that all of them can use. Leave scalability aside for this question: assume the infrastructure can handle the load, and concentrate on what the system does, whom it serves and how you would design it. ```hint Find the platform's customers Ask who this system is for: the people whose accounts it holds, the internal teams that build on it, or both. List what each group would need before you choose features. ``` ### Clarifying Questions - Which users does the system manage: shoppers, sellers and their staff, delivery partners, employees using internal tools, or several of these? - Do teams keep their own user records today, so that adoption and migration are part of the job? - Should the system own sign-up and sign-in, or only profiles, roles and permissions, with authentication handled elsewhere? - Which privacy and consent rules must it enforce when one team wants user data that another team collected? ### What a Strong Answer Covers - A clear scope: which user types the system manages and which capabilities it owns versus leaves to individual teams - The needs of each customer group: end users, the internal teams integrating with it, and support and compliance staff - Core capabilities backed by a data model and interfaces: identity, profiles, organizations, roles and permissions, consent and audit - A prioritized path for teams to adopt the system, including migration of existing accounts - Success metrics and risks such as account takeover, privacy, sign-in as a shared point of failure, and ownership of shared data ### Follow-up Questions - Two teams want different fields on the same user profile and disagree about who owns the phone number. How do you govern the shared data? - How would you move a team with a large existing user base onto the system without forcing everyone to sign in again? - The system's direct customers are other teams. How do you know whether it is succeeding?

Overview: A technical product question about designing a shared user management system that many teams at Flipkart can build on, with scalability out of scope. It tests scoping, the needs of end users and internal teams, identity and permission models, interfaces, adoption and migration, privacy and success metrics.

Flipkart logo
Flipkart
May 1, 2024
mediumProduct ManagerOtherSystem Design
0
0

You are a product manager at Flipkart. Many teams across the company need to manage users, and you are asked to design a user management system (UMS) that all of them can use. Leave scalability aside for this question: assume the infrastructure can handle the load, and concentrate on what the system does, whom it serves and how you would design it.

Clarifying Questions Guidance

  • Which users does the system manage: shoppers, sellers and their staff, delivery partners, employees using internal tools, or several of these?
  • Do teams keep their own user records today, so that adoption and migration are part of the job?
  • Should the system own sign-up and sign-in, or only profiles, roles and permissions, with authentication handled elsewhere?
  • Which privacy and consent rules must it enforce when one team wants user data that another team collected?

What a Strong Answer Covers Guidance

  • A clear scope: which user types the system manages and which capabilities it owns versus leaves to individual teams
  • The needs of each customer group: end users, the internal teams integrating with it, and support and compliance staff
  • Core capabilities backed by a data model and interfaces: identity, profiles, organizations, roles and permissions, consent and audit
  • A prioritized path for teams to adopt the system, including migration of existing accounts
  • Success metrics and risks such as account takeover, privacy, sign-in as a shared point of failure, and ownership of shared data

Follow-up Questions Guidance

  • Two teams want different fields on the same user profile and disagree about who owns the phone number. How do you govern the shared data?
  • How would you move a team with a large existing user base onto the system without forcing everyone to sign in again?
  • The system's direct customers are other teams. How do you know whether it is succeeding?