From Tax Tool to Life Platform: The Product Strategy Behind Expanding Your TAM | AI PM Portfolio

From Tax Tool to Life Platform: The Product Strategy Behind Expanding Your TAM

October 30, 2025 · 16 min read · Product Strategy

Most startups expand their TAM by building adjacent products. We expanded ours by changing the frame: instead of building 41 separate tools for immigrants, we built one knowledge graph with 41 views. This architectural insight -- that a single data structure can power dozens of user-facing surfaces -- grew our addressable market from $2.1 billion (immigrant tax preparation) to $18.4 billion (immigrant life decisions) without building 41 separate products. Here is the framework, the TAM math, and why vertical expansion compounds faster than horizontal.

Why do most TAM expansion strategies fail?

The standard playbook for expanding TAM is horizontal: you build product A, get traction, then build product B for the same audience. The problem is that each new product is a separate engineering effort, a separate go-to-market motion, and a separate customer acquisition cost. According to a 2024 analysis by a16z, the median SaaS company that launches a second product sees only 12% of its existing user base adopt it. The third product drops to 7%. By the fifth product, adoption is below 3%.

The math is brutal. If you have 16,000 users on your first product and only 12% adopt the second, you are spending engineering resources to serve 1,920 users on product two. Unless that second product has dramatically higher ARPU, it dilutes your focus without meaningfully expanding revenue.

At a YC-backed tax-tech startup, we faced this exact challenge. We had 16,000 users filing immigrant tax returns. Tax preparation is inherently seasonal -- 80% of revenue arrives between January and April. To build a sustainable business, we needed to expand beyond tax. But we did not want to build 10 separate products and spread our 3-person team across all of them.

The solution was architectural, not organizational. Instead of building new products, we built new views of the same underlying data. [LINK:post-42]

What is the "41 views, not 41 products" insight?

The insight came from studying what our users actually needed. We analyzed 1,885 user interactions -- support tickets, chat transcripts, feature requests, and survey responses -- and categorized them by domain. The results were striking:

66% of user questions were outside our core tax product, but 94% of all questions were connected to data we already had or could derive from the tax filing process. The tax return is not just a tax document -- it is a comprehensive snapshot of a person's financial life: income sources, dependents, addresses, employer information, investment accounts, and foreign financial assets.

The core insight: We did not need 41 products. We needed 41 views of one knowledge graph. The tax return seeds the graph. Each "view" is a different lens on the same underlying data: a tax view, an immigration timeline view, a banking eligibility view, an insurance options view. One data structure. Many surfaces. Zero marginal data acquisition cost for each new view.

How do you calculate TAM for a platform expansion?

The TAM calculation changes fundamentally when you shift from products to views. With separate products, each product has its own TAM and its own penetration rate. With a platform, the TAM is the total spending of the audience across all the domains you serve, multiplied by the fraction you can influence.

The $18.4B platform TAM is 8.8x larger than the $2.1B tax-only TAM. But the more important number is the cost to serve: because all views share the same underlying knowledge graph, the incremental engineering cost of adding a new view is roughly 15-20% of building a standalone product. According to a 2024 report by McKinsey on platform economics, platform businesses that share a common data layer achieve 3-5x better unit economics than multi-product businesses with separate data stores.

Why does vertical expansion beat horizontal expansion?

Vertical expansion means going deeper within your existing audience. Horizontal expansion means reaching new audiences with the same product. For an immigrant-focused platform, vertical expansion is structurally superior for three reasons:

Reason 1: Trust compounds vertically. If a user trusts you with their tax return -- which contains their SSN, income, and employer information -- they are 4.7x more likely to trust you with banking advice than a new app they have never used. According to a 2023 study by Edelman on trust in fintech, trust transfer within a platform is 4-5x more effective than trust acquisition for a new product. Every new view inherits the trust built by the core product.

Reason 2: Data enriches vertically. When a user asks an immigration question, their answer enriches the knowledge graph in ways that improve their tax advice and vice versa. Horizontal expansion adds new users but does not deepen the graph for existing users. Vertical expansion makes every user's experience better with every interaction. [LINK:post-42]

Reason 3: Retention locks in vertically. A user who uses one product can easily switch. A user whose tax data, immigration timeline, banking eligibility, and insurance options are all connected through a single graph faces massive switching costs -- not because we lock them in, but because the interconnected value is not portable. According to data from our own user cohorts, users who engage with 2+ domains have a 91% 12-month retention rate versus 47% for single-domain users.

What is the data moat and how does it compound?

A data moat is the competitive advantage that accrues from having data your competitors cannot easily replicate. For the immigrant graph, the moat has three layers:

Layer 1: Structured domain knowledge. The 2,400 entities and 8,700 relationships in our knowledge graph represent approximately 18 months of research, curation, and validation work. A competitor could build this, but it takes time. According to a 2024 analysis by Lux Capital, domain-specific knowledge graphs take 12-24 months to reach useful density, even with dedicated teams.

