Bob Moore, CEO and co-founder of Crossbeam, on ecosystem-led growth

At Crossbeam, we took it further with "Partner Base," designed to be like Crunchbase for partnerships. We created a massive directory of companies and their partnerships, resulting in landing pages for individual companies and their specific partnerships. Today, Partner Base has over 90,000 companies and 300,000 partnerships represented, delivering more traffic than all our other content assets combined.

The other significant insight was about ecosystem-led growth. At RJMetrics and Stitch, we realized that partner ecosystems were crucial for customer referrals and delivering value. However, the strategy for growing partnerships lacked data. It was challenging to determine shared customers or potential collaborations without oversharing sensitive information.

This realization led to the idea for Crossbeam: a secure, independent platform that acts as an escrow service for data between collaborating companies. Crossbeam ingests and transforms data, allowing companies to maintain control while unlocking valuable insights about buyer intent and potential partnership opportunities. This new data layer has been a significant breakthrough and is fundamental to why Crossbeam was started in the first place.

Can you talk about the inspiration behind Crossbeam? Not just where the idea came from, but what inspired you to really commit 5 to 10 years of your life to building this company? And perhaps help us understand the conviction element – that human element behind it?

It's so true. One of my taglines for Crossbeam has always been that this company could never have been founded by a first-time founder. The pattern recognition across multiple environments, not just where the market opportunity was but also how to solve the problem on the product side, was an extremely unique intersection of what we learned and saw at RJMetrics/Magento and then at Stitch/Talend. This business is the perfect Goldilocks combination of those two experiences coming together.

Even if somebody else had come up with the idea independently and was a first-time founder, a huge part of getting Crossbeam off the ground was solving the cold start problem that exists in any network effects business. Crossbeam, if you think about how it works, is kind of like LinkedIn for data. How bad would LinkedIn be if you showed up and nobody was there? There's no value proposition if there are no other people. So what do you do when there are no people?

Seeding that network graph turned out to be an exercise in basically cashing in all of the relationship capital I had built up over the last 15 years. I asked a lot of our former customers, former employees who went on to work at other companies, and former investors, saying, "Hey, I'm really trying to get the first cohort of companies onto this thing. Will you take a chance? I know you can't take a chance on this idea yet, will you take a chance on me?" Had I not spent the last 15 years building up all that social capital to spend, I'm not sure I could have been in a position to make it come together as quickly and tightly as it did, with as many really good, big brands as the cornerstones of it.

So what you're saying is totally right. A has always informed B, and then B has informed C, and it's always continued in that way. I'd say the other thing that's true in the background, though, is that the one thing all these companies have in common is that they really lit up my brain. The problems themselves were fundamentally really interesting.

RJMetrics was interesting because at the time, I was learning on the job. I started that company not even knowing that the word "dashboard" was something you could use to describe what it was, not even knowing the phrase "business intelligence." I just knew that I was really into SQL queries and how to optimize them, and also the ways in which you could take fairly dirty, abstract data coming out of various systems and turn them into really interesting insights. That was my job, by the way, prior to starting RJMetrics. I was an analyst at a venture capital firm doing exactly that, which is where I met Jake.

This problem space for RJMetrics really lit up my brain, and then we spent all this time at RJMetrics basically getting good on the job, falling down and breaking our noses plenty of times along that way. But that was kind of like our version of business school. In the course of doing so, you just get this really weird, specific knowledge of otherwise wonky, somewhat boring industries. One of those was how all this data moves around and what data pipelines actually are, and what they represent in terms of where things are going in the bigger tech cycles that are out there.

That observation for Stitch was kind of just a byproduct. It was like exhaust coming off of the RJMetrics ambition. Technically, Stitch was an RJMetrics spin-out. We had a product called RJMetrics Pipeline that was kind of like the early version of Stitch.

When we did the deal with Magento, part of what we arranged with them was our ability to continue pursuing that idea because they weren't really interested in that part of the product. So Stitch got a bit of a head start because of the RJ journey, and it got a really interested, passionate team who cared a lot about a kind of objectively boring problem space, which I think was also an unfair advantage.

