Ideate, Design, and Iterate
An update on how Arbor has been developing in the lead-up to our launch.
Perhaps the most challenging aspect of building Arbor has been choosing the right problems to solve first. Our website launch in early July jumpstarted a month-long push to develop prototypes for Arbor’s research and management tools by the end of August. That plan remains underway with one slight caveat: a product is never perfect. Yes, we are aware of the naïveté exuding from that sentence, but allow us a moment to explain ourselves. Like all good clichés, you never really internalize them until you have lived them.
What has become obvious to us is that the first thing we put out will not be the last. There are too many issues to resolve and too little time to resolve them all. As we said, the challenge lies less in fixing them than in choosing which ones to focus on. Recent team meetings have covered everything from never-ending UI/UX choices to the engine behind our content production and even as far as long-run scalability. Those discussions cleared up one notion: “Rome wasn’t built in a day.” We needed to hone in on exactly what Arbor v1 should accomplish.
And that’s exactly what we did
While we might be naïve, we are simultaneously an action-oriented team. Constant ideation, designing, and iteration have led us to have quite a few working attributes as part of our v1 release.
Our research tool, currently under the working name Atlas, is progressing at a strong pace. Atlas is being built as the starting point for investment research when you log on to Arbor. With that in mind, we were faced with three crucial decisions: the user flow, the content, and the goal.
To address the first, we’ve combined our native design language with the way analysts actually approach research; from our experience, things boil down to beginning broadly then going deep. Atlas will flow from one stage to the next, with each stage serving as a different layer of the analysis, allowing users to see a wide snapshot but also go deeper if they feel up for it. Atlas will enable users to customize their research workflow based on their preferences. That means your dashboard and Atlas experience will look nothing like anyone else’s.
The second made us think about the information itself. We could get Jony Ive to design Atlas and it would still be meaningless without credible content.1 As such, we’re actively improving the engine behind our sentiment and fundamental analysis. To do so, we’ve designed an architecture to systematically rate and compare equities across a multitude of sectors. The effect will be twofold: Atlas will provide you with a benchmark for when you research, and also improve the quality of the experience. Personalization will help you see what matters to you, and our composite scoring system will give you insight seldom found elsewhere.
Finally, we needed to connect research to action. Arbor’s mission has always been to provide retail investors autonomy and a firmer basis for their decisions. As a result, Atlas will help users turn research into a living investment thesis. Any time something in the market catches your attention, you will be able to research and then log that idea, revisit/revise it over time, and receive updates when we realize your convictions are being tested. In this way, you don’t just track prices, but ideas themselves.
Our portfolio management tool, currently under the working name Meridian, was touched on briefly in our previous article. Little has changed in the ideation, but the process has moved into implementation at last. That’s not to say that things have been “smooth sailing,” though we never expected otherwise.2
Meridian’s core function lies in enabling users to decompose portfolio risks, stress test under scenarios, and then optimize with respect to constraints using institutional-grade techniques. In order to successfully deliver on these use cases, a primary step is estimation. So far that has been most of the work, and most of the trouble: getting the covariance and return estimates right through methods such as shrinkage and winsorizing in order to reduce noise.
The short version is that every clever thing we want Meridian to do sits downstream of one unglamorous step: estimating what the problem’s inputs actually are. Get that wrong and everything after it inherits the error with complete confidence, which is the worst possible combination. It’s hard to overstate both the importance of this step and its difficulty. But then again, challenges are what make building Arbor worth it.
Arbor v1 – imperfections included
We know how Atlas and Meridian will function, and we have a concrete direction and a set of issues to resolve in time for launch. Arbor v1 will not be perfect, in fact it will be far from it. Nonetheless, it is our belief, or rather our hope, that the first interactions users have with our product will teach us more than we’ve learnt in the past few months building it. After all, the fastest way to perfect is to fail fast. The countdown to launch is live on our site, and the waitlist is open for when v1 lands.
Team @ Arbor
Although after seeing his work with the Ferrari Luce we thought it best to design Atlas ourselves…
Funnily enough, the term “smooth sailing” is predominantly uttered by those who have never sailed.