Product
September 9, 2026

A Friday in February

Sam Garrison
Director of Product Management @ Savvy
In this article

Ritik and I were up at 4am arguing about what to build. We had a doc full of AI concepts scored against each other, he'd just told me the one we picked wasn't compelling enough, and he was right. Twenty minutes later he made the only useful suggestion available at that hour: stop scoring and go ask a few advisors.

At 5:14 I sent the same paragraph to two of them, describing something that didn't exist. Instead of opening planning software and entering data, you'd talk through a client situation out loud and watch the plan build as you went.

One of them answered in 12 minutes. He'd been up too.

We went back and for in discussion for an hour, and by the end he'd refined my concept with his own experiences. Complicated clients he could handle; his problem were the 300 households he can't get to, and the good idea that applies to clients he won't think to check. He told me about April 2025, when the market dropped on tariff news and he ran Roth conversions early for the handful of clients who came to mind, then spent the next week wondering which ones he'd missed.

That was a key use case. It came from an advisor at 6 in the morning after we had gone back and forth with something tangible.

By lunch I had a prototype, with chat and voice working and the charts  that were mostly working. I sent it to Ritik with a note that I wouldn't be upset if we scrapped all of it. The advisor had asked when we could start testing at 6:15 that morning. He was testing it on a call later that evening.

Twelve hours from an advisor's problem to that advisor clicking on the answer.

What survived was his framing of the problem

The prototype was disposable and we threw it away eventually, but the problem he handed me stayed. Four weeks later that same use case was a demo in front of 24 advisors, and on April 14th, we launched the first version of Savvy Intelligence to all of our advisors.

He describes it as something he helped build, because he did. That's the part I'd take over the speed. Once an advisor recognizes their own thinking and experience in the product, they stops filing requests and starts designing with you.

A day like that was impossible everywhere else I've worked. For three years I ran product at a company I believed in and helped build, where "we'll build that" meant a fundraise and a user telling us something was broken started a conversation about money we didn't have. Our roadmap was a negotiation with our funding and our org chart, and the thing we promised in January was still a bullet on a slide in July.

That day is the method now

Prototypes come before specs, because a prototype answers the question a spec only argues about. We build them fast, put them in front of advisors early enough to be embarrassing, and throw them away. Then we write the spec from what the advisor changed, break it into scoped work, and let agents run most of the build.

Then we ran it across the whole org

One person and one advisor in one day is an anecdote. In April we tried it with all of engineering.

We paused feature work for a week and had each person carry projects end to end (scope, build, test, ship) instead of passing work from the PM who writes the spec, to the designer who mocks it, to the engineer who builds it. We'd been working in agentic tooling for months by then, inside a shape of work where three calendar weeks disappear into the seams.

165 projects in 7 days. 423 code changes, 4 times a normal week. 88% of the feature requests advisors had voted on over the previous 2 months, addressed.

That week was a ceiling test, and the point was keeping whatever survived once feature work restarted. Most of it did, and we haven't let up since.

Two things here are hard to copy

Any team can buy the tooling we use, and most of them will.

The first is where you're standing when an advisor tells you something is wrong. Our advisors are in our Slack and often in the building. That February morning started with a DM before dawn and an advisor willing to spend an hour teaching me his job.

The second is whether you own the thing you'd have to change. Advisors everywhere else rent their software from vendors serving thousands of firms, so a feature request joins a queue behind all of them. We own the CRM, the system of record, account aggregation, financial planning, tax, and the advisor-facing AI, and we're building our own custody layer now. So when an advisor tells us a report is wrong, there's no vendor to wait on and no round to close. There's a decision about when.

There's a version of financial advice that's been sitting just out of reach for 20 years, because nobody owned enough of the stack to build it and moved fast enough to keep advisors' trust while they did. I've spent most of my career being the reason a good idea had to wait. That's not the case anymore.

The only thing our advisors ask us for now is a little less speed. This spring a room of them told us the pace of improvement was running ahead of their ability to absorb it. They loved the product. They wanted room to fold it into how they actually run their practices.

It's rare for your users to ask you to ship slower. It's the best problem I've had.