Sachin Rekhi

When I went to college I knew that my ultimate aspiration was to found my own tech startup and in order to prepare myself for that goal, I decided to pursue a dual-degree at the University of Pennsylvania from both the engineering and business schools. I studied computer science in the engineering school and ultimately settled on finance at Wharton. While I may have been better served studying marketing or management, I did learn some important finance principles that I still use day-to-day in my product management role. I wanted to share three such principles that I find incredibly relevant to product.

Finding the arbitrage opportunity
One concept that we often talked about with respect to trading was finding arbitrage opportunities. An arbitrage is basically buying low in one market and simultaneously selling higher in another, profiting from a temporary difference. For example, buying an antique in Florida and re-selling it for a higher price in California would be a simple arbitrage opportunity.

I find myself always evaluating every growth channel on it's attractiveness as an arbitrage opportunity. We often talk about how in growth you can't simply re-use a list of tactics for your own product because the channels are constantly becoming saturated, over-run, and thus less effective. And thus you need to be constantly scouring for new growth opportunities and determining whether an arbitrage opportunity continues to exist. For a SaaS business this may be specifically determining whether you can acquire a customer at a cost of acquisition (CAC) that is well below the customer's ultimate lifetime value (LTV), thus re-creating the "buy low" and "sell high" opportunity. But more broadly, I think it's important to leverage this mindset for all businesses. When evaluating a channel, how saturated is it? Are there many folks already exploiting the channel? Does the arbitrage opportunity remain? For example, Atlassian was successful early on in going directly after developers in driving their initial acquisition via free/cheap open source editions that could be installed on dev boxes. This was in stark contrast at the time to their competitors that were largely focused on getting tools into organizations via the IT organization. This helped them grow very fast initially. Many others copied this approach of marketing primarily to individual developers, like New Relic and Twilio, resulting in several companies going IPO via specifically exploiting the developer channel. Yet now, everyone is embracing developers as a key audience to go after, even coining it B2D (business-to-developer), and the arbitrage opportunity is not nearly as attractive as it used to be.

Leveraging modern portfolio theory
In investment management, we studied the idea of modern portfolio theory, which states that an investor can construct a diverse portfolio to maximize expected return based on a given level of acceptable market risk. The key was that while diversification could help mitigate risk, it came at the cost of expected return. Risk and return were directly correlated. While I leverage this theory as the basis for managing my personal finances (via Wealthfront), I find it also applicable to product.

I think about my product's roadmap as a modern portfolio, where I'm constantly balancing risk/reward across a diverse portfolio of product initiatives. And at each stage of the product lifecycle, I'm re-assessing the acceptable level of risk to guide the portfolio of initiatives to include in each product cycle. As soon as you launch your product, prioritizing initiatives becomes far more challenging because it's not as simple as doing the one most important thing because you're constantly balancing bugs, performance/scale issues, poor performing functionality, customer feedback, brand new features, and entirely new products. There is no steadfast rule that can be applied to guide which items should be included in the upcoming sprint. That's where I find portfolio theory helpful, thinking through the right allocation of resources across these various initiatives and what's appropriate for where the product is at. Maybe you just launched and your pre-product/market fit. Then your portfolio may be heavily weighted towards improving the existing experiences to get them to resonate. Or maybe you're further along your journey for product/market fit and can now think about allocating a meaningful portion of resources to new features/products to expand the market opportunity. While I'm not calculating expected returns during this process, thinking through initiative allocation across each category of investment is extremely helpful.

Assessing performance against stated strategy
Probably the most important finance principle I learned wasn't from a class at Wharton, but from Andy Rachleff, the CEO of Wealthfront. One of the things we often talked about at Wharton was the difficulty of assessing an investment based on past performance. We've all seen the disclosures saying "past performance is not indicative of future performance" right before we evaluate an investment based on it's historical returns. We often talk about the hot hand fallacy, which is the false belief that someone who has achieved success with a seemingly random event has a greater chance of future success. Yet this remains what we are effectively doing when judging future performance based on past performance. And while we've countlessly shown what's wrong with this approach, we continue to leverage it as the main mechanism for evaluating fund performance.

But is there a better way? Andy Rachleff, based on his years as Vice Chairman of Penn's university endowment, is convinced there is a better way. The approach is to evaluate fund performance on whether it outperformed based on executing faithfully on an a priori stated strategy and whether the outperformance was specifically driven by that stated strategy. If this is true, then those funds that do outperform in this way do most often see repeated success. As in then past performance does become indicative of future performance. The challenge from an investment perspective is its almost impossible to get this level of data and insight that you would need to evaluate based on this approach (unless, say, you are a prominent university endowment).

So what's the application to product? Well, we are constantly looking for best practices to replicate when building our own products based on the success of other products, but we often conflate their success with the supposed best practice that they leveraged to achieve it. Sometimes a product's success is not because of a specific tactic that they employed, but may in fact be in spite of it. So when trying to find repeatable best practices, I constantly look for lessons where I can determine that the team a priori had stated a specific strategy that they faithfully executed on and there success can in-fact be attributed to that very strategy. Only then do you have "outperformance against stated strategy" that can be used as a repeatable lesson for your own endeavors. As an example, I remember when the hamburger menu became a popular design choice for mobile apps. Apps started to incorporate it into their apps as a clean way to extend their navigation beyond the few items typically shown in tab bar navigation. The approach became especially popular when Facebook embraced it in their application. I saw so many more apps starting to adopt it after this point. And I imagine many product teams justified the approach based on Facebook's usage of it. Yet recently we've seen so many applications move away from this approach, including Facebook, as A/B test after A/B test has shown that the hamburger menu reduces discoverability and engagement when used as a primary form of navigation. This was a case where folks were leveraging the best practice of using hamburger menus for primary navigation as exemplified by companies like Facebook without in-fact ensuring that this tactic itself was resulting in success for Facebook or not. Facebook wasn't successful because of the hamburger menu. They were successful in spite of it.

I hope this gives you a few frameworks from the world of finance that might be as helpful to you as they are for me in product management.