Prospect to Proposal

A prospect's portfolio isn't worth the usual setup — until they say yes.

Wealth managers need to sell as much as they need to advise. After an initial client meeting, they're expected to analyze a prospect's holdings and come back with a compelling case — but the company's platform had no tool built for that moment, so advisors built the case themselves, by hand, in Excel.

Existing clients already have their portfolios loaded into the platform — typically through white-glove onboarding, though advisors can also do it themselves — and that data becomes usable across any of the platform's other applications. That process doesn't serve prospects well: uploading a portfolio properly is cumbersome enough that doing it for someone who hasn't committed to becoming a client isn't worth the effort, especially if they say no.

So advisors filled the gap themselves — bouncing between spreadsheets and whatever other platform applications they needed to reference, during exactly the window when they most needed to move quickly and look credible.

The application was meant to close that gap: giving advisors a way to quickly upload a prospect's holdings, run analysis, and surface recommendations that could help the prospect see a better return — cutting out the manual work and the app-hopping in between.

Every workflow on the platform assumes a portfolio already exists. Prospects break that assumption completely.

This wasn't a missing feature so much as a missing category — the platform's analytical depth, and the company's own biggest selling point, had no on-ramp for a client who didn't exist yet.

Every dashboard, every analysis, every downstream workflow on the platform depends on portfolio data already being in the system — a prospect falls entirely outside what the platform is built to handle, which meant the fix needed something closer to a new front door than a small addition to an existing tool.

That mattered beyond convenience. Deep data coverage is one of the company's central selling points, which meant the moment with the highest stakes for a wealth manager — proving they can deliver more value than a prospect could get elsewhere — was the exact moment the company's own core differentiator wasn't actually available to them. The opportunity wasn't just to save advisors time; it was to close the gap between what the company was known for and where that reputation actually showed up.

The platform's core strength — depth — was exactly what a prospect-facing tool couldn't afford to lead with.

The tension wasn't technical difficulty; it was a genuine values conflict. The platform's differentiator is thoroughness. But a prospect might say no, so the tool built for them had to prioritize speed. That conflict showed up concretely in two open questions: what to do with holdings the platform couldn't fully recognize, and how much analytical depth advisors actually wanted before a decision got made for them.

That tension surfaced in two concrete places.

First, coverage gaps: the securities most likely to trip up analysis weren't obscure edge cases. Private equity, hedge funds, and energy infrastructure vehicles are common holdings for exactly the kind of prospect a wealth manager is courting, and they don't have the standardized market data the platform's analysis depends on. Blocking the flow on an unrecognized holding would have undermined the tool's entire premise of a fast first pass — so the design had to find a way to approximate rather than halt.

Second, an open question the team never fully resolved: with a data platform this broad behind the tool, "more" was almost always technically possible. The harder question was what advisors actually needed at the moment of a sales pitch, versus what simply could be shown because the data existed.

A senior team, a first-time product owner, and real friction over what "helpful" actually means.

I led design with one direct report — a senior designer — reporting to me, partnering with a product manager who was newer to building and shipping software, and a senior engineering lead running a team of developers. The effort was sponsored by a group of product managers in the company's wealth product group, and ran for roughly over a year. Real friction surfaced early: feature creep, requirements drawn more from conversations with the sales team than from direct user research, and stakeholder pushback that sometimes favored personal preference over usability.

Some of what made this project genuinely difficult wasn't the interface — it was the conditions around it. That inexperience led to real assumptions about what kind of data users would find helpful, some of which held up and some of which didn't. Because the platform's data depth is one of its core selling points, scope discipline was a constant, active argument rather than a settled principle — narrowing what the tool showed was something I had to keep making the case for, not something the team agreed on from the outset.

Requirements didn't always arrive settled, so my direct report and I ran regular working sessions using rapid Figma prototypes to think through vague or partially-formed requirements before bringing anything to the PM and engineering lead — using the prototype itself as the way to pressure-test what the workflow actually needed to account for. Sometimes that process surfaced places where the two of us had quietly drifted out of alignment with each other, and prototyping together was what pulled us back onto the same page before a review.