With Crossbeam, it was kind of a clean sheet of paper. I probably should have taken a vacation and gone and sat on a beach for some amount of time prior to doing it, but this problem lit up my brain. It had everything that I loved and had the most fun doing and dealing with at RJMetrics, and I just couldn't stop thinking about it. It had network effects, it had vitality, it had these really cool content marketing play opportunities like with Partner Base, it had category creation and the ability to basically define a category for something that never existed before. It just sounded so fun and refreshing to go try and solve this really ambitious problem that, frankly, was pretty contrarian in conception.

I got laughed out of a lot of VC offices trying to start a data sharing company in the same month that GDPR went live. It doesn't seem like the kind of thing that meshes well with the surrounding market conditions, but as it turned out, it was something that the market really needed.

Could you define ELG in short? How do you define it when talking about it with other founders?

It's really simple. If you are leveraging the data or relationships from your partner ecosystem to generate more leads, close more business, or grow your customers, then you are doing ecosystem-led growth. It really is about the practical applications of leveraging your partner ecosystem to grow faster. It's that simple. I try to keep that label on it, which is a fairly broad label, but intentionally so. There's this specific and important constraint that exists there, which is: could you have done this if you didn't have your partner ecosystem? If the answer is no, then it's probably an ecosystem-led growth play.

Is there a canonical example of an ELG company? For the companies that are doing it really well, what does that look like?

As canonical examples go, it's almost like you could pick one in every vertical. If you look inside the universe of places where I've played historically, I was in the data analytics and modern data stack universe. There's an example in the Ecosystem Led Growth book about Fivetran, who ironically was Stitch's number one competitor back in the day before we got acquired.

I think Fivetran and the story they tell about their ELG strategies is a really exemplary model for how to think about growing with the ecosystem front and center. This includes identifying market opportunities, pursuing accounts, and determining when and how to use intelligence from partners to go at it alone versus enlisting partners to help win business. There are some great stories and quotes from their CEO George that really hammer that home.

Then you look over in a totally different industry like e-commerce, where RJMetrics was involved. There's another amazing ecosystem effect going on in the Shopify ecosystem. You look at the way in which the major e-commerce platforms have emerged and evolved. Magento bought RJMetrics; they're a company that was disrupted in many portions of the market by Shopify.

One of the major things Shopify was able to do, because they deliver their platform as a purely SaaS product through the cloud for all use cases, as opposed to Magento's open-source model with many on-premise installations, was build an extremely consistent, easy-to-scale app store partner ecosystem.

People could basically plug in technologies, features, and functionality into the experience of building Shopify sites or the buyer experience for people purchasing through them. This cloud delivery model, participating in the modern API economy, gives a subtle but profound effect in how you scale the value story and value proposition of your products.

Now you look around, and the ecosystem surrounding Shopify is immense. So much so that almost no companies went public last year, except Klaviyo. What's Klaviyo? It's a giant Shopify partner; their market is Shopify's market by and large. In one of the early earnings calls for Klaviyo after they went public, ecosystem-led growth was specifically cited by their CEO. There was a big set of comments around the importance of their participation in that ecosystem and using it as a growth lever. I absolutely love that; it's a shining example.

You can also look at Procore, which is in the book. Procore is construction software, another publicly traded company that's the dominant player in this vertical SaaS category with significant scale. They've been really innovative, a huge ELG proponent, and there are a lot of great case studies for how Procore does ELG in the book as well.

So, pick your vertical, and I'll show you your shining company on the top of the hill. They're probably the one that's winning, by the way.

In the past, companies like Rippling and Ramp might have been partners because one does payroll and one does cards. Now they both do cards and some aspects of bill pay and vendor payments. How do you see this dynamic playing out? How do companies think about these shifts in partnerships and competition?

There's this great Jim Barksdale quote - he was one of Marc Andreessen's collaborators at Netscape, among many other accolades. He says, "There are only two ways to make money in software: bundling and unbundling." I think one thing that is true of the modern cloud era is that it brought on a great unbundling cycle.

Consider RJMetrics: we were an all-in-one kind of suite solution. We would do the ETL, the data warehousing, the data modeling layer, and the dashboarding. If you think about how people solve for that problem today, there's been an incredible unbundling effect. They buy Fivetran to do the ETL, put it into a Snowflake data warehouse, put dbt on top to do the modeling, and then use Looker or Tableau for BI. I should plug Omni here, which is a kickass next-generation dashboarding tool founded by some RJMetrics and Looker alums. So one product becomes four products - a great unbundling cycle.