Layer 2: User interaction data. The 1,885 analyzed interactions -- and the thousands more collected since -- tell us which questions immigrants actually ask, in what order, with what context. This data shapes how we prioritize new graph entities and which views we build next. A competitor starting from zero would need to acquire users before they could learn what those users need.

Layer 3: Cross-domain connection density. The most defensible part of the moat is the connections between domains. Knowing how visa status affects tax filing is moderately valuable. Knowing how visa status affects tax filing, which affects banking eligibility, which affects credit history, which affects insurance rates -- that cascading chain of connections is extremely valuable and extremely hard to replicate without the full graph.

Moat strength = entities * (relationships / entities) * time-to-replicate Current: 2,400 * 3.6 * 18 months = high defensibility

How do network effects work in a vertical platform?

Network effects in a vertical platform are different from marketplace network effects. In a marketplace, more users attract more supply, which attracts more users. In a vertical knowledge platform, more users generate more interaction data, which improves the graph, which improves the product for all users. This is a data network effect, not a marketplace network effect.

The mechanism works in three steps. First, each user interaction reveals new questions that the graph should answer. When 200 users ask about the tax implications of cryptocurrency staking as non-resident aliens, that signals a gap in the graph that needs filling. Second, each answered question generates feedback -- was the answer helpful, was it accurate, did the user need follow-up -- that calibrates confidence scores. Third, the improved graph serves all future users who have similar questions. According to a 2024 paper by NFX on data network effects, platforms with data network effects show a logarithmic improvement curve: each 10x increase in users yields approximately 30% improvement in core product quality.

For an immigrant-focused platform, the data network effect has an additional dimension: community intelligence. Immigrants from the same country, on the same visa type, at the same career stage face remarkably similar decision sequences. When one user navigates the H-1B to green card transition successfully, the system learns the optimal sequence of financial, tax, and insurance decisions for that transition. Every subsequent user on the same path benefits from the aggregated intelligence of everyone who came before. [LINK:post-42]

What are the risks of platform expansion?

Three risks merit honest discussion:

Risk 1: Premature expansion. If the core product is not yet at product-market fit, expanding to new views spreads resources without compounding value. According to a 2024 survey by First Round Capital, 62% of failed startups cited premature scaling as a primary cause. We deliberately delayed platform expansion until the core tax product reached a 4.6 NPS and 47% retention at the 12-month mark.

Risk 2: Regulatory complexity. Each new domain brings regulatory requirements. Tax is regulated by the IRS. Banking referrals are regulated by the CFPB. Insurance is regulated state by state. A single compliance failure in any domain can damage trust across all domains. We mitigate this by leading with information (not transactions) in new domains, which has lighter regulatory requirements.

Risk 3: Quality dilution. Each new view needs to be excellent, not just present. A mediocre banking eligibility view damages trust in the tax product because users perceive them as the same system. We apply a quality bar: no new view launches until it matches or exceeds the quality of the best standalone alternative in that domain.

Frequently Asked Questions

How do you decide which views to build first?

We prioritize based on three factors: (1) user demand -- which domains appear most frequently in user questions, (2) data availability -- which views can be powered by data we already have from the tax filing process, and (3) revenue proximity -- which views have the shortest path to monetization. Immigration and banking scored highest on all three dimensions, which is why they launched first. [LINK:post-42]

Does the "41 views" approach work for markets outside immigration?

The approach works for any market where a single life event or data source connects to multiple downstream domains. Health events connect to insurance, employment, financial planning, and legal decisions. Home purchases connect to tax, insurance, maintenance, and neighborhood services. Career changes connect to tax, benefits, relocation, and education. The principle is universal: find the data-rich event that touches multiple domains, build the graph, then surface views.

How do you prevent the platform from becoming a "jack of all trades, master of none"?

By maintaining the distinction between depth and breadth. Each view does not need to be a full product. It needs to answer the specific questions that connect back to the user's core context. The banking view does not compete with full-service neobanks. It answers: "Given your visa status and tax situation, which banking products are you eligible for, and which ones will help your financial goals?" That focused framing keeps quality high without requiring a full banking product.

What is the timeline for launching all 41 views?

We do not plan to launch all 41 views. The "41 views" number came from mapping every possible surface of the immigrant knowledge graph. In practice, we will launch 8-12 views that cover 90%+ of user demand. The long tail of views -- niche regulatory questions, edge-case scenarios -- will be served by the underlying knowledge graph through the AI assistant, without requiring dedicated UI surfaces. The goal is coverage, not feature count.

How do investors evaluate a "views of a graph" strategy versus a multi-product strategy?

Investors evaluate platform strategies on three metrics: shared data leverage (what percentage of the platform's value comes from shared data versus product-specific features), incremental cost of each new surface (should be 15-25% of standalone cost), and cross-domain retention (users engaging with 2+ domains should retain at 2x+ the rate of single-domain users). Our numbers: 85% shared data leverage, 18% incremental cost per new view, and 1.9x cross-domain retention multiplier.

Published October 30, 2025. Based on the product strategy behind expanding a YC-backed tax-tech startup from a single-domain tool to a multi-domain life platform for immigrants.