Abstraction Layers

Imagine you were recently hired as a product manager to a brick and mortar retailer that has 10,000+ locations around the globe. As the newest member of the “Digital” organization, your task is improve customer experiences with coupons and other offer-related content across all digital properties. Concepts like “ omni-channel” and “at scale” are mentioned to you as lofty goals in the many conversations you are starting to have. 

Time to get to work. Without any further initial direction, it may seem like the sensible next thing to do is to start brainstorming solutions and new coupon and offer-related experiences. The issue with this approach is the lack of boundaries that your problem space - the set of unifying goals for the problems you want to solve - has at this point. 

It would be like playing a game with too few rules (or no rules at all), how would you know if the next move you made was meaningful to the game without the rule to define it against? Similarly, most new ideas for experiences that you come up with will be inherently arbitrary. This will ultimately lead to disconnected applications, disarticulate user experiences, and an incoherent business strategy over time. That’s where the Computer Science concept of abstraction comes in handy. 

Abstraction layers can be used as a tool for defining where your problem space starts and stops. Consider the fact that was mentioned at the beginning that you now work for the “Digital” organization in your new role. This is an abstraction, created to help group people with similar job functions together. An abstraction layer is an artificial grouping of things (ideally with a goal in mind), that can be nested (like all other logic systems). 

The question to ask yourself is, “what specific actions are our customers taking within this problem space?” If your problem space consists of anything “related to coupons and offer-related content”, then you can identify increasingly more specific actions that customers may make within that space. Utilize the perspectives of your co-workers to help direct your progressively deeper nesting of abstraction layers until you have a clear and holistic understanding of your problem space. If needed, you can also continue this process until the problems are small enough for you to develop your feature set around (you’ll know it when you get there). 

If you are required to go more than two layers down, your initial problem space may be too large and may need to be broken up into smaller pieces anyway. Because these feature sets are logically connected, you’ll always ensure that you are meeting the overarching goals of your problem space in a more cohesive way.

The biggest risk to this approach is human bias. Be open to new suggestions as you define your space and plan your roadmap. The more opinions that make it to the table, the better your solutions will be.