What direct indexing reveals about state, scalability, and long-term product design
Most product managers have worked with capabilities that appear straightforward at first but reveal deeper complexity as they evolve. The turning point often comes when something initially scoped as a feature begins to behave more like infrastructure.
I am sure this experience will resonate with many product managers. At this point, the capability is not just a feature, it is becoming a platform that enables others capabilities to emerge over time. It is important to recognize this shift early in the product development lifecycle.
Direct indexing is a useful example of this shift. Direct indexing is a type of wealth management product that allows an investor to replicate a market index, such as the S&P 500, by directly owning the individual securities that make up the index, rather than buying a single bundled fund like an ETF or mutual fund. In simple terms, instead of owning one “container” that represents the index, the investor owns the underlying components themselves.
This category of product has become increasingly popular as modern platforms have made it possible to manage large portfolios of individual securities automatically. It has enabled wealth platforms to buy, track and rebalance hundreds of stocks in a portfolio with minimal manual effort. It also enables investors to customize portfolios and apply strategies to minimize taxes. This is not possible when investments are packaged inside a single fund. At a high level it appears to be a very simple capability but it requires a platform which is capable of managing significant data, automation and decision logic.
I’m using direct indexing as an example not because it is unique to wealth management, but because it clearly illustrates a broader product principle. What appears to be a simple feature from the outside actually requires the system to manage complex, persistent state over time, making it fundamentally a platform problem rather than a feature problem.
The structural shift most users never see
Traditionally, investors gain exposure to market indices, such as the S&P 500, through pooled vehicles like ETFs or mutual funds. From a product standpoint, this model is relatively simple. The system tracks ownership of the fund, and the fund itself manages the underlying securities.
The platform’s responsibility is limited to tracking positions in the fund. The internal composition of the fund is abstracted away. Direct indexing changes this model entirely.
Instead of owning shares of a fund, the investor owns the individual securities that make up the index. A portfolio may contain hundreds of individual stocks, each purchased, tracked, and managed independently.
From the user’s perspective, the experience appears similar. They see a portfolio aligned with a market index, performance metrics, and allocation summaries. But from a system perspective, the difference is fundamental.
The product is no longer managing a single position. It is managing hundreds of independent, persistent entities per user, each with its own lifecycle, attributes, and historical context. This structural shift transforms the product from a feature into a platform.
The difference isn’t the interface. It’s the state
Most features operate on limited and relatively simple state. A user performs an action, and the system updates accordingly. The complexity may exist in the workflow or business logic, but the amount of state the system manages remains controlled and predictable.
Platform products behave differently. Each individual security in a direct indexing portfolio has its own purchase history, cost basis, and associated attributes. These records persist indefinitely and directly influence future system behaviour.
Future operations, such as portfolio adjustments, reporting, or optimization, depend on this accumulated state. The system is not simply responding to user inputs. It is managing an evolving structure of persistent, interconnected data. This is a defining characteristic of platform products. The system’s responsibility extends beyond delivering functionality. It must preserve, interpret, and evolve state over time.
Product lesson: Persistent state turns features into platforms
When products begin managing long-lived state, product decisions take on new significance. Data models, abstractions, and architectural boundaries are no longer implementation details. They become foundational product decisions that determine what the system can support in the future. This dynamic exists across many domains:
- Identity platforms manage persistent user relationships and permissions.
- Payments platforms manage transaction histories that influence downstream operations.
- AI platforms manage training data, model outputs, and inference behavior.
- Marketplace platforms manage relationships between buyers, sellers, and transactions.
In each case, the system’s role extends beyond executing tasks. It becomes responsible for maintaining and evolving state. This shift requires product teams to think beyond immediate functionality and consider long-term structural implications.
Why platform roadmaps look different
Feature roadmaps tend to focus on visible user functionality—interfaces, workflows, and automation. Platform roadmaps often prioritize capabilities that are not immediately visible but are necessary for scalability and future extensibility.
These may include:
- Systems for managing complex state reliably
- Abstractions that support future feature expansion
- Mechanisms to ensure consistency across evolving data
- Infrastructure that enables automation and optimization
These investments may not produce immediate user-visible outcomes, but they determine whether future capabilities can be implemented efficiently. Without this foundation, products often accumulate constraints that limit their evolution.
Product lesson: Platforms enable future capabilities
One of the defining characteristics of a platform is that it enables capabilities beyond its original scope. Direct indexing, for example, enables personalization, automation, and optimization capabilities, not because each was designed independently, but because the underlying platform supports them.
The same pattern appears in other domains. Payments platforms enable subscriptions and recurring billing. Identity platforms enable authentication and authorization. Data platforms enable analytics and machine learning.
Platforms enable new capabilities over time, while features usually solve a specific, immediate problem. Understanding this difference helps product teams build systems that can evolve and support future needs.
Scale is not just about users. It’s about state
Product teams often think about scale in terms of user growth. Platform products scale along another dimension: state complexity.
Each additional user increases not just system load but also the volume and complexity of managed state. Over time, systems must efficiently manage growing numbers of entities, relationships, and historical records. Without appropriate abstractions, complexity accumulates, making the system harder to maintain and to evolve.
This challenge exists across many platform products. Designing systems that can scale with growing state is critical to maintaining long-term product velocity.
Product lesson: Platform decisions are often invisible, but foundational
From a user’s perspective, platform products often appear simple. The interface is clear, and the experience feels seamless. The underlying complexity remains hidden.
But the most important product decisions exist beneath the surface. These include how the system models state, how behavior evolves over time, how extensibility is preserved, and how complexity is managed. These decisions determine whether the product can support future capabilities efficiently.
Users may never see these decisions directly, but they experience their consequences through the product’s reliability, flexibility, and ability to evolve.
One of the most valuable skills in product management is recognizing when something that appears to be a feature is actually a platform. Common signals include
- persistent and evolving system state
- complex relationships between entities
- capabilities that enable other capabilities.
When these signals appear, the product approach must change. Roadmaps should prioritize structural integrity alongside visible functionality. Product teams must think beyond immediate delivery and consider how today’s decisions will shape future capabilities.
This principle applies far beyond wealth management. Many of the most important product capabilities are not standalone features, but foundational platforms that enable ongoing innovation. Treating platforms as features can introduce constraints that limit long-term evolution. Recognizing platforms early allows teams to design systems that scale, adapt, and support future growth.
The most important product decisions are often not about what users see today. They are about what the system must support tomorrow. When a product begins managing persistent state and enabling future capabilities, it crosses an important threshold.
It stops being just a feature. It becomes a platform.
