The tools for building domain expertise vary quite a bit across companies, and I found the same tools ranged from excellent to effectively useless when applied across Stripe (an increasingly expansive platform for manipulating money online), SocialCode (a Facebook advertising optimization company), and Carta (a platform for fund administration and a platform for cap table management). Here are some notes about approaches taken at specific companies, followed by some generalized recommendations. (View Highlight)
Uber likely had the simplest and most effective strategy of any product I’ve worked on: each employee got several hundred dollars of Uber credits every month to use the product. This, combined with the fact that almost all early hires lived in markets that had an active Uber marketplace going, meant that our employees intimately experienced the challenges. (View Highlight)
This was particularly impactful for folks who traveled to other cities or countries and experienced using Uber there. Often the experience was pretty inconsistent across cities, and experiencing that inconsistency directly was extremely valuable. (View Highlight)
Carta has an unlimited individual book budget, and they pay for the Certified Equity Professional (CEP) test. These are good educational benefits, but are more a platform that you can build on than the actual learning itself. Teams working on products tend to develop deep domain expertise by building in that domain, but that approach is difficult to apply as an executive as I’m typically simultaneously engaging with so many different products and problems. (View Highlight)
In addition to the standard foundation of domain learning (talking to customers, digging into product and business analytics, etc), I’ve found three mechanisms particularly helpful: our executive sponsor program, reading textbooks, and initiative-specific deep dives. (View Highlight)
For our executive sponsor program, we have a C-level executive assigned to key customers, who are involved in every escalation, periodic check-ins and advocating for those customers in our roadmap planning. By design, being a sponsor is painful when things don’t go well, and that is a very pure, effective learning mechanism: figure out the customer’s problem, and then track resolving it through the company. Some days I don’t enjoy being a sponsor, but it’s the most effective learning mechanism I’ve found for our exceptionally deep domains, and I’m grateful we rolled the program out. (View Highlight)
Finally, initiative-specific deep dives have been a good opportunity to work directly with a team on a narrow problem until we solved a complex problem together. This taught me a lot about the domain, the individuals, and hopefully provided them with a better sense and relationship with me as an executive sponsoring a project they also cared about. My first big project was working with our payments infrastructure team to support automated money movement in our fund administration product, and I learned so much from the team on that project. I also know there’s no chance I’d understand the complexities at the intersection of money movement and fund administration so well if I hadn’t gotten to work with them on that project. (View Highlight)
At the time I joined Stripe, all new employees were encouraged to read Payment Systems in the US. More ambitious folks usually built a straightforward Stripe store of some sort: David Singleton created a site to sell journals, and Michelle Bu maintained a store that sold t-shirts with the seconds since epoch printed on them. Building a store was a great educational experience, but maintaining the store live was significantly more valuable in understanding the friction that bothered our users. Things like forced upgrades or late tax forms are abstract when imposed on others, and illuminating when you experience them directly. (View Highlight)
As Stripe got increasingly broad and complex, it became increasingly difficult for anyone to maintain a deep understanding of the entire stack. To combat that trend, executives relied more on mechanisms like project-driven learning on high-priority projects, and executive sponsors for key customers. They certainly also relied on standard mechanisms like talking to customers frequently, frequently reviewing product data, and so on. (View Highlight)
I met Brian Scanlan some years back, who told me that executives at Intercom would start each offsite by doing a quick integration of their product into a new website. The goal wasn’t to do a novel integration, but to stay close to the integration experience of their typical user. I still find this a fairly profound idea, and I tried a variation of this idea at Carta’s most recent executive offsite, making every executive start the offsite by performing a handful of fund administration tasks on a demo fund’s data. (View Highlight)
Chatting with one of the founders at Felt, Can Duruk, about this topic, he mentioned that they maintain an introduction to Geographic Information Systems for both employees and users to understand the domain. They also hired an in-house cartographer who helps educate the team on the details of map making. (View Highlight)
Some particularly useful mechanism for senior leaders to develop domain expertise are:
• Reviewing product analytics on a recurring basis. Your goal is to build an intuition around how the data should move, and then refine that intuition against how the data moves in reality.
• Shadow customer support to see customer issues and how those issues are resolved.
• Assign named executive sponsors for key customers. Those sponsors should meet with those customers periodically, be a direct escalation point for those customers, be aware of issues impacting those customers, and be an advocate for those customers’ success.
• Directly use or integrate with the product. Try to find ways that more closely different customer cohorts rather than just what you find most common. For example, if you only used Uber in San Francisco in 2014, you had a radically misguided intuition about how well Uber worked.
• Make an executive offsite ritual around using the product. Follow Intercom’s approach to routinely integrate the core parts of your product from scratch, experiencing the challenges of your new users over and over to ensure they don’t degrade.
• Use executive initiatives as an opportunity to dig deep into particular areas of the business. Over the past year, the areas at Carta that I’ve learned the best are the ones where I embedded myself temporarily into a team dealing with a critical problem and kept with them until the problem was resolved.
• Use a textbook or course driven approach to understand the underlying domain that you’re working in. This applies from Uber’s marketplace management to Carta’s accounting. (View Highlight)
