A few weeks ago, I hosted the 2nd session of a monthly Company Building webinar series for founders and operators of developer-focused and/or commercial open source startups. The goal of this series is to share tactical knowledge -- the nitty gritty know-hows that can make the grinding experience of company building a little easier for entrepreneurs -- from experienced operators who are still in the game (Our 3rd session will be on April 6, 10AM US Pacific Time, with Justin Cormack, CTO of Docker, to discuss managing and scaling engineering teams. Please REGISTER HERE).
The topic of this session is the considerations of building a global company from Day 0. The expert panelist is Clint Smith, Chief Legal Office at Discord, former SVP of DataStax, ex VP & General Counsel at MySQL, and advisor & investor in many startups.
To make our wide-ranging conversation more useful and digestible, I edited and condensed the session’s transcript into the following topics (jump to the section that's most relevant for you):
- Clint’s Background
- Global Product Competition from Day 1
- Bundling with A Rising Platform
- Myth of Product-Led Growth
- A Contrarian View on Partnership
- Building A Global Team Operationally
- Compensation Philosophy
- Should You File Patents
You can find the audio/video version of this conversation on the Interconnected Voices YouTube channel or watch it below:
Kevin: I’d love to open up with some of your biographical background, so people get to know a little bit about you. How many years have you spent working in enterprise and open-source technology companies? And what was your path into this really wonderful world?
Clint: Thank you for having me. I've been looking forward to this because I'm a big fan of yours. We met through OSS Capital and through supporting some commercial open-source companies that were just getting off the ground. We worked together at Preset, the Apache Superset company that's doing great. And I also love the fact that you bring a global outlook - like your global newsletter and your recent trip to Mexico. I'm the son of a US diplomat. I was born in Spain and I've lived in South America, Europe, and Australia. I like bringing a global perspective to these discussions and I know you do as well. So I think that's a bond we share here in Silicon Valley.
I was trained as a lawyer. When I was starting my career at a law firm as the lowest minion in Washington, DC, this partner, Stewart Baker, then the General Counsel of the National Security Agency, came out of government to the law firm where I worked. So he started a private tech law practice with a lot of encryption, a lot of surveillance, a lot of interesting issues. He needed a helper and I was the most junior person, but he brought me along and exposed me to all these fascinating tech clients. And I fell in love with product managers and engineers. I thought the most interesting work on the planet was helping them think through the legal, regulatory, and public policy aspects of getting their products built and into use. And even since then I've worked for a series of technology companies that I was drawn to because they were interesting.
The first was UUNET, the world's largest internet backbone that's now part of Verizon Business. Then I was at Macromedia. You might remember Macromedia Dreamweaver. Macromedia Flash has finally died, but it played a lot of videos before it was killed. And I worked with Adobe and then MySQL, maybe one of my favorite companies - we'll talk about that. And then payments startup TrialPay with Alex Rampell, who's now a partner at Andreessen Horowitz. It was a wonderful team, a tough market, but we powered through and got to an acquisition by Visa. And then most recently, DataStax, the company behind the Apache Cassandra open source database, and now Discord, the popular communications platforms. All of them are high growth with good people and products of impact in the world.
Global Product Competition from Day 1
Kevin: I want to jump into our first discussion item. Both of us have really strong global perspectives. I think one of the things that I'm seeing a lot with early stage developer-focused companies and/or open-source companies is that they're getting users from around the world on almost day 1. And they are also probably competing with similar projects or products from around the world from day 1, even when they are super tiny companies. I'd love to hear from your perspective: how do you think through a global product positioning in this day and age to help young startups think through this new situation, which is full of amazing opportunities, but certainly a bunch of challenges too.
Clint: I'll use two examples from my career: MySQL, the open source database, and TrialPay, an alternative payments platform.
I think if you're going to divide startups, some of them are attacking a well-known space. The product category is well known but they have some new twist to it. That was MySQL attacking the relational database market. There have been relational databases with DB2, Oracle, and Sybase - no shortage of that at all. And there, the incumbents have huge advantages. They have contracts with every company in the world. They have robust ecosystems of partners and tooling. And they have people who've built their careers around being an Oracle DBA or a SQL Server DBA.
It's tough to break into that market, so you really need to narrow in on how exactly you are different from the 18 relational databases that are already out there. And we focused on open source and the fact that we were part of the Linux distros. I think the real story of MySQL success was not that it was a remarkably profound database - there were a lot of better databases, probably. It's the fact that it was simple to use and bundled with Linux, and reached people through that channel.
And then with TrialPay, we were a new way of paying for things. So instead of paying by PayPal or credit card, the user could take an action that would result in a payment. You might watch a 22-second video to earn coins for an online game. Or you might sign up for a magazine subscription to get two free movie tickets from Fandango. This payment method had never been used before and is a totally different approach to the market so merchants didn't know that they needed to provide this method of payment to their users.
So what we found at TrialPay was that we either had to find merchants who had a high margin product that they were willing to experiment with our new way of purchasing, or -- and this was a more successful approach -- we had to offer credit card and PayPal processing at cost, and then put our alternative payment as a third or fourth option, so that we could go head to head with the Braintrees and other credit card processors and say to merchants: “look, you know, we'll handle it if your customers want to pay by credit card, but we're going to actually open up the opportunity for you merchant by having this alternative payment for people who don't have credit cards or max out credit cards.”
Basically we had to latch onto something they knew, which was credit card processing, and tag our innovative payment solution onto it. Those are the challenges you face, and it's not easy either way, whether you're attacking an established market, like MySQL did, or inventing a new market of offer-based or action-based payments the way TrialPay did.
Bundling with A Rising Platform
Kevin: It seems that Linux was a determining factor to MySQL’s success in a lot of ways. Linux is obviously still everywhere right now. And in the cloud world, we have Kubernetes everywhere for the container-orchestration side. So these sort of platforms that are of global reach are forming and being consolidated. Would you say for a new startup to think about their global reach, they should think about the strategic platform with which they have to bundle themselves?
Clint: Absolutely. Ride the wave I'd say. Maybe your wave is serverless architecture, or multi-cloud and Kubernetes, but regardless, you need something that will carry you and you'll find that “wave” actually touches every part of the organization: like your recruiting pitch is going to be, "Hey, I am part of this wave"; your search engine optimization is going to be those keywords relating to your wave; and your VC pitch is going to be, "I'm riding this wave to a hundred million in ARR."
No startup can make it on its own energy so you need the energy of a big wave and have to pick your wave wisely. And hope that the wave you picked wasn't Mesosphere 5 years ago.
Myth of Product-Led Growth
Kevin: I see. Kind of a different side to this conversation is that a lot of startups in our world, whether it's enterprise tech or open-source or developer-focused products, by definition have mostly founding teams with very technical folks. It makes a lot of sense because they have to be, to be able to create something new in the technology sphere.
And there is this often glossed over assumption, almost wishful thinking, that if you build a better technology or product, you're going to have this wonderfully nice motion of product-led growth. Almost like, "if we build it, they will come." I think there's a lot of hard truth to that assumption and I'd love to hear from your experience: if you build it, will they come?
Clint: In open-source discussions there are often questions like, “will there ever be another Red Hat” and with product-led growth the question is: “Will there be another Atlassian or did they happen to hit something magical with their product-led growth?” And this causes a hundred VCs to come to startups and say, "why don't you do what Atlassian did and generate product-led growth, you know, without sales or sales engineers?"
It's, in fact, extremely hard to do. So I'll tell you a fact pattern that I see: an open source project is solving a real need in the world. It may not be a massively successful project, but has traction and people who are following and contributing. Then the founder think: “all I need to do is to turn my project into a SaaS product and people will discover it and hand me their credit card. I’ll charge them X dollars per month. And all of a sudden, I'll have a $10 million ARR SaaS business.” That almost never works out.
I feel like there's this expectation that you're going to take your open-source project and turn it into a SaaS machine. And it's extremely, extremely hard work. So there are a couple of things to do along the way. One is to invest in sales engineers, invest in customer success, and get 20, 30, 40 enterprise customers to use an on-prem version of your open-source project. You will learn so much from that. You're probably going to build a better product-led growth machine after actually having launched your open source project as an offering within a bunch of companies that will pay you and let you watch how they use it and what benefit they obtain from it.
So I often see open source founders at the angel or seed stage thinking that they're going to go directly to this SaaS model. But then they pause and say, “actually, I need to understand how an Uber or a Roblox or a Slack is going to use my open source project within their company. I'm going to charge them $50,000 to create a center of excellence around my open source project within their company. I'm going to see how their engineers use it. I'm going to understand the tooling and the environment and go do a bunch of those engagements so I can learn.”
One, they generate cash flow, right? It's very easy for one of these companies to cut you a check for $50,000. And second, the learnings are immense. Then after launching 20 or 30 of these customers, you can step back and say, "is my better model the self-managed, self-hosted enterprise sale, or do I now know enough to turn this into an atomic, pay-by-the-credit-card SaaS model that will have wide adoption?”
Jumping immediately into this product-led growth and sales on a credit card of a SaaS product is harder to do than you'd expect. But the VCs ask you to do it and you're going to face a lot of pressure. It's not easy when you don't know exactly what people will pay for and how to get to them.
Kevin: It seems that there’s this pressure or bias from the venture investors community, generally speaking, that the SaaS model or the SaaS kind of revenue quality is better. And if, like you said, we go in depth with an Uber or a Roblox through the center of excellence model, what ends up happening on the tactical level is that you have to deliver a lot of training, right? You probably have some support-level agreement that is just them calling you when they have problems, kind of revenue, which is old school, Red Hat, and not very SaaS-y or subscription based. And that's why people kind of poo poo it. But from your experience, that is almost like a rite of passage or the necessary step a young company needs to go through to really know how to provide a good SaaS experience. Am I getting that right?
Clint: I would say you don't rule it out as an excellent path to get learnings primarily, and get cash flow, which helps, and get logos that will give you prominence for both market penetration and your next fundraise.
So I think Martin Casado at a16z has written well about this in terms of the value of doing services early on, and how much you've actually learned from those services that can help you build into the product going forward. So yes, you might face some investor resistance by doing services, doing proof of the concept, standing up a self-managed implementation of your open source software, but a lot of learnings come from that. And it's much better than building a SaaS platform that doesn't attract any users.
A Contrarian View on Partnership
Kevin: Now I know you have a more contrarian or unique view towards partnership, which I'd love to talk about a little bit. A lot of companies in the early stages - probably from 0 to 2 years old - often shun partnership discussions, or don't even want to think about it. What's your view on how early stage companies should think about and/or prioritize partnership conversations?
Clint: I've been in rooms where an investor will tell a founder CEO to not spend a minute on partnerships until you understand who you are building this product for and have a repeatable sales model to some known buyer persona.
I think that's fundamentally wrong. If I sit with a founder CEO, from the earliest days, I want us to map a landscape of partnerships. It doesn't necessarily mean that you're going to start spending time building those partnerships. Your time is super valuable - you're not going to spend time with every one of those possible partnerships - but you want to be thinking about a taxonomy or map of partnerships and understand what types of partnerships will be available to you as your company grows.
Which are the ones that are going to accelerate your growth? Which are the ones that could lead to an acquisition offer? Which are the ones that can lead to technology adoption and acceleration? And which are the ones that are a complete waste of time? You need to map them out and decide who you will strictly ignore, who you'll allocate a small amount of time to, and who you'll aggressively pursue.
I'll cover a couple of categories. One is really for any startup. I think there are probably three to five larger companies that will have a big impact on your fate. They may crush you by adding a small feature that completely destroys your market opportunity. They may make you a billionaire by acquiring you. They may partner with you and put you on a price list and bring you into accounts that you can never reach on your own. You need to think about the giant companies that are working with the types of customers you're trying to reach out to. Who are they? What kind of relationship could you have with them?
You need to get on their radar early and build relationships as high in those organizations as possible. So that's the process of saying: “Okay, there are three to five companies that are on the landscape that I'm working in. They really matter. They can crush me, buy me, bring me to market, or shut me out of markets.” And you need to have a strategy for those three to five companies, almost an account plan, like an enterprise rep would have.
Then you’ve got to look at the adjacent technology, the technology sitting right next to yours within the target accounts or target use cases. So at DataStax, everywhere Apache Cassandra is, Apache Kafka is, or everywhere that's using Cassandra as a data store is also doing Spark analytics. And you better find a way to work with thee people building those adjacent technologies because you want to accelerate your momentum by being associated with things that work perfectly with your technology.
You should find that those partners are very receptive to you. So you and I worked with Max and Preset with Apache Superset. Apache Superset works really well with the Druid database from the folks at Imply and with the data lake engine products from Dremio. Those adjacent companies are riding the same wave, reaching the same customer, and solving similar problems. You should work together and get that great synergy.
And then sometimes you say, okay, there are certain markets that are great for me that I can never get to alone. And maybe it's the government, or financial services, or a whole country like Japan. So somewhere on your roadmap, you're going to have to say: “aha, I need a government resale partner. I need one large partner in Japan that can just hold that market for me. I want an education customer, but can't deal with them, so I need a partner who has credibility in that space.” So then at a deciding point in your journey, you partner with those companies that can penetrate a market that you can never penetrate alone.
Anyway, I'm passionate about this, because it may not take a lot of your time on a week to week basis, but I think it's essential as a founder CEO that you have a partner roadmap and strategy. That is a multi-year strategy that covers the different types of partners that can accelerate your growth, but they can also hold you back.
Kevin: Very interesting. Would you say within a company's first two years, they should have some executive retreats or whatnot with their team and advisors, like you, Clint, if they’re lucky enough to have you, or other investors, and map out potential partnerships? And then we'll just put it in the back somewhere, but this is like in our head now. So as we progress and start to really dive in on some other stuff, we wouldn’t forget that we can think about partnership from time to time in a more strategic way.
Clint: Absolutely. This is a perfect topic for a strategy offsite and for having an advisor help you for 90 days. And one of the benefits I didn't talk about, which is one of the most powerful ones because we all know that our time management is critical, is that it gives you a plan for what meetings you don't take.
There are a lot of situations where system integrators want to come talk to you, because there are teams at Accenture and Booz Allen Hamilton, who just need to scour the planet for tech trends and they're often in the “labs” function of their firms. They'd love to just come in, spend a day with you, and understand your technology and where it fits in all the different architectures that are evolving. Complete waste of time. Just send them a white paper from the website and never meet with them because they never actually generate revenue.
It's very different if the message you get is: "Hey, we are the automotive group from Accenture, and we're doing manufacturing optimization and we’ve decided we could use your software in the auto industry at these six manufacturing sites where we have consultants." Then you take that meeting, right? Especially if manufacturing is a good vertical for you and the partner who contacts you is actually onsite doing billable projects that are relevant. So yeah, part of the benefit of that map is turning down a lot of partner meetings.
Building A Global Team Operationally
Kevin: I want to kind of zoom out a little bit more to somewhat maybe the more operational stuff even, cause you've just had so much hands-on experience running the operations, HR, finance, legal, and obviously the strategy and product of these companies. And one thing I know is top of mind for so many people in the software space, especially young companies is like, Oh, we're going to build this amazing distributed team, right? We're all going to work from home, even though currently like me and Clint are, I don't know, maybe 10 miles away from each other that we're still in our respective rooms doing this thing.
But I do think that presents some very challenging scenarios going ahead for young companies, right? Even big companies have challenged organizing their workforce from around the globe. How do you think through kind of the foundational aspect of setting yourself up right. If you're like a company that's like less than 10 people right now, a couple of people in Australia, maybe a few people in SF and like a couple of people in Berlin, very typical makeup. How do you make sure that they're thinking about this with the right set up to succeed in the right way?
Clint: So I started with strong conviction that talent is evenly distributed across our species. But you know, capital and purchasing power isn't. And so as a startup founder, you have to take that into account, which is this fact: most of your revenue is going to come from OECD countries, rich countries that spend a lot of money on startup products, but your talent is actually evenly distributed across any place where there are humans and networks. And so I'd like to think broadly on the human capital side but narrowly on the sales and marketing side.
And it was very motivating at MySQL, which really was one of the first fully distributed companies, to see the talent that would join our company from the MySQL community largely, which existed all over the world. And we had colleagues in New Zealand and South Africa, Bulgaria. And the power of being able to hire from anywhere, it's really a great advantage. Now, it creates a pain, right? When it comes to, you know, giving stock options or paying employment taxes and the like. But that pain is worth it. But you can't ignore the fact that your revenue is going to come from a small number of countries.
And so when you're hiring in marketing, when you're hiring in customer success, when you want analyst relations to talk to Gartner and Forrester, you have to be in the market where your customers and the money is going to be. So that's a tension I see where you can hire support engineers and software engineers and database engineers all over the world. But when it comes to sales and marketing and the go-to-market function, you're likely going to be in the major markets where the money is because people need to have that expertise.
Kevin: I see, would you say from just like a general management perspective, even all these like taxes and labor stuff and the headache that comes with hiring someone who might happen to live in Iceland, for example, when you're a Delaware C Corp. Are these issues basically solved problems at the end of the day? It's just a bit of a pain in the ass. And it's kind of the right thing to do as far as company hygiene is concerned, to get it right from the beginning, and not have to think about it. Or how do you think about that?
Clint: So you start from first principles, which is if there's a talented human who can accelerate your company's journey, get them onboard. You can figure out the taxes and the stock options and the employment benefits.
With the push to have more distributed teams, there are all sorts of service providers popping up today that didn't exist when we were at MySQL, trying to figure this stuff out manually. And so it is getting much easier to give stock to people in different countries and to make sure you're complying with the right tax withholdings in different countries. So you find service providers that will get you there. But you never miss out on getting a great human to join your company and advance your prospects.
Kevin: 100%. So I have two more, very tactical questions for you, which is part of our MO, right, to be very tactical with something you can think about tomorrow. One of them is about compensation philosophy, specifically maybe executive compensation. It won't be that long before most startups have to hire a VP of something, VP of marketing, VP of sales, and then a lot of things cascade when that door opens. How would you advise founders to think about compensation philosophy, so they don't kind of screw it up for the long term?
Clint: Yeah haha. So first the founding team needs to codify their company values and live those values and explain them to people. And I think that's one exercise before you get to compensation. But then at the second exercise, before you start hiring your first VP of something, or a Head of something, you as the founder CEO should codify your company's compensation philosophy so that when new people join, they have an understanding of your approach.
It can evolve a bit year to year, but I think these things are fairly fundamental. So at TrialPay part of our compensation philosophy was: “we're not inspired by people who are motivated by cash.” We wanted to build a great company. We wanted to have stock in a company that is meaningful, but if you're the type of person who's arguing for another $5,000 of salary, that's kind of de-motivating to us. You're not in sync with us. And so we wrote down rules like that, but we also wrote down rules like: “if one of our employees comes up against a really tough personal situation, it's all hands on deck to help them through it.”
So when we had an employee with a sick child, we went above and beyond to keep that employee, taking care of supporting them with meals, with paychecks, with extended leave, with continued vesting. Those situations are so tough on the family, that if it happens to someone, you need to rally around them.
And that was a consorted compensation philosophy that we wrote in. They're other interesting questions that I'll often help a founder clarify. Like, iin our equity, we should have a bias to product and engineering people who are building intellectual property that lives for many years, and we will give less stock and more cash to a sales or marketing person, which is generating shorter term rewards, right? A great marketing campaign generates leads that will close in six months, but a great software architect is designing something that could last for five to seven years. So let's have a clear position that we will give more equity to the architect. Let's give cash bonuses to the marketing person and a little less equity. I think defining these points is very important.
And I'll raise two more comp topics that I think are very important from early days to have an opinion on. One is: when can an employee sell stock? So now it's becoming more and more common for startup employees to sell stock, as early as probably Series B. And some companies say: “you know, we're going to make it hard for you to sell stock. We're going to put into our bylaws that you can only sell stock when the board of directors approves that. We're going to control when you get liquidity. It's our choice.” That's fine, you know, a lot of companies decided that's the right way to do it. Just be clear about that with employees.
Other companies, and this has been the case that at Discord, the CEO believes that employees should have the right to sell vested shares, just like you would if you were at Google or Facebook. And we have an active market where employees with vested Discord shares can sell them. But that's a philosophy, right? “I'm going to give my people freedom to sell our stock,” as opposed to, “I'm going to decide when my people can sell.” And you need to have a philosophy on that early and explain it to your board and then to your employees.
A related point. This is very practical and narrow, but it's important: “what happens to the options when someone leaves?” And Pinterest was an early leader on this, where if you left Pinterest, you got an extended window to exercise your options. In California, you get I believe 30 days and most companies give you 90 days and deciding what to do about your options as you leave a company is very stressful. “I'm leaving a company, do I buy my shares? Do I lose them? What happens?” As the founder CEO you should have a philosophy on this. Does everybody get stuck with the same narrow window to exercise? Does everybody get a year to exercise instead of 90 days? Does everybody get three years? Do you want a formula where, if you spend two years at my startup, when you leave, you have two years to exercise your shares? There are so many options but you should choose an approach that matches your values and then document it and communicate it.
That's a very tactical point, but it's important to have a philosophy on that. Then you can explain to people. And then you can apply consistently, rather than make it up when somebody leaves. So yeah, sitting down and writing your compensation philosophy, I think is a Month 12 job for the startup CEO. As you're starting to hire employees 8 through 20, that's a perfect time to say: “I'm going to distill my philosophy and really talk about how I treat my people when it comes to matters of compensation.”
Kevin: And would you say this philosophy when it is written down and vetted within the team or the board and everything, that it should be published and just transparent to all employees going into infinity? Or how do you think about the transparency of this?
Clint: Yeah, it comes back to your values, where if one of your values is being transparent, you know, if this is GitLab, you're going to publish that document. At a minimum, you want any hiring manager to know this is how we feel about spot bonuses. This is how we feel about tenure bonuses. Like what happens when you get to year three at the company? Do you get a $10 Starbucks card or do you get a Tesla? Let's define these things.
And so definitely every people manager should know the compensation philosophy of the company. And if you're all about transparency, everybody should know.
Kevin: Do you think a lot of companies do this? It definitely intuitively sounds like the right thing to do, right? Otherwise you're just going to have very inconsistent applications or management of your people. Do you see that a lot of companies actually do spend time doing this?
Clint: Actually, this is one of the values I have as an advisor -- sitting with the founders and mapping out a compensation philosophy and they know where they stand on these topics.
The value is having someone distill this into a few paragraphs that you can read. And then when you hire that VP of Engineering from Twitter, she might come in and do her own thing on compensation. But if you bring her in and say: “This is our compensation philosophy, do you agree with it? Are there things you'd change?” Then you keep alignment as you bring in new executives on how folks are compensated at your company.
It again is a huge time saver because when companies don't do this, then they'll end up reaching out to a board member, an advisor, a law firm and say: ”Ah, you know what? I've got to fire Kevin, but what should we do about his stock option? Like, you know, if he exercises it now, he's going to have hella taxes to pay. What should I do?” And then you're doing a one-off solution, as opposed to saying with clarity: “when employees leave, this is our approach to the window for exercising options.” And that was codified in our compensation philosophy. You save yourself so much time. If I had a time, we could cover what do you pay as severance when you fire someone, and then how long do you give them to exercise their options. And when can someone give a spot bonus? And when can you do a signing bonus? And what happens if you pay a signing bonus and they quit 10 days later, can you claw it back?
As an advisor, you know all these questions are predictable questions, and if you can solve them upfront, then the CEO can just breathe and relax when the situation happens. You're like, “Oh, of course, we paid a signing bonus and we never try to go get it back. It's on us. We made a bad hire. Person keeps the signing bonus. That's in our philosophy.”
Kevin: And I think the other thing you said just now rings true to me too. If you decide early on, say we are an equity versus cash kind of company, at least in the beginning, the $5,000 negotiation could end up either wasting you a week or two with a candidate, which is frankly, a really big cost, or it could just be one email. I'd be like, all right, then, nevermind, thanks for talking to us. And then, then you move on, right? Which is huge for a startup that's 10 people or less.
Clint: I worked with one CEO who said: “I want people to design their own compensation.” So his principle was, I want to be able to go to a candidate and say, okay, you know, your baseline offer is a hundred thousand dollars and 0.2%. However, if you want to take less cash, here's the formula where you can have more equity. But if you want more cash, I'm going to peel back your equity using this formula. And what he wanted,, his philosophy was: “I want the candidate to decide their ratio of equity to cash based on their personal situation.”
Maybe their spouse makes a ton of cash, maybe they really need cash this year to pay off the debts and they'll be happy to take more stock next year. And then the same thing at bonus time, right? So rather than say: “You know, Kevin, you had a great year, you earned a $20,000 bonus.” It would be: “Kevin, you had a great year. Would you rather have this many shares or would you rather have this much cash? You decide because we want this to be optimized for where you are in March of 2021.” That was pretty cool. It took a little bit of work, but it was really just exchange formulas, right? And it became personalized based on what the employee needed that year. And that's awesome, right? Because all of us have needs that change year to year.Some years we love some cash, other years we believe in the stock and we're fine on cash, and so we want to load up on the stock. And so that compensation philosophy was very much individualized.
Should You File Patents
Kevin: One more tactical question and I swear I'm going to open us up for Q&A before we let you go. Should a company file a patent or think about filing patents early on? You alluded to this too, like rewarding software engineers and architects with creating patents with more equity. But a lot of people have this question, especially in the open source world.
Clint: Haha I know. I have a confession to make as a citizen of the world. I hate software patents. I hate the whole regime that has arisen around patent litigation and patent settlements and patent cross licenses. So as a citizen of the world, I hate software patents. As an angel investor, seed investor, and advisor to startups, there can be great value in having a small investment in patenting your core technology. It can be helpful when you fundraise to show that you have something that the US Patent Office has recognized as innovative. When you try to sell the company and the buyer is coming up with what valuation should they pay for this, you know, the seed stage startup with patents will be worth more than the company without patents. If you have a couple of patents, that can only help in the valuation analysis. So I definitely think having a massive patent program doesn't make any sense for a startup, but having a core patent application on your fundamental technology is very useful.
And there's an interesting technique you can do, which is you can file one initial patent application and then later do spin-offs relating to more discreet technology pieces. So if you decide that patents are important to you, you can take that one foundational patent application and the precedent date of that application, and you can do branches off of it. And you could end up with 6 or 10 patents if you decide that's really important to you. So almost every company that does an IPO, in their S1’s they'll say: “We have 6 issued patents or 14 pending patents” and that conveys some imprimatur that you've done, an amount of innovation that's protectable. And I think it helps in fundraising. And I think it helps when you sell the company. I don't think it matters to customers and I don't think it matters to market acceptance.
If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).
几周前，我主办了每月一次的 “创业公司建设” 系列webinar的第二期，受众专注于面对开发者产品和/或商业化开源创业公司的创始人和运营者（第三场将于美国太平洋时间4月6日上午10点举行，与Docker的CTO，Justin Cormack，一起讨论工程团队的管理和扩展。请在这里注册）。
Clint：谢谢你邀请我。我一直很期待今天的讨论，因为我是你的忠实粉丝。我们是通过OSS Capital和帮助一些刚刚起步的商业开源公司而认识的。我们一起在Preset工作过，它即是Apache Superset背后的创业公司。而且我也很喜欢你的全球视野 -- 比如你写的《互联》博客和你最近的墨西哥之行。我是个美国外交官的儿子。我出生在西班牙，在南美、欧洲和澳大利亚都生活过。我喜欢把全球视角带入我们讨论中，我知道你也有同样的角度。所以我想这是我们两人在硅谷的一个共同点。
第一个是UUNET，当时是世界上最大的互联网底层的骨干网，现在是Verizon Business的一部分。然后我在Macromedia。你可能还记得Macromedia Dreamweaver。Macromedia Flash终于死了，但它死之前还是播放了不少视频。后来与Adobe合作，然后是MySQL，它也许是我最喜欢的公司之一，我们一会儿可以深入谈论这个公司。然后去了支付创业公司TrialPay与Alex Rampell合作，他现在是Andreessen Horowitz的合伙人。那是一个优秀的团队，打一个艰难的市场，但我们坚持努力，最终被Visa收购。然后最近一段时间是在DataStax，一家开源公司，现在在Discord，一个通信平台。它们都是高增长创业公司，有优秀的人才和在全世界都有影响力的产品。
我认为如果你要划分创业公司的话，有一些公司是在攻打一个现有的领域，其中的产品类别是众所周知的，新公司也许有些小的新改动而已。MySQL就是一个例子，当时攻打关系型数据库市场。一直以来，关系型数据库领域里有DB2、Oracle和Sybase，市场一点也不缺选择。在位者拥有巨大的优势。它们与世界上的每一家公司都有合同。它们拥有强大的合作伙伴和工具生态。而且它们有一批人围绕着成为Oracle DBA或SQL Server DBA为生，并发展自己的职业生涯。
要打入这种市场是很难的，所以你真的要专注并了解你的产品与其他18种关系型数据库到底有什么不同。而我们当时专注于开源，以及是Linux发行版绑定。我认为MySQL成功的真正原因并不是因为它是一个非常有深度的新数据库科技 -- 其实有很多更好的数据库。而是因为它简单易用，，与Linux紧紧捆绑在了一起，并通过这个渠道接触到了用户。
而同时还有一种普遍的假设，甚至是一厢情愿的想法，就是只要能做出一套更好的技术或产品，所谓的产品主导增长（product-led growth）自然而然就会发生。就像说，"如果我们能做出来，客户自然就会来。" 我认为这种假设如果把它当真理，有很多人吃亏，我很想听听您的看法：如果能造出来，客户自己就会来吗？
Clint：在开源圈子里经常有这种讨论："还会不会有另一个红帽（Red Hat），以产品为主导的增长？" "会不会有另一个Atlassian，还是它们的产品主导增长恰好奏效，无法复制？" 这就导致一百个VC来质问创业公司："你为什么不像Atlassian那样，在不雇销售或销售工程师的情况下，就能做到以产品主导的增长？"
我觉得行业里有一种不切实际的期望，就是把你的开源项目变成一个SaaS的产品机器。而这是非常非常艰苦的工作。所以，在这个过程中，有几件事要做。一是雇销售工程师（sales engineer），投资于客户成功人员（customer success），让20、30、40家企业客户使用你的开源项目的on-prem版。你会从中学到很多东西。如果你能把开源项目作为一个产品在一些愿意付费的公司里面推广出去之后，再去搭建一个以产品主导来增长的机器，成功率会高很多。
Kevin：似乎风投界会给创始人施加这种压力，或有这种偏见，是因为觉得SaaS模式或者SaaS的那种收入质量更高。如果像你说的，我们通过“卓越使用中心”的模式去深度开发一个Uber或者Roblox，就需要交付很多事情，比如提供大量的培训之类的，对吧？可能要签订一些服务支持协议（service level agreement），用户遇到问题时给你打电话，那种收入，老式的，红帽式的，而不是很SaaS或基于订阅的收入，所以很多人瞧不起这种收入。但从你的经验来看，这其实是一个年轻公司的必经之路，如果想真正了解如何提供一个好的SaaS用户体验。我总结的对吗？
Kevin：我知道您在怎么看早期合作伙伴关系这个问题有些独特，反观的看法，所以很想聊一下。很多早期创业公司 -- 也许在0到2岁的公司 -- 经常回避合作伙伴这个话题，不愿花时间去想它。您对早期公司应该如何思考合作伙伴关系有什么看法？
然后，你得看看相邻的技术，在目标客户或目标用例中，哪些技术和你的是邻居。在DataStax的时候，有Apache Cassandra的地方都有Apache Kafka，或者所有用Cassandra作为数据存储的地方，都用Spark做数据分析。最好找到一种方式与这些公司合作，因为你想通过与那些与你的技术完美结合的产品加速发展势头。
你应该会发现，那些合作伙伴对你的接受度很高。所以你和我与Max在Preset合作的时候，用的是Apache Superset。Apache Superset与Imply的Druid数据库以及Dremio的产品结合得非常好。这些相邻的公司都在“冲”用一波浪，接触同一批客户，去解决类似的问题。大家应该合作，取得更大的协同效应。
有很多情况下，系统集成商想来和你聊聊，像Accenture或Booz Allen Hamilton内部有些团队，他们的工作就是全球跑搜集最新的技术趋势，看看大家都在干什么，他们都在内部实验室机构工作。他们很想花你的时间，和你呆一整天，了解你的技术，以及其他所有不同的架构发展中的位置。这种会完全是浪费时间。从网站上给他们发份白皮书就好，永远不要和他们见面，因为他们永远不会成为收入。