But you keyed into something that's happening in the market: sometimes there are precipitating effects that bring on the next phase. If the API economy brought on an unbundling cycle, there's been a question of whether AI will bring on a rebundling cycle. A lot of things that made it sensible for companies to get hyper-specific with narrow value props that interact with one another - maybe it's not as hard to do a lot of this stuff anymore.

If you look in different categories, your Rippling example is perfect. The HR universe has become significantly unbundled, and Rippling is effectively a rebundling approach to providing a better, more tightly integrated user experience. It's almost like the Apple approach back in the day: we're going to do the OS, we're going to own the software, we're going to own the hardware. I think there's a resurgence of that showing up, and I'm curious to see how AI plays a role. It's just going to be easier if you have one copilot interface driving you through doing the best version of your job, where all the underpinnings might actually live under the same hood. That'll be fascinating to watch.

Regarding competition within certain markets, I think we're going to see more of that. It's going to be an important dynamic. I'm a capitalist and a free market believer, and I think this is not a black and white situation. Every company at every moment in time needs to make decisions that are optimal for them in pursuing their markets and building shareholder value. You will go through many transitions and relationships in the course of building a company where your enemies become your friends and then your friends become your enemies. It's important to closely monitor and manage that, but it's absolutely not black and white.

There are time periods where you may be directly competing with a particular partner on a particular use case in a particular market, yet in another market, you might have zero footprint whatsoever. They are a fantastic on-ramp for you to access that customer base or gain visibility among a certain cohort of folks. Both of these things can be true at once, and figuring out how to split that atom is really important.

Not to shamelessly plug Crossbeam here, but this is one of the things that Crossbeam is great at. You can create those Venn diagrams in a way where you've pre-filtered by geography, use case, and customer segment. Some partners you only show totals to, some partners you show account names, some partners you show more. Some days you want to turn it on, some days you want to turn it off. The control of those feeds can be extremely dynamic and curated. It's a huge part of the reason why Crossbeam has overtaken the classic account mapping strategy in a lot of companies because it can't be the wild west in an environment where these situations are so dynamic. So yeah, you struck a chord on a really important thing there.

GDPR, iOS privacy updates, and data privacy movements in general have made zero-party and first-party data much more scarce. Has this actually been a major tailwind for companies like Crossbeam? Such platforms enable companies to gain access to some of this data through partners and also build workflows around privacy management, ensuring compliance.

For sure. These are all things where a company, depending on its own relationship with its customers, their expectations and entitlements around the treatment of their data, and their regulatory environment, needs to assess these risks for themselves and make their own decisions. That said, what we offer as a platform is something that allows people to set up the right collaboration strategy across company lines to fit into and conform to whatever those requirements are.

In many businesses, there are some really critical agreements that exist with partners, such as partnership agreements or NDAs. There may be circumstances where certain classes or categories of partners, with a certain level of engagement or established rules of engagement, may be entitled to more access, information, or transparency than others. Alternatively, they may need to be much more strictly and tightly controlled.

Another important consideration is GDPR and CCPA. While not exclusively, they're chiefly concerned with personally identifiable information (PII) - characteristics that allow you to associate online activities with a specific human being and their identity. In the vast majority of cases with Crossbeam, PII is actually not even present at all. The identity of human beings in these customer relationships is optional to connect, like the contacts object or table in Salesforce, for example.

When you think about it, what it really comes down to is business relationships. It transcends individual people; people leave jobs, enter jobs, and jump from company to company. If Company A is using Company B's product and they have purchased a services agreement from Company C, that relationship will likely persist beyond the time span of any particular person being there. While people are critical to buying decisions, there's also this underpinning that sits at the business relationship level, which is where the initial core unit of value comes from.

You might want to attach contacts to that, and you can choose to do so based on all the conditions I described before. But even if you decide you don't want PII within 100 miles of this collaboration with a partner and you really just want to talk about business relationships between companies, then it's just a question of determining your level of comfort and appropriateness with having that information make its way to a partner. Depending on your partner agreements and customer agreements, you choose your own adventure there and set up Crossbeam accordingly.

Do you think of the third-party layer of data, like Clearbit data, as related to the data layer that you're building? Are they additive or complementary? Do you compose them, or are they two separate things? Is one approach saying, "This information comes directly from customers and partners we work with, and we rely on that," while the Clearbit-style data is just a bunch of information used to spam people? Or do you combine them? How do people typically think about this?

