Skip to main content
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, 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. If a direction does not serve a bet, we drop it.
  • For what is real today, read the release notes instead. That is the honest record, month by month.

Where Introw is heading

Alongside these, the work launched this autumn keeps growing: Introw Pay toward more ways to pay and an approval before money moves, the in-Salesforce experience toward more of the program on the record, and Partner Connect toward a partner’s own pipeline staying in step with yours, both ways.

What we are deliberately not building

Direction is also what you refuse. These are settled, not open questions:
  • A portal-only product. The branded portal stays the home of your program: it is where most partner activity happens and where you define what each partner may see, do, and earn. It is never the only way in. Partners who prefer their own CRM, Slack, Teams, email, or an AI assistant get the same program, under the same rules, through those, which is what running Introw headless already means today.
  • 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 carry every customer-facing change, month by month, each linked to the docs that explain it.