> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What's next

> Where Introw is heading and why: the directions that decide what we build next, tied to the bets behind the product. Direction, not dates.

> Where the product is heading, and why. This page is deliberately about direction rather than dates: it tells you which problems we are moving toward, so you can judge whether Introw is building toward the program you want to run. What has actually shipped is a separate, factual record - the [release notes](/release-notes), updated every month.

## How to read this page

* These are **directions, not commitments**. Priorities move when what we learn from customers says they should.
* There are **no dates** here on purpose. A roadmap with dates is a roadmap that lies twice: once when it slips, once when we build the wrong thing to protect it.
* Each direction ties back to one of the [bets that decide what we build](/introduction). If a direction does not serve a bet, we drop it.
* For what is real today, read the [release notes](/release-notes) instead. That is the honest record, month by month.

## Where Introw is heading

<CardGroup cols={2}>
  <Card title="Partners get themselves connected" icon="plug" href="/why/time-to-value" cta="Time to value" arrow="true">
    Today a partner program starts moving when someone chases each partner. We are pushing toward partners arriving, connecting, and getting productive on their own, so the size of your program stops being limited by how many people you can put on chasing it.
  </Card>

  <Card title="Money moves end to end" icon="money-bill-transfer" href="/why/low-tco" cta="Low TCO" arrow="true">
    Introw already calculates what partners have earned from your CRM and billing data. The direction is the whole path in one place, from what a partner earned to the partner actually being paid, without the spreadsheet in the middle.
  </Card>

  <Card title="The steps join up" icon="diagram-project" href="/why/ai-native" cta="AI-native" arrow="true">
    Registration, approval, enablement, and reporting are separate steps today, each waiting on a person. We are working toward the handoffs between them carrying themselves, with your team approving rather than assembling.
  </Card>

  <Card title="Both CRMs, the same depth" icon="arrows-rotate" href="/why/crm-native" cta="CRM-native" arrow="true">
    HubSpot and Salesforce should not be a tier list. We are closing the remaining differences so the CRM you already run on stops being a factor in what your partner program can do.
  </Card>

  <Card title="Governance you can still read at scale" icon="shield-halved" href="/why/enterprise-grade" cta="Enterprise-grade" arrow="true">
    Programs on Introw already run into the tens of thousands of partners, and answering "what does this partner get, and why" is now one screen rather than an audit. The direction is keeping it that legible as programs keep growing.
  </Card>

  <Card title="Enablement that stays current" icon="graduation-cap" href="/why/work-where-you-are" cta="Work where you are" arrow="true">
    Partner content goes stale faster than anyone can maintain it by hand. We are moving toward training and enablement material that is cheap to keep accurate, and that reaches partners in the tools they already use.
  </Card>
</CardGroup>

## What we are deliberately not building

Direction is also what you refuse. These are settled, not open questions:

* **A portal-first product.** The portal stays optional. Partners who prefer their own CRM, Slack, Teams, email, or an AI assistant get the same program through those instead.
* **Anything that needs a consultant.** If a change to your program cannot be made by the person who owns the program, we consider it unfinished.
* **A second source of truth.** Partner data lives in your CRM. We are not building a parallel database for you to reconcile.

## How to influence what we build next

The fastest route into this list is your partner manager or your CS contact. Requests that come with the actual shape of the problem - the object, the field, the step your team keeps doing by hand - land far better than a feature name, because they can be built once and serve everyone.

If you want the factual record of what changed rather than where we are going, the [release notes](/release-notes) carry every customer-facing change, month by month, each linked to the docs that explain it.