There's so much to unpack here. First of all, let's talk about an industry that has gone through a rebundling cycle. If you rewind the clock a year and a half, think about these four companies: Gong (call recording software), Outreach (SDR automation for cold outbound), ZoomInfo (a data broker for third-party data), and Clari (a forecasting tool). These four companies, on paper, are partnered with each other. They work closely together, have the same target buyer, and operate in specific swim lanes around how value gets created for these businesses.

However, if you look at all their websites today, they look exactly the same. They've all become "revenue orchestration platforms," which is the category term that Gartner has coined and most of them are latching onto. It turns out that now ZoomInfo has acquired Chorus and has call recording capability. I should have named Apollo instead of ZoomInfo as an example. Apollo is starting to do a lot more workflow tasks, helping people send outbound emails and things like that.

Everybody's trying to get into the analytics and forecasting game, and everybody's got their hand in everybody else's cookie jars. It's interesting how they're all going after the bigger total addressable market (TAM) in a rebundled world, and a lot of them have these AI agents that are designed to be overlays for that purpose. It's a perfect example of this trend.

So where does Crossbeam fit into all that? There's an important differentiating factor when it comes to our data: it's second-party data. All of the data that those other platforms use are some combination of first-party and third-party data. First-party data is data that you already have, reconstituted in some way to figure out how to do certain things. It's great, entirely proprietary to your business, but also entirely limited to stuff you already know, so it's not additive.

Third-party data is like the contact records you would buy from ZoomInfo or Apollo, or maybe the intent data from companies like 6sense. But if you buy it, you're likely going to buy the same data or data from the same source that your direct competitor is also buying. If you want to get a contact at Microsoft you're trying to sell to out of ZoomInfo, anyone can buy it. There's an incredible commoditization and lack of proprietariness to the data.

Contrast that to the second-party data that comes out of Crossbeam. There are 19,000 companies on Crossbeam, and no two companies get the same data because what data you're getting is a direct byproduct of who you are partnered with and what data they have allowed you to see. This creates a really nice cyclical effect where the companies you're partnered with happen to be the ones whose data you care the most about. They are also the ones where you have alignment around ideal customer profile, value story, and winning together.

By virtue of being on Crossbeam, you get this very rich data that's as rich as your own first-party data but has the proprietariness and newness of third-party data. It sits right there at that second-party, curated, definitionally proprietary-to-you sweet spot.

Does Crossbeam fit within the realm of those revenue orchestration platforms? I think the answer realistically is yes, if not from a direct competition standpoint, more from a philosophical alignment point of view. The objectives of the go-to-market leaders in all of these cases are to grow their businesses faster and more efficiently, and I would say that's part of, if not the core value proposition of all of those tools, including Crossbeam. So in that way, we do fit into that market, even though we haven't historically been associated with it or carved out as a major player in it. But life is long, and things can change.

Do you think some of the positioning on Crossbeam's site is like, "Hey, we're for partnership people, but it also helps drive revenue"? How does your buyer think about it? Do they think, "I'm buying something for my partnership people," or do they think, "I'm accelerating revenue, and then I'm going to give it to my partnership people"? How do people reconcile the partnership and revenue operations perspectives?

We were really intentional about this actually. If you look around the universe of companies that sound or feel similar to Crossbeam prior to its existence, it's an absolute graveyard. Many have attempted to build something like this, and they've all failed. We studied a lot of those companies, and I met many of the founders who tried it. They had a couple of things in common.

One of them was that most didn't try to do this at the business-to-business relationship level. Instead, they attempted it at the person-to-person relationship level, more like the LinkedIn network graph, trying to be a smarter, better, richer substitute that serves salespeople or sellers to make their way to certain people through the graph.

There are several reasons why that's really hard, and LinkedIn has a huge moat there. There are also reasons why the value of any individual output from that graph is actually limited or capped. There's a negative-sum game effect around relationship capital that's necessary, which isn't really true on the business graph.

Here's another mistake that people made: Many who didn't succeed tried to build something in this universe and went directly to salespeople as their target market, bypassing partnership people. From an immediacy or path to revenue standpoint, it's really smart. Salespeople are a better market - they have more control over their destinies, agency, and budget. They have larger teams and larger budgets, so everyone would rather sell to sales teams than partnership teams.

