In E42 🎬 we’re fortunate to have Sharrifah Loren, Head of Partnerships at Census, who previously launched and led partnerships in Asana and Loom.
Our team uses these great products every single day, just like many other tech companies. It was therefore super interesting to learn from Sharrifah her insights on launching and leading channel, product, startup and other partnerships in these companies.
Including how partnerships in Asana evolved from the inception, when she started all the way up to the IPO.
If you’re building a SaaS product, this is the fireside chat worthwhile watching (probably a few times).
In this fireside chat:
Starting in partnerships
Launching and scaling partnerships in Asana
Channel partnerships vs tech partnerships in Asana
How to launch channel partnerships in a SaaS company?
Partner product integrations - who, what, how?
What does it take to become a platform and will Asana be one?
Launching and testing partnerships in Loom - SDK, product, channel and startups
Partnerships with VCs, aka Startup Partner Programs
How to build successful venture (startup) partner programs?
Monetization of startup partner programs
Partnerships in Census
How partnerships are different in a data company
Why partnerships should be about customers first
Product vs channel partnerships in Census
How should startups think about partnerships?
What is the right approach to partnerships in a recession?
Hi Sharrifah, Great to have you today. You're one of the people who I wanted to speak with for a while because you led partnerships in three amazing companies starting from launching partnerships in Asana, then Loom, and now you’re leading partnerships in Census, an amazing data company.
We've been using all of these products and that's why I'm very excited to talk with you. I would love to ask you to give us a little bit of introduction about your career, starting from consulting and how you started in partnership after that. Tell us please a short version of your story.
As you pointed out, I started my career in consulting. And that really was around companies that were going through market moving events, M&A, shareholder activism, IPOs. And at the time, I thought I wanted to go into heavier finance and go the buy side or the sell side. I spent several years doing this thing called the CFA, which is an advanced finance designation. At the end of the eight years with consulting, four years doing the CFA, I decided, I actually wanted to build something instead. And at that time, I decided to go back to grad school, and ended up going to Berkeley for an MBA. And then I moved in-house, first to lead investor relations for a FinTech company. And then to really start my career in business development and partnerships, starting with Asana. And I was the first BD and partnerships hire. When I started, maybe there were 200 people. By the time I left, there were 1,200, we'd gone public. I was ready to go somewhere smaller. That's when I joined Loom. Loom is a video messaging application, also I have led their BD and partnerships efforts, and their strategy around their SDK. I was there for a bit over a year. And I decided I wanted to go somewhere even smaller. And I really wanted to move into data applications, developer tooling. And Census was looking for a head of partnerships, and it was a great fit for my background, and to my interests. And I recently joined Census. I've been there for almost two months, although sometimes it feels like forever. And I'm loving it.
Amazing. I think we can probably spend three hours on each of your experiences. But let's try to cover all three of them briefly, and focus on highlights in the next 40 minutes or so. I think you mentioned when you started in Asana, it was a company of 200 people. Can you talk a little bit about the inception of the partnership program? How did you start? When it was, not in terms of headcount, but in other ways, when it was in the company journey, and what are interesting maybe highlights that you remember from those days.
When I joined Asana, there wasn't anyone doing partnerships, officially, different folks had done it in different capacities, BizOps, product, etc. They wanted someone to go in and really build a repeatable framework and put some structure around partnerships. And the intent was to really start with product partnerships. But the company had been building a bunch of technical debt that they needed to address. And product and engineering resources are very limited. And I was brought on to start the product Partnerships Program, ended up pivoting after maybe six months in building out their channel from the ground up. And we were really looking at sales and services, consulting firms to extend what we are already doing. And I did that for a couple of years, it then became very evident that we needed a dedicated Head on channel and a dedicated Head on product partnerships. We ended up hiring someone to run the channel, and she's still their channel leader, and she's been doing an amazing job. And then I moved back to product partnerships. And then I did that for another couple of years. I also launched a VC startup program, which had say, middling success, and I can explain more about why and then how what I learned and what I did differently at Loom. And we ended up growing the team. When I left there were three others I believe, maybe two others, it’s hard to remember it's been a minute, but I wanted to go somewhere smaller again. Once Asana had gone public and hit 1200 people, it just became. I like to build zero to one. And I wanted to do that again. And there was an interesting opportunity. That was part partnerships and part strategy, and that was with Loom leading their SDK efforts. And then, I guess a year and a half ago, I left to join Loom.
Let's talk about all these pivots, just moving briefly. Because I think it's super interesting. You started with Tech partnerships. And actually, I saw in Asana messaging boards, your messages asking about early days Slack integrations. And you can see that even right now. I'm curious, what did you learn from launching and iterating on tech partnerships? And then you mentioned that you also launched a six month channel program. I think a lot of companies are now thinking about channel, especially in the days leading to a recession or something. Why did you do that? And why was it successful? What are the attributes that you discovered that led to success of the channel program?
Taking that second question first, on the channel program, we had started feeling some pull from the market, from consulting firms that were unofficially consulting on Asana. And to be honest, the team was not that thrilled with us moving heavily into channel, because we really wanted to own the end-user experience. We thought we knew the best way to implement Asana, we had done so much research, we had all of our customers to pull from. And really, the initial goal was just to set some parameters around these individuals and firms that were already doing this work. And then it became clear that other firms, like firms that weren't currently doing it, wanted to start including work management in their tool stack.
At the time, a consulting firm might work with Dropbox for file storage, G Suite, which is what it was called then, for email client, maybe Slack for messaging. And they didn't have a work management app, because the category was so nascent. And they would look to a tool like Asana to help them basically complete their tool stack. They could go to their end users and say, “Hey, I have a best-of-breed productivity suite, you should use all of these tools and Asana being one of them”. And we stood it up rather quickly. It was very scrappy in the beginning, which is good. I think you have to build things that are manual before you can build them to scale just to prove them out. We were doing a lot of things in Asana, email, spreadsheets, it was not an elegant process at the time. But then we started getting traction, we started growing the team. And then we knew that we needed to hire someone to focus on it full-time. That's on the channel side.
And then on the product side. Product partnerships, depending on the company you're at, they vary tremendously. So product partnerships at Census, for example, look very different than product partnerships at Loom and at Asana. And in Asana, it's an interesting combination of what our customers are asking for. And this is actually where Slack came in. Because Slack had built the original integration, they built all of their original integrations, because they wanted to prove out the model of Slack being a platform. And once they started getting traction, they reached out to other partners to take over the integration. This happened when I was there. And it actually caused a lot of friction internally, because some people said we should build it. Some people said we shouldn't, if you looked at the usage, it was fine, but it wasn't great. Then there was this question of, is it not being used widely. Because no one wants it? Or is it not being used widely, because it's not built well, or it's not being used, because people don't know about it in the first place. And really uncovering what the drivers were there and then working with product to figure out how we can sequence it in the roadmap. And really, on the product partnership side, the most success that I've had is when I've worked incredibly closely with product to figure out what customers are asking for the capabilities of the API. Can we build a workflow that end users want? Are they interested in partnering although really, that's less of a priority, it's more that are we giving customers what they need?
It's a great story. Let me double click on those questions. Company wasn't that excited about outsourcing, or not owning user experience. And that's why you were reluctant to launch channel, or there were people who were not that excited to launch Channel. But Channel proved to be more successful than you thought in the beginning?
To be honest, I didn't really know what to expect. What's hard about channel for certain companies, this is the case with Asana, it's the case with Loom, it's not the case with Census. But channel partners, they make money on either the margin or the services. And SaaS applications are relatively cheap. And a tool like Asana, we intentionally built it simply. A user could get started without consultants or without any implementation support. And I wasn't sure about channel just because of that, what's the value for the partner? And it really wasn't until we launched and saw that the value was including this new technology that really made work faster. And more effective, it is really helpful to know who was doing what, and by when. And it was the product itself, which is why we were able to get some traction. But it wasn't easy. It took a long time, even after I had moved back to product partnerships, to really make inroads with channel. And I think that that's the case with many companies, there's this inherent tension that can exist between sales teams, and trying to hit their revenue targets, Customer Success teams and wanting to own the implementation or the rollout, and partners. And I think that's something that Asana is probably still dealing with today, to be honest, figuring out what customers it should push to partners versus which it should continue to own.
In terms of integrations, I think it's interesting that you mentioned that you were working closely with product teams, because I've been talking with great partnership people and some of the best ones I've actually worked closely with product. And it's interesting to hear that actually Slack builds all integrations themselves and they pushed this work to partners, it's hilarious. How did you make them successful, these partner integrations, and how did integrations with your partners actually work?
At the beginning, when you're the smaller company, you pretty much always are the one to build. And the value exchange really is we’ll build the integration with Slack, the bigger company, in exchange for exposure to their users, whether that's in an app marketplace, through formal marketing, co-marketing, or something else. And in the beginning, we built a lot of integrations. And it was very challenging to figure out how to sequence them, to figure out what the value was. And to really show, hey, integrations make sense and here's why. Now as Asana grew, Asana itself became more of a platform.
At the beginning, when you're the smaller company, you pretty much always are the one to build. And the value exchange really is we’ll build the integration with Slack, the bigger company, in exchange for exposure to their users, whether that's in an app marketplace, through formal marketing, co-marketing, or something else. And in the beginning, we built a lot of integrations. And it was very challenging to figure out how to sequence them, to figure out what the value was. And to really show, hey, integrations make sense and here's why. Now as Asana grew, Asana itself became more of a platform. And when I left a couple of years ago, now, a year and a half ago, there were in-app entry points for third parties that never existed before. And now it's our turn to give exposure to smaller companies that are willing to build, so they could then be exposed to our user base, our customers, etc. But it's still the case that, no matter how big Asana gets Google and Microsoft, they're all going to be bigger. For those larger strategics, we're always gonna have to continue to maintain them. And then as far as how we're able to show value, there are a lot of stats, Slack actually has put out many of them that show the value of having integrations as far as customer retention, stickiness, and engagement. And we really look to that to understand what is the profile of a customer that has one or more integrations installed. Are they stickier? Turns out they were, because we were able to use the integration to get our own app more deeply ingrained into their workflows.
Completely agree, definitely stickier, especially with integrations, but also embedding your product into workflow in different ways increases stickiness - we've seen it in multiple cases. Thank you so much. Didn't want to spend all our time on Asana, but I cannot omit asking two quick questions. Number one is that everyone is talking about platforms. And Asana has a lot of usage, I think it's not as big in terms of a platform like Zoom is trying to become a platform. I'm not sure if it's happened already or might happen, let's see. Do you think Asana will become a platform? This is number one. And number two is that you launched a Venture Program in Asana. What did you learn there on the Venture Program?
Starting with the first question, do I think Asana is a platform or will become a platform? It's hard to say, and this is a question that we discussed a lot when I was at Asana. And the question is, should Asana be the hub of work? And how do integrations interact with a user's workflow? Some companies, honestly, I think Zoom is probably one of them. They just want to be a platform, because they want to be a platform. But I don't think video messaging or video communication is where people start their workflows. I think Slack believes that all work starts within chat, and that makes sense. They've also proved that their platform, possible applications, like content creation tools, Notion is a great example. I could see that being a platform. Similarly, I can see Asana being a platform. Our view is just that all work starts at a project level. Our product is built around projects and tasks. The answer is yes, I do think as work management continues to increase in penetration across organizations, it will and it can become a platform.
On the venture side, the challenge that we had with venture is…. At Asana, we had a fantastic product-market-fit with startups. The challenge that we face and why I don't think we did as well with venture and this is what I changed when I had moved to Loom, I used two things, number one Asana is a freemium product, it's very good. Their free product is great, and is probably too good. And startups, they don't want to spend money in-app, if their free product is good enough. That was number one. Number two, the best way to get folks using your product is to give it away for free. At Asana, we were too worried about revenue cannibalization, and degrading our pipeline. And we gave startups a very small discount, and it just wasn't generous enough. And to be frank, you really need to give the product away at first through credits or extended trial, which you can position as a credit. Notion does a good job of this, Figma does a good job of this, Miro does a great job of this. And it's what we ended up implementing at Loom as well. And in order to have a successful venture program, I think you need to be really thoughtful about the discount that you provide, or the promotion you provide. And then the extent to which you're able to enable the VCs that are basically wrapping your product. And Miro did a good job of this, they basically gave their app away for free to VCs, to get them using the tool with their startups. Then the start-up would see the tool, then they would want to use it. And otherwise it's hard to get exposure to the portfolio companies of VCs, they're only going to push your promotion once a quarter if you're lucky. And I think if you do a few of those things, it will really help.
First of all, thank you so much for helping to build this amazing tool, we've been using Asana every day here. It's fantastic. Let's talk about Loom, another product that we use every day, like video messaging, which seems almost too easy. And everyone can record short videos, and instead of having meetings, just send a quick video message - an amazing tool. You started partnerships there. And you came with this rich background from leading partnerships in Asana. What did you do differently and how did you approach it because of that?
The program in Loom looked a little different than it did at Asana. And what I mean by that is, when I started at Loom, the goal I guess was twofold. We had traditional product partnerships, as was the case at Asana, but we also were building an SDK that would allow developers to insert a Loom button inside of their app. And then a user could just hit record, and the Loom interface would pop up, they could record a video, they could insert it, and they can view it without ever leaving the partner application. And solved these two things in parallel. The second thing, we ended up realizing that partners didn't want to surface a third party instead of their app, which in hindsight, is no surprise. But they did want native video. And we ended up pivoting that to be more of a white-label experience. And that motion, instead of being a partner motion, it was more of a sales motion. Because we're charging based on consumption. And for me that was fun, because it was quite different than just basic partnerships. Although I did both, we had integration, traditional product integrations with Slack, Notion, and others. But it was much more of what is the strategy. Why are we doing this? Do we want to own the end user? Are we eroding our own user base? What's the value of providing this? If all these other applications, like Slack is a great example, if they build native video themselves, is that an existential threat for Loom? That was a fun exercise that was quite a bit different than what I did in Asana. In Loom, I had also explored channel, but it didn't make sense for the reasons I had mentioned earlier. It just was too easy to use, and the product was too cheap. Firms weren’t really interested in using it. And then I also did a Startup Venture Program at Loom, which ended up being more successful, because it took some of the lessons that I learned, particularly around enabling the VCs and around just giving it away for free. They were able to get more traction, which was great.
You might argue that Slack is almost a consumer product. I think now, with the Salesforce acquisition, they're now more moving towards B2B. You can see that in their messaging. And Loom is almost also like a consumer-ish experience, and I think that's probably why it was difficult to do partnerships. And then I guess, recently, with Clubhouse audio, and the same with Loom, everyone just copied multiple things from a bunch of different apps. And I can see that just happening at scale now, which is surprising. But maybe double-clicking on the Venture Program, if you will be willing to share a few things. Tell us a little bit more about venture programming Loom and then we talk about Census.
If I were building a Venture Program, at a productivity software solution like Loom or Asana, or any of those applications, there are a few things that I would do, having learned what not to do in prior companies. The first one is - the volume is going to be low and so revenue cannibalization is going to be limited. And you should give it away for free. And this is a really hard thing to convince sales leaders of. And because they're just worried about hitting their numbers. And the way I was able to work around that at Loom was to limit the headcount of those that could avail of the deal. But to be honest, I think some people think that a venture program is like a silver bullet, it's just going to inject growth into a company. It's not. It takes a really, really long time. That was one, you need to have your leadership team on board, and you need to convince them. They used to give it away for free, otherwise, startups won't pay for it. The second one is how do you think about enabling of the portfolio companies? And it really just depends on how easy or hard your tool is to use. For Loom, we could enable the VCs, give it away for free, show them how to use it, so they could use it with their portfolio companies. And that's how we're able to get a lot of traction. If you are able to do that, that is great.
The third thing is you do not need to hire someone and build all of these frameworks and use any tech solution to get started. It's really easy to take someone and have them dedicate 20% of their time. You'll get enough signal if it's worth investing further. Some companies, they just again think it's a massive unlock. They'll throw resources at it. And it just takes a long time to scale. It probably takes 12 months before you start seeing meaningful revenue from that channel. And just being really mindful of that is important. Otherwise, your expectations and the expectations of leadership, they're going to be out of sync with reality. And then you'll get the wrong signal that is not worth investing in when in fact it is, it just takes a long time to actually hit that growth trajectory.
Through OnDeck we are using Loom quite extensively now and getting into a special program, like OnDeck invested in us and through that we got Loom, really unlocked our usage. I'm curious, the promise you as a partnership leader keep in your mind that as soon as more people use it, some of them will start paying for it. And then your revenue will gradually grow.
The way we thought about monetizing this startup program is we give it away for six months for free up to 25 seats. We expect either expansion for those that use it and grow beyond 25 seats. Or we look for conversion once six months have passed. And we used nurture campaigns, we did a lot of office hours. Other types of enablement. When the six-month mark did occur, they were already using it heavily. It's that much harder to leave. I think that was a pretty big win as far as converting, because what you don't want is a bunch of folks just using it for free, and then churning as soon as they hit whatever threshold or paygate that you've set. It's really important to make sure that the startups are actively using your product. And you can use all BI tools to do that. And then if they're not using it, either do some light touch marketing motion, or a higher touch sales assist or something like that.
Make sense, thank you. Let's talk about your current company. Census. I think Asana is a little bit more B2B, Loom was a little bit more consumer still B2B. Census is back to more B2B. I'd love to hear your explanation - how do you explain Census to your friends?
That's a hard question. Census is what's called a reverse ETL. And it basically takes the data from your data warehouse, Snowflake, BigQuery, Redshift, and it pushes to the operational tools you use every day - Salesforce, HubSpot, Zendesk, etc. A use case might be, “hey, I am an AE in Salesforce, but I want more than just my Salesforce data living in Salesforce. I want to see how the customers are using the product, I know which products they're using. I know when to reach out to them, I can see if they're about to hit some rate limit in their usage of a product, and I can see what a health score might look like. And what I'm able to do is use Census to pull product data from Snowflake and push it into Salesforce in this instance. The sales reps have a 360-degree view of the customer. That's an example. People use reverse ETL tools as CDPs as well. They also use it for support tickets at Loom. Loom is a heavy census user, they use it to make sure that they're prioritizing the right tickets within Zendesk then they can actually turn the tickets faster.
Your target user is probably the growth stage to enterprise companies. Multiple things that are very, very interesting about Census. Number one is that generally speaking, I'm really curious about data economy. And it seems that there was a time not long ago when everyone was talking about data is new oil, and then it seems that this conversation slowed down, even though the amount of data actually is growing. And I think there's just more exciting things on the horizon, like AI and stuff like that, but I think data is very interesting. I’d love your overview of how your partnership program looks right now? Because you started leading this partnerships function, and it's actually called Business Development and Partnerships. I think it's the very beginning, business development is much more important. It's much more figuring out stuff. Tell us a little bit more about your partnership program.
What's interesting, and I think this is the case for many data applications. But unlike Asana and Loom that are standalone products, you don't need to use an integration to get value out of them. Census is basically a pipe between two applications, and we only exist because of partners. And the structure of the partnership itself looks quite different. In productivity tools, especially those that are standalone tools, most of them, Miro, etc. the value is really around engagement, churn reduction, and improving retention. Sometimes you can drive top of funnel through co-marketing, sometimes you can drive sales, but less frequently. In Census and as the case for others in what we call the modern data stack, Fivetran, Snowflake, DBT. There is actually clear business outcomes that are tied to revenue and pipegen, that wasn't the case with the earlier companies. Right now, what might happen is a customer is talking to Snowflake, or let's say they're talking to Fivetran. And Fivetran is an ETL tool. Fivetran actually takes the data from Salesforce, pushes it into Snowflake. A lot of times the customer will say, hey, Fivetran, and get the data out of the tools into the database. But how do I get the data now from the data warehouse back into the tools I use? And it's a really natural conversation or thing to bring up, when they talk about Census. Oh, do you use a reverse ETL tool? We don't currently do this, you should check out Census. The same thing with Snowflake - customers go to Snowflake and say I have all this great data inside of Snowflake. How do I activate it? How do I use the data? And then they would refer our reverse ETL tool. And it's almost a loop or a data flow. You start with an operational tool, an ETL tool pushes it into a data warehouse. Maybe there's some modeling with DBT, maybe events get pushed in, and then reverse ETL pulls it back out. And then the data again gets pushed back. Really, the value of Census to a partner is greater, because we help complete that data flow. And when I look at our partners, we still have channel partners and product partners. But the product partners act more as channel, they send us leads, we send them leads, we do a lot of AE mapping, we try to find joint accounts to go after together, and we do a lot of co-marketing. Partnerships are more integral to tools that exist within a flow of other tools. That's number one. Number two, because the category of reverse ETL is so nascent, marketing and co-marketing with larger players is essential to category creation. And we work with all these big players in part because people don't know about reverse ETL is an option. How do we create the category? How do we drive awareness? How do we get folks to know about our tool in the first place? And partnerships are critical there. And again, Asana and Loom, they're standalone products. They were creating categories, they were pretty small, but they weren't nearly as small as Census is in that space. And partners are just incredible megaphones for growth.
It's been a great explanation, talking about data partnerships and data economy, what are the interesting things happening there, and especially on the “collaboration between companies” side.
It's interesting because again, with Asana and Loom, it's just the bigger companies have so much more leverage in the relationship. But Census provides a value that's different, which makes us more valuable to large players. Now there's still that balance, but because we get data into Braze, Mixpanel, Salesforce, HubSpot, Zendesk, faster, and the data is of higher quality, and there's more of it. Customers get value out of their tools faster. It makes sense for these, we call them destinations because where we push data, it makes sense for them to want to use a reverse ETL to get data to populate their applications faster. We actually provide a product value that is directly connected to the end user, it's time to value for them. Similarly, on the source side, where we pull the data from, it also provides value because customers say, now I have this data, what do I do with it? And there's really nothing that Snowflake or BigQuery can do themselves. Then they partner with reverse ETL tools. And we're really that last mile solution. But as a result, this size is less of an issue than it is with other types of tech products in the data space.
Data is really interesting. As far as what I see, for the future of data, I think data is going to become increasingly important to how we work every day, we're already seeing it in the numbers. And I mean, Census we're 65 people, we’re really small. And when I think about how companies are going to become increasingly sophisticated with data, data is going to become increasingly important to their business and driving business outcomes. I actually think that we're going to see an acceleration and growth in data. And we're seeing it now, but we will continue to see it in the coming quarters years ahead. And as part of the reason I actually wanted to move explicitly from productivity and collaboration into data and developer tools.
What’s interesting about what you have mentioned about the value to customers, the second you have a higher value to customers, I think your partnership conversation becomes very different.
What I think, were a lot of partnerships, and it's not usually the teams that get it wrong. I think a lot of executives are thinking about partnerships incorrectly is when they only think about what's in it for them. What can this partner get us? When in actuality, especially larger partners, they don't care about you, all they care about is their end customer. And if you can figure out how to position an opportunity in a way that speaks directly to what they care about, and in most cases is their customer, have a much greater likelihood of winning that partnership actually doing something. And to your point for data, and for the desk for actually both the sources, the data warehouses, data lakes and the destination, there's a clear value that it provides for their end user, whether it's speeding up the sales cycle, making a time to value all of that, it makes the sell a lot easier, they sell on the partnership side.
To wrap up on the Census side. I just want to check that I understand everything, because I'm a big student of partnerships. You partner with this destination and also sources right. And they both serve you as tech partners and channel partners at the same time?
Well, we have traditional channel partners. We have consultancies, agencies, data firms that are traditional channel. But when I think about channel, channel is really just a way to get revenue, a way to get leads, a way to generate pipeline. And in the data space, technology alliances provide that same benefit. They both have similar outcomes. Whereas in productivity, typically, the outcome of a product partnership is product-centric, it's around usage of the product driving engagement, driving retention. Whereas in data, of course, we want to drive usage of the integration, it drives consumption for our sources, but really, it’s how do we work with our partners to grow the pie for both of us? How do we generate revenue for all partners? It's less product-related and more sales, marketing related.
KPIs are different, in productivity, you typically have usage and retention. And while into the more B2B data context, you will have more rev share and also obviously, customer stickiness, and delight maybe.
Exactly.
Let's move on to the last few questions of our conversation about you're working with startups. You were part of two amazing angel programs. One of them is First Round Angel Program and the other one is the OnDeck Angel Program, and you advise and invest in startups. Typically startups, ask, “I want to do partnerships. and you've been in partnership with all these great companies. I’m a startup CEO, what do I do now? And I'm building a B2B SaaS, how should I think about partnerships? What is your typical answer to that?
Honestly, it depends on your size. But partnerships should be secondary to your core product. I think what happens is oftentimes, C-suite, investors, they think of partnerships as a way to increment growth or accelerate growth or achieve any kind of growth really. And what they don't think about is all of the investment that is required to actually do some of these partnerships whether it’s on the tech and integration side or on the marketing side, convincing larger partners to work with a startup, many won't. Unless your company is built on other companies, sort of in the way Census is. They had partnerships are really critical early on. But I would say that's more of an exception than the rule. It is helpful to have someone at least thinking about partnerships. And for startups it is important because partnerships are often the first entry point into a potential acquisition. And whether or not there's a real partner opportunity there, it's a great way or great Trojan horse to just kick off conversations about the two applications with the two companies together. Then down the road, if that is an exit you want, you have already paved the way using partnerships. I think, I wouldn't over-invest in partnerships too early, but they're worth building, at least in a lightweight way, so you could open up a conversation for when you are ready, whether it's a partnership itself, or a potential acquisition.
I'm also curious about how you think for an early-stage company, or maybe a growth-stage company, the importance or difficulty of doing partnerships during this potentially recessionary time? For one hand, partnerships are becoming more important, but for the other hand, it is also not a fast process. How do you think about it?
You're right in that it feels partnerships are more important than they had been before. And what I mean by that is, I hear companies looking for partnership leaders, partnership managers all the time, a lot more than I used to. I think the value of partnerships if you can get it right is there and it's more widely accepted. But to your point, it's a long cycle. If you want to do a partnership with a larger company, and you're a series B, or series C, it could take 12 to 18 months. And then, the outcome is really uncertain. And I think people always overestimate the near-term value of a partnership. Really, partnerships is a long game. And it's just important to keep that in mind. And to really think about the value of the partner to your specific organization and the value of your organization to a specific partner. Certain industries, like data developer tools, if you again live between other products, partnerships is critical to success. And it can be a massive lever for growth. But that's not always the case. And you need to make sure that you as a company have value that you're providing the other partner, because that's the only way you'll get them to agree to do anything.
Great, Sharrifah. It's been a fantastic conversation. And we can continue for much longer, but I want to be mindful of your time. I'm sure that some people, many people would love to connect with you, what is the best way to connect with you?
Connect with me on LinkedIn, you can also just email me, which is my first name @getcensus.com. In full transparency, I'm going out on maternity leave, I don't know when this is going to air. I'll be out through the rest of 2022. There might be a delay, but feel free to email me or get in touch via LinkedIn. And I'm happy to chat.
Thank you so much. I look forward to seeing you succeed in Census and building a great partnership program in 2023. And really excited to maybe do it with you again at some point. Thanks so much.
That sounds great. Thank you so much, Roman.
Comments