The proxy security workflow is where this mattered most for the whole team, not just the two of us. The deeper we got into designing it, the more open questions surfaced — what should happen to a security's weight once it's excluded, how much of that should be automatic versus left to the advisor, what a user needed to see to trust an analysis that wasn't fully resolved. When we brought a working Figma Make prototype to the PM and engineering lead, they realized the workflow involved considerably more moving parts than they'd originally scoped it to be. From there, the prototype went in front of other stakeholders, who were able to clarify what the workflow actually needed to account for — turning something that had arrived as a single line item into a shared, specific understanding across the whole team.

None of this was adversarial in a way that stalled the project — it was closer to a team still building its own product muscle, and part of my job was pushing back constructively where it mattered (a broken workflow, an accessibility issue, a case for validating an assumption with users) while picking my battles elsewhere.

This one reached real users — further than the trade lifecycle project got.

Unlike the earlier proof of concept, this shipped: released internally, then out to lighthouse clients, where it entered an active feedback stage. That feedback wasn't fully processed before my visibility into the project ended.

Feedback that came back before I left centered largely on requests for additional features, which the team made a deliberate call to defer to future iterations rather than build immediately — a sign of the same scope discipline that had been a point of friction earlier in the project, now working in the product's favor.

What happened after I left — whether it led to a broader rollout, further iteration, or measurable impact on how advisors close prospects — isn't something I have visibility into.

A complete product, live with real prospects and real advisors — with the final chapter outside my view.

I can state directly that a full, working product shipped, reached lighthouse clients, and entered active feedback. What I can't speak to is what came after: whether that feedback led to broader adoption or measurable impact on how advisors close new business.

What I can state directly is that a complete product shipped end-to-end — upload, proxy resolution, model comparison and customization, and report generation — and reached real lighthouse clients, further than the trade lifecycle proof of concept managed to get before my involvement in that project ended.

The more honest framing of this project's outcome isn't a business result — adoption, revenue impact, or advisor satisfaction are outside what I have visibility into — but a demonstration of what it took to get there: turning a genuinely difficult set of working conditions (an inexperienced product owner, real feature creep, requirements shaped more by sales conversations than user research, stakeholder pushback rooted in personal bias, and a genuinely hard data-coverage problem in the platform's alternative-asset gap) into a coherent, shipped product, while also growing a direct report's own judgment along the way.

The same instinct, twice — and a chance to teach it directly.

Pushing to connect this project to the company's existing portfolio management application, instead of letting a newer product manager's team build a competing one, was the same integration-over-duplication judgment that shaped the trade lifecycle project. Here, I got to apply it earlier, and pass it on.

The same instinct showed up on a smaller scale in the proposal tool's report builder: reusing an existing report-generator pattern surfaced a data-lifecycle mismatch between prospects and onboarded clients, and I flagged that gap the same way, directly and early, rather than waiting for it to become someone else's problem.

That same dynamic — using the work itself to teach, not just to ship — ran through how I managed my direct report over the year. She had been having a hard time resolving her own disagreements with a product manager, so I used this project as a chance to show her directly how I navigate that: when to push back hard (a workflow-breaking issue, an accessibility gap, a pattern chosen from bias rather than evidence) versus when to let a genuine open question ride into user feedback instead of forcing a resolution I wasn't sure of myself. The model-comparison decision is a good example of the latter — swapping one candidate model at a time gets advisors most of what a true side-by-side view would, but not all of it, and rather than push further to force a "complete" answer, I let that gap stand as a real question for lighthouse clients to weigh in on.

Working within the platform's own limitations — an internally built grid that couldn't deliver the Excel-like experience users expected — was a similar kind of discipline: designing honestly around a real constraint rather than either pretending it away or refusing to ship until it was fixed.

If there's one thing I'd want a reader to take from this project, it's that judgment showed up on two levels at once: technical and structural calls, like scoping the model-edit workflow down to something buildable, or integrating with an existing system instead of duplicating it, alongside the less visible work of navigating an inexperienced stakeholder group and deliberately growing someone else's ability to do the same.