However, what became clear from many companies that didn't make it in that space is that once the sales team buys in and the value seems real, you need to actually get the data. This data requires connectivity between companies across company lines, which is completely controlled by the partnership teams. Sales teams are not well-equipped to do this and often enlist the partnership teams to get that work done.

When it comes down from sales teams to say, "Hey partner team, go use your relationship capital to create this network graph or data model," it's looked upon by the partnership teams with some skepticism. They're basically being asked to expend resources as opposed to owning something and taking credit for it.

Our approach was to say this is going to be a business that comes together in two or three acts. Act one is about the partnership people. Nick Mehta, a mentor of mine from Gainsight, did a brilliant job with the customer success manager persona, taking it from a bespoke title used inside Salesforce to basically an entire industry. He built out all the content marketing, events, and everything else around it. I talked to Nick several times, and we decided to run his playbook within the partner universe.

For the first five years of the company, we essentially ran a mini media company helmed by Sean Blanda. We did events, blogs, specialized content, benchmarking reports - all the things. We did an annual survey with salary data so people in the role could benchmark against each other, as there's not usually great salary data for those roles in major tools. We built rapport with that partner persona, which was great for the growth of our network graph.

This allowed partner people to claim ownership and pride around the establishment of the Crossbeam graph, as opposed to feeling like it was designed to squeeze value out of what they had already built. It was an embodiment of their relationship capital instead of a consumer of it. This continues to be true to this day. Partner people are awesome, and they're a massive percentage of our end users.

We've now transitioned into act two of this business, where we build concentric circles of alignment within companies. It's become a multi-persona product. Partner teams can use the platform to derive a lot of value directly in their own jobs, but our best customers, where Crossbeam becomes most instrumental to their growth, are the ones where the partner team is this enabling layer.

They're almost like the ops layer bringing the data asset to life, and then it's actually the sales leadership and go-to-market leadership that figure out how to operationalize all of the outputs of that network graph inside their actual teams.

We've got things like sales reps consuming the data directly, sales leaders using it to forecast and make bets, and so forth. This has been an intentional journey, but act one was a five-year journey to solve the cold start problem and get the network graph off the ground.

You alluded to the rise of open APIs and partnering with companies through API integration. We've talked a bit about integration ecosystems and marketplaces, of which Stitch was an early example, and we've discussed Fivetran. What are you seeing in terms of the value of an integrations marketplace?

The power law is definitely in effect for many of these things. There's no such company where 80% of the usage, consumption, and value delivered through their integrations and partners is delivered by 20% or less of the people actually involved. I think you have to approach this from your buyer or user perspective, not the other way around.

Having a bunch of integrations is a really poor vanity metric. Having a marketplace with 1,000 integrations is meaningless if you don't know who's using those integrations, how many of your customers actively derive value from them, what they are, and how you're investing in them to make them even better and more valuable.

The smartest companies are the ones who identify that they don't need 5,000 partners. They need a finite number of partners that have a wildly disproportionate impact on what adds up to the majority of their customer base. You're right that it's increasingly easy to have a seemingly impressive number of touch points to other products.

For example, if you have one Zapier integration, you could theoretically automatically have 1,000 partners through that middleware layer. But it bears out in the data too. There are some companies on Crossbeam who are connected with over 1,000 partners, but most companies, I think, are using Crossbeam to connect with only 7 to 9 partners. For the average enterprise company, it's in the tens or dozens, not even in the hundreds.

This is because there's been an identification of a wildly disproportionate opportunity and impact from a finite set. In fact, they use Crossbeam to figure this out. As with all things, like cold emails, the easier they are to do, the more of them you're going to see. But the ones that always matter the most are probably still going to matter a lot, and the smarter bets are the ones to make those impactful ones even more effective.

Is there a way for someone building a SaaS product to enable people to do partnerships inside their product by connecting to something like Crossbeam Connect? Second, is there potential for a company like HubSpot to build Crossbeam-like features to enable its own customers to share data?

A couple of things: I'll start with the second half of that because this is always a classic VC question that every company gets: "What happens when Amazon builds this?" or "Why doesn't Salesforce or HubSpot build this?"

