Native mobile appsCustomer profile in the app journey
Backend product · Capability portfolio
Decouple the journey,not the intent.
Owned the Customer Data Platform foundation and its capability APIs, separating customer-facing journeys from legacy backends while making profile data materially faster to retrieve.
- Role
- Backend Product Owner
- Duration
- May 2022 — Oct 2023
- Milestone
- Delivered at scale
Time to first customer data in Telekom shops-75%
Full profile load-60%
Fixed-line My Profile-40%
Interactive request traceFollow the capability,
Follow the capability,
not the legacy topology.
Customer information had to flow from complex legacy backends into fast-changing frontend use cases. Direct dependencies slowed change, amplified complexity, and made consistent performance difficult.
ConsumerNative mobile appsCustomer profile in the app journey
Product boundaryProfile APIREST · JSON · encrypted
Legacy backend layerLegacy backend interactions orchestrated hereCustomer · Orders · Identity
GET /profileStable use-case contractTarget <20msOmnichannel delivery
One capability.
Three frontend channels.
The same customer capability served native mobile apps, web journeys, and internal Telekom shop platforms. Each channel used a stable contract while the CDP handled legacy-backend differences behind the boundary.
On-demand profile migration
Each first legacy-backed profile lookup also acted as a migration step. Once the customer was written to the CDP, later lookups were served from the CDP without calling the legacy backend again.
Shared customer capabilityCDP / Profile APIOne stable product boundary
WebMy Profile and web journeys
Telekom shop platformsAssisted-service customer lookup
The product decision
A proxy forwards complexity.
A capability layer contains it.
The programme introduced a Customer Data Platform: a collection of APIs hosted on AWS and connected to legacy services. Native mobile apps, web journeys, and internal Telekom shop platforms needed stable, secure access to customer capabilities without inheriting backend complexity.
Capability-first
Organize the layer around durable business capabilities rather than mirroring legacy-system structures.
Use-case-led contracts
Use frontend use cases to define the endpoint portfolio and keep contracts relevant.
Performance by design
Treat latency, daily request volume, and encryption as product requirements—not late technical checks.
Stable channel boundary
Use the Customer Data Platform and REST APIs as the boundary between channels and underlying systems.
Non-functional requirements
The architecture had a product budget.
Shape
Legacy sources exposed customer information in different structures and operating models.
Scale
The layer had to support millions of requests every day.
Speed
Response-time expectations were measured in milliseconds.
Security
Encryption, on-premises components, and cloud services had to work within one end-to-end design.
Customer and channel impactCustomer data arrived sooner—without exposing channels to every backend constraint.
- Reduced time to first customer data in Telekom shops by more than 75%.
- Cut full profile load time by 60%, shortening assisted-service journeys.
- Improved My Profile load times by 40% across app and web for customers with fixed-line contracts.
- Enabled cross-domain matching between fixed-line and mobile contracts, customer profiles, and contracting parties.
- Made profile migration demand-driven: after the first legacy-backed lookup populated the CDP, later requests were served from the CDP without calling the legacy backend again.
- Supported millions of daily requests with a response-time target below 20ms and enterprise-grade encryption.
The best decoupling boundary is a product decision: capabilities stay useful when they represent customer and business intent, not the shape of yesterday’s systems.
Evidence note · Customer-journey and performance figures reflect the supplied project outcomes; proprietary service topology remains abstracted.
Start a conversation