Prototype built to test a product hypothesis around just-in-time advisor enablement.

Product Specialist OS

Complex products are hard to explain when advisors only see the cases occasionally. I built a system that turns client context, product knowledge, offering facts and firm guidance into what an advisor needs to know, say, ask and confirm before the next conversation.

Watch the demo View Product Specialist OS →

The problem

Financial advisors may only encounter 1031, DST, 721 and Opportunity Zone situations a few times a year.

The knowledge exists. It is scattered across product decks, offering documents, tax resources, firm guidance, wholesalers and specialist teams.

The hard part is not finding another document. It is knowing what matters for this client, what to say, what they are likely to ask, what still needs confirmation, and who should answer the part you cannot.

The thesis

The product specialist should be available before the product specialist is needed.

Advisor Enablement combines client context, product knowledge, specific offering facts, firm-approved guidance and what is still unknown — then prepares the advisor for the next conversation.

Software prepares.
Humans decide.

Watch the case change

The Advisor Enablement Platform showing Miller Family with Acme DST I: what changes for Miller, what to say, and the questions the client will probably ask

View Product Specialist OS →

Miller and Rodriguez are considering the same offering.

For Miller, debt becomes the key unresolved issue. For Rodriguez, debt disappears completely and liquidity becomes the lead concern.

Same product.
Different client.
Different conversation.

The same offering, two clients

Miller

$1,600,000 existing debt

Acme DST I allocates $400,000 of debt at the modeled investment amount.

The system does not conclude whether that solves the exchange requirement. Instead it prepares two questions:

Sponsor / product specialist

“How much replacement debt would Miller receive at the intended investment amount, and can the investment size be adjusted?”

CPA / tax counsel

“How should Miller’s debt relief and replacement structure be evaluated for this exchange?”

Rodriguez

$0 existing debt

Debt disappears from the conversation entirely.

Liquidity becomes the lead concern, because Rodriguez says liquidity is important and Acme DST I has no contractual redemption program.

Ask next

“How much of the sale proceeds could you comfortably leave inaccessible for the expected hold period?”

The same offering applied to Rodriguez Family: liquidity leads the list and the debt section is absent — The same offering, applied to Rodriguez. Liquidity leads. The debt section is gone.

Why this matters

Generic AI can explain what a DST is.

The useful layer is knowing which client facts matter, which offering facts change the conversation, what the firm has approved, what is still unresolved, and exactly who should answer the unresolved part.

Who it changes the day for

The advisor: Walks into the conversation knowing what matters for this client, what to say, what they will be asked, and what still needs a human. Less time reconstructing client context before every call.
The product specialist: Fewer repetitive calls explaining the same structure, and fewer incomplete escalations. The questions that do arrive carry the client facts, the modeled assumptions and the specific unresolved issue — so the time goes to cases that genuinely need judgment.
The firm: Product expertise reaches more advisors without adding specialists at the same rate. More consistent use of approved language and materials, and a shorter path from a client question to a clear next action.

No usage figures are claimed. This is a working prototype, not a deployed system with measured results.

What the advisor gets

60-second product refreshers
Client-conversation prep
Likely client questions
Plain-English talk tracks
Offering-specific context
Firm-approved language
Prepared specialist questions
Explicit unknowns instead of invented answers

Product principles

Value before data collection.
Teach the product in the context of the client.
Show only what matters now.
Never turn an unknown into an answer.
Software prepares. Humans decide.

What I learned

I initially exposed too much of the underlying case system in the interface. It was technically capable and commercially confusing.

The breakthrough was narrowing the job. The advisor does not want to manage the case. They want to be ready for the conversation.

Once that became the product definition, the interface got simpler and the value became much clearer.

What I did

Product strategy: Defined the user job, product wedge and interaction model.
Domain model: Mapped 1031, DST, 721, Opportunity Zones, offering facts, firm guidance, client state and specialist routing.
UX: Designed the advisor-readiness flow around what to know, what to say, what they’ll ask, what to ask next, and what still needs a human.
Build: Used AI-assisted development to implement, test, iterate and deploy the working product.
Evaluation: Built scenario-based tests around real advisor situations, offering-specific facts, client differences and bounded unknowns.

Under the hood

The front end is intentionally simple. Underneath, the system maintains client facts, product knowledge, offering facts, firm guidance, provenance, unknown state, specialist routing and stale-state dependencies.

It is deterministic where reliability matters, and it refuses to fabricate missing product or tax conclusions.

Interested in product enablement, complex-product distribution, or building systems that make expertise easier to use?

Explore Advisor Marketing Partners → ← Back to the work