I'm a big believer in the innovator's dilemma, and I've seen it exist in many circumstances. The reality is, I get asked about Salesforce probably more than HubSpot because a lot of this involves CRM data for mid to late-stage enterprises. Salesforce is a phenomenal company, but they have mainly grown their product capabilities through acquisition over the course of the last 10, maybe even 20 years. There are not a lot of new products that come out of their internal operations.

For something to rise to the level where you would make internal investment to develop a new product, one thing has to be true: you have to really point to a reason why this is going to be a multibillion-dollar line of business within a finite number of years. Otherwise, it just doesn't move the needle for that company.

The reality is, a category creation play like this one needs some time to prove that it's actually a billion-dollar industry. Right now, it's not. We're in the 8 figures of revenue at Crossbeam, and that's awesome—we're really happy about that. But Salesforce spends 8 figures on breakfast the first morning of Dreamforce. It lives in a different world.

The bigger question would be: What's the dynamic in the market itself, and is there a risk that we have a competitor that gets acquired into one of these companies and becomes a big initiative? Even then, I would love to go toe-to-toe with any acquired company inside a bigger mothership because the operating constraints that appear are real and material. I think they make it harder to compete with a well-funded startup.

My answer to the VCs was always, "I don't think they will, but if they do, bring it on." I think that's typically the best way you can answer that question.

Regarding the first part of your question about network effects and virality and the different forms they take, can you put a finer point on that?

If I'm a SaaS company, let's say I'm a mid-market company like Campaign Monitor, and I want this feature in my product but don't want to build it, is there a way for me to integrate with Crossbeam in the future?

So, this gets very meta. I'll make a couple of broad statements. First, network effects as a growth strategy are really difficult to bolt on to an existing company or business model—I'd say it's nearly impossible. However, network effects can take many different forms.

The network effects across Crossbeam are proper network effects. It might as well be a social platform like Facebook or LinkedIn. The way in which people derive value from the product is directly related to how they engage in building the network. These two aspects are joined at the hip, and if the product is successful, it will inherently contribute to the strength of the network.

There are other smaller elements of network effects that many companies can access. One of them is virality on the user acquisition side. A great example is the early days of Dropbox in the early 2000s. Dropbox would give you storage, and then if you referred a friend, they would give you another 10 megabytes of storage for every friend that signed up. This created an incredibly viral loop for their product. However, the core value proposition of Dropbox after that sign-up had nothing to do with your friends or who invited whom. Ironically, today Dropbox is a bit more network-oriented with the dynamic sharing that exists across different parties, but back then, it was primarily a backup solution for individuals and their own data.

Regarding whether people can use the knowledge, data, or practices from Crossbeam to propagate their own virality and product success—definitely, but with caveats. It may amount to something more in the category of virality or user acquisition, or really specific plays to contribute to network effects within an organization. For example, we want to cross-sell from the sales team into the customer success team and leverage those internal relationships. You get these little tastes and benefits of network effect "pops," but I don't know that just infusing that on top will inherently make you a network effects business. I think it's more of a force multiplier on your core model.

If everything goes right for Crossbeam and ELG, what does it look like in 5 years? And how has the world changed as a result?

It's a great question. I think about this on two dimensions. First, ubiquity: there are literally no companies that aren't on Crossbeam because it would be foolish not to be. Not participating in the Crossbeam network would inherently mean missing out on some pretty fundamental growth patterns that most companies need to survive.

The other dimension is another form of ubiquity, but it's more about diversity and personas. It's ubiquity within organizations and massive adoption by the go-to-market team specifically.

When I think about it, if Act 1 was the partner teams and Act 2 is getting into these go-to-market teams, our Act 3 is this very interesting ecosystem play. The data coming from Crossbeam is not just powering value for the partner teams and go-to-market teams directly, but there are actually entire other businesses being built on top of the data derived from the platform. These are value propositions that could not exist without being powered by the data coming out of Crossbeam.

We're starting to see some cool stuff going on with people consuming our API data downstream. We've had a bunch of companies show up and build into our API specs to offer add-on solutions. A lot of them so far have been in the partner tech space, but we're seeing a couple of startups in the sales and go-to-market arena. I expect that to continue and grow. I think five years from now, that may actually be the primary growth driver of the business, but it requires that ubiquity step as a prerequisite for the TAM to be worthwhile for these companies to pursue.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.