GRTiQ Podcast: 36 Brandon Ramirez (Part 1)

The following podcast is for informational purposes only. The contents of this podcast do not constitute tax, legal or investment advice. Take responsibility for your own decisions, consult with the proper professionals and do your own research.

Brandon Ramirez (00:14):

And so I know that’s something that you need, was thinking a lot about at the inception of The Graph is wasn’t just how do we make data publicly available, but how do we decide what data is actually true and deserves to be part of this large global graph.

Nick (01:07):

Welcome to the GRTiQ Podcast. Today I’m speaking with Brandon Ramirez, co-founder and research and product lead at Edge & Node. In addition to his role at Edge & Node, Brandon is one of the original founders behind The Graph. Brandon was incredibly kind with this time and our interview lasted nearly two and a half hours, so I’ve decided to split the interview in half and create a two-part series. During part two, which we’ll release next week Brandon discusses a lot of interesting ideas, including the story behind Edge & Node, a core dev team working at The Graph, along with the design of the protocol incentive structure and how the roles of Indexer, Curator and Delegator emerged. During part one, which you’re about to hear Brandon talks about his corporate experience working at Microsoft, his move into entrepreneurialism, and then he provides a great backstory about the origin and early days of The Graph. We started the discussion by talking about Brandon’s personal and educational background.

Brandon Ramirez (02:13):

I grew up in San Diego and studied electrical engineering at USC. I’d say in terms of my background that I’m a generalist at heart. Even as I get more and more technical, I feel like I’ve worn a lot of hats over my career. In fact, even in undergrad I started as a business and computer science double major and then ended up switching into electrical engineering because that’s where I had more intellectual drive and passion, but at the start of my career I didn’t work as an electrical engineer, I actually worked as a product manager at Microsoft on some big data products. I worked on Excel, owning features like pivot tables, pivot charts, some of the enterprise dash boarding and I’ve had this through line of data products throughout my career.

(02:55):

The big reason honestly for switching was just that when I graduated USC in 2010, most of the job opportunities were working for big military contractors, Raytheon, Northrop, Boeing, all the companies that are down there in El Segundo, and I really didn’t have a passion for building things that would end up being sold to the military or it could be end up in weapons systems. And so I ended up just getting thrown into software as a matter of finding the job that felt like the biggest fit for me. Also that put me back at the intersection of business and technology, which is where I’d wanted to start my undergrad studies in the first place. Did that for about five or six years working as a product manager, learned a lot about how software gets built at the highest levels at these huge companies. When I started my career, it was these long three year waterfall cycles, so we actually shipped software on physical discs, and so it was a really different way of building software than we do it today, but nonetheless you saw the whole process end to end.

(03:55):

And after getting a feel for that, I wanted to dip my toes into startups just because it felt like a great way to test your abilities, have a more personal relationship with customer and the user. One of the things that’s challenging about working in an enterprise is sometimes you feel like you’re so far removed from the user and the market. During that time at Microsoft had actually been keeping in good touch with Yaniv Tal, who had been one of my peers and actually project mates back at USC. He had a job in Boise, Idaho working, doing embedded systems on HP printers. It just so happened that one of the remote offices that I managed as a product manager was based in Boise, Idaho. I would do these business trips back and forth to Boise all the time, Yaniv and I would grab beers or coffee anytime I was in town and that was one of the ways that we kept our friendships strong throughout the first couple, two, three years of our career as an enterprise.

Nick (04:47):

You and Yaniv begin working on a startup together or around this time. What was it that you started working on together?

Brandon Ramirez (04:54):

In our first startup together, we were focused on restaurant tech and we learned a ton in that process. Many of those lessons that we applied when starting The Graph and importantly also built our relationship as co-founders. When we started future things, we didn’t have to work through all those interpersonal getting to know each other or one another’s work style values, those sorts of things. That startup, I did the product management as well, but I was also wearing a few other hats. I did most of the UX design, I also did the sales. I managed, I grew and managed the sales team. I sold our first customers that brought dollars in the door.

(05:30):

And so up until those first five, six years of my career, really solidly establishing myself as a generalist and trying to find the commonalities between these disparate fields and that’s something that I look for a lot in my career. What are the common threads between different fields that can be applied elsewhere? The ways that some of my robotics and control systems background from undergrad are playing into the way that we’re thinking about the economic design of protocol. Learned a ton of lessons, like I said, in that first startup, but we eventually did decide to shut it down. Just wasn’t on the growth trajectory that we needed it to be. It was one of the hardest things I’ve done in my career was shutting that down, going back to customers that I had sold, taking the product back out, having had paying customers at the time.

(06:15):

And at that point I wanted to retool a little bit. There were some phases during that first startup where I had sold customers, pre-sold customers, and we were blocked on some of the engineering work and it was such a bad feeling, not being able to roll up your sleeves and really push the needle on the engineering velocity and get your hands dirty. And so I spent about a year at that point retooling and getting back into software engineering actually, which came from this desire to get closer to the work, closer to the tech. I didn’t have any professional experience at that point working as a application developer writing software. I had written software as part of my electrical engineering studies, both doing things like Verilog and low-level C for embedded systems. Verilog is a language for basically designing circuits.

Nick (07:09):

Then what did you do next?

Brandon Ramirez (07:11):

Spent about a year retooling at that point. I started consulting in the Bay Area, moved from Austin, Texas to San Francisco Bay Area, started consulting for some companies out there. Then about a year and change into that I actually rejoined Yaniv for a startup that he had been working with Jannis on, a dev tool startup focused on react developers and this was in late 2017. This was mid to late 2017. A few things happened after I joined. One was coming in with the product manager mindset. I realized that part of the market opportunity that they had been early on was passing in some ways. When they started working on this project they would’ve been the first entrant, but in the meantime, there were a few other really compelling options came up in that space, so it was becoming a little bit more of an uphill battle in the market.

(08:04):

And the other thing that happened was Ethereum was really coming to prominence and we started observing that every lunchtime with Yaniv and I in San Francisco we used to work out of the galvanized there. Every single lunchtime we’d be talking about crypto and what was becoming possible in crypto and what was becoming possible with programmable incentives and all the things that were becoming interesting at that time. We weren’t really spending any time talking about the startup that PI and Jannis were working on. That was a good indicator to us that we were probably working on the wrong thing, so we shut that startup down. We decided at that point that Jannis, Yaniv and I all enjoyed working together. At that point we were all programming, we were all writing code.

(08:48):

And so we decided to pivot into a software dev agency, a little boutique agency, we called it Functional Foundry and we just started looking for clients in the blockchain space. Unfortunately for us, there were a lot of projects in 2017 that had raised exorbitant amounts in ICOs, and many of them shockingly didn’t have technical teams on the projects or on the founding teams. And so we would come in as the technical expertise to help them build X, Y, Z app that’s built on Ethereum or some other blockchain. It was pretty early days for app development on Ethereum still, and so that put us in this position of being some of the first ones to experience some of the problems as app developers that The Graph eventually went on to solve.

Nick (09:33):

I think a lot of listeners will be surprised to hear in your background is time at big companies like Microsoft working on a tool like pivot tables in Excel, which most listeners and certainly I myself have used quite a bit. What was that experience like working for such a big software company on such a important product and how has that informed what you do now and how you approach things?

Brandon Ramirez (09:54):

The most obvious connect is just that it got me thinking about data in ways that I’d never appreciated before. Every part of my career since then has really had this through line of enabling users to do something interesting or useful with data, and Excel was the start of that for me. Some of the clients I was consulting with later as a software engineer, I was actually working on their analytics platforms. The other thing that I think working at Microsoft really gave me an appreciation for was just scale. Just because they have literally hundreds of millions of users using Microsoft Office. Even very tiny decisions, when you think about the impact that’s going to have on people is absolutely massive.

(10:32):

That can be from a user experience standpoint, if you save a hundred million users 15 seconds or a minute on some important flow or task in their day, in aggregate that’s actually quite a large impact. The converse is also true. If you don’t approach the challenge of making that product usable and having really streamlined flows, the level of care and passion that it deserves, you could actually in aggregate be stealing that amount of time from humanity collectively, which it’s a big responsibility and it definitely weighs heavily in your mind as you’re doing these things.

(11:07):

The other type of scale that it comes up in a variety of ways. Another one is energy efficiency, so one of the earliest talks that I got when I had just joined Microsoft, it was part of this PM orientation, they talked about just the impact of an extra disc read for a certain type of action in the software. A disc read takes a little bit more energy than reading from memory, and you can actually measure that delta in energy usage and then you multiply it times the number of actions the average user takes that action and then multiply it times the number of users. The math works out that even a few disc reads and some key user flow could be an entire coal power plant somewhere in the world that needs to be built to support that inefficiency that’s been introduced into the app.

(11:53):

And so just operating at that level of scale was really incredible, but the counter side of it is that you’re not agile at all. You’re steering an aircraft carrier and everything you do is slow. Like I said, there’s these three or release cycles. We had a ton of, this was after all of Microsoft’s compliance issues in the ’90s and the antitrust stuff in the ’90s. And so working on any feature, you have a ton of work that’s just around compliance and accessibility and making sure that these open source office clones can use the same file formats. Even there the scale comes in, so you have a compliance error there. I think at the time, the fines from the EU, if you were found to be not in compliance, were under a order of millions of dollars a day for each day that you’re not in compliance. Just the types of concerns that you think about when you’re operating at that level of scale are just completely different.

Nick (12:48):

Someone with your background and training, Microsoft’s got to be the apex. There’s only a few other companies that really fit in that realm, and yet you had this entrepreneurial bent in you that pushed and motivated you. How would you explain that passion or interest in being an entrepreneur having achieved such success? It’s one of the most well-known software companies in the world.

Brandon Ramirez (13:11):

It’s a good question. In some ways I was late to the entrepreneurship game in the sense that I didn’t even really know what a tech startup was in its true form. When I graduated college I had this vague awareness that I wanted to be at the intersection of business and technology. That’s why I started my undergrad that way. Part of I think why Microsoft hired me as a product manager despite not having a background as a software engineer, so most PMs by the way that get hired at Microsoft have a compsci background. It’s a technical role even though you’re in this product management position, and one of the things that they liked about me was that I had a strong sense of the impact of the engineering work and not just looking at this thing in the vacuum.

(13:50):

I had done some internship work at Cisco where I was actually doing automation testing for some of their multitask systems, and they really liked that I could hone in on the value that had to key clients and customers in the space. That ability to see the impact and the problems being solved for specific users and really empathize with the user is I think part of what gave me a leg in the door at Microsoft. The downside of being at a company so large is that, I alluded to this earlier, is you’re so many steps removed from the user and you’re also so many steps removed from the impact that your changes and your specific contributions are having in the market.

(14:33):

On top of that, you’re in this environment that I refer to as universal competence where everyone around you is so incredibly competent and then not only that, you’re operating within processes that are so well-developed and defined that have been built out over years if not decades, that it’s in some ways impossible to mess up. Being able to mess up or being in a position where you can make mistakes I think is really essential for learning. And so I hit a point where I was really feeling like I could do anything and I wouldn’t get this learning feedback cycle, and so I didn’t feel like I was going to keep growing on the trajectory that I was at that time. Even though really enjoyed the people I was working with and the impact that I was having working on such a massive and widely used product, I felt like to really learn, I’d have to get closer to the user and also be able to start something from scratch. And so I could build up those processes and those organizational learnings myself.

Nick (15:34):

Inevitably, someone’s going to listen to this interview, they’re going to be working at a very large company in a web2 type environment. You’ve made the leap, you’ve done something really remarkable in that leap. What would be your advice to Brandon 10, 15 years ago that was still working at Microsoft and was contemplating making a move that you’ve successfully made?

Brandon Ramirez (15:54):

My first advice would just be to not sweat the small stuff because things work out in the long term in ways that are so impossible to predict in the short term, and so especially to someone in your early 20s. I was, I think the most important thing is to just follow your curiosity and experiment and try as many things as possible, and it won’t always be obvious how those things connect. Today in my work in crypto, I’m leveraging ways of thinking that connect back to my electrical engineering training, which I never thought I would use professionally. I’ve had this long through line of interest in economics, took some classes in college. I used to read probably several economics books a year for a huge part of my 20s. Again, never really thought that would end up being valuable from a marketable skills perspective necessarily, but it was just where my curiosity was at the time.

(16:51):

And now I’m thinking about economics and economic design all the time. I think about UX design all the time. I think about product management on data products all the time. My first startup at the end of it, we had been working on that thing for two to three years. Like I said, we had paying customers, they had been bootstrapping it, so foregoing our market rate salaries that we would’ve been making at these large enterprise customers. I had a lot of, I don’t know if regret’s the right word, but certainly some existential angst of like, “Hey, did I just spend two, three years working on something that is going to just be a step backwards or a non-factor into my future career?” And then you fast-forward a few years and a strong relationship that I developed as a business partner with Yaniv during those years has absolutely carried forward into future ventures. Then in many ways, part of what I think has made The Graph successful is that we’ve basically made all our mistakes in the first startup, and so all the lessons from that first venture have also carried forward.

(17:52):

To get back to your original question, if you’re trying to get into crypto, I would say just do it, especially if you’re at that phase in your career where you’re supposed to be exploring and experimenting. If you’re later in your career, I would say by this point you’ve probably built some skills that are valuable along some domain or some dimension. Despite what many people think, crypto is bigger than just the tech, there’s many opportunities to contribute. I think this podcast is a great example. Figure out where… A good heuristic for, I think for any type of career move is figuring out the intersection of where your interests lie, where your skills are and what the market rewards. I’d be shocked if for most people that have a professional career that’s spanned a decade or more that you wouldn’t have some intersection with what’s needed in crypto today.

Nick (18:41):

Well, I love the story that you’ve told so far because it’s so much the model of entrepreneurship and people taking risk and taking chances. You’ve mentioned some of those early failures that you and Yaniv and Jannis went through. What are the one or two lessons that came out of that?

Brandon Ramirez (19:00):

There’s a lot more than one or two lessons. I can go through a few. One thing that was challenging, and this is an interesting one actually because it’s a rule that we broke with The Graph, but one thing that was challenging about our first startup, which like I said was in restaurant tech, was that we actually had a lot more users than we realized at the outset. We had this product that was used in the restaurant, it was a real time customer feedback product, and then we were pivoting that into payments at the table. If you look at the users that needed to be engaged and engaged in certain behaviors for the product to work well, we had the guests at the restaurant, we had the servers at the restaurant, we had the GMs who needed to actually respond to and take action on the feedback or look at the dashboards that we were building and then in larger restaurants, oftentimes there was a fourth stakeholder, which was just the owner themselves, who was the person we were trying to sell.

(19:56):

And so building a product, especially when you’re bootstrapping and you have a really, really small scrappy team, building a product well for that many different user personas at once, especially when they’re interacting with different applications altogether that are connected to the same system is really, really challenging. We did break that rule with The Graph, but we came up with a sequencing that would make that manageable. When we started off building Graph Node as an open source library and then the hosted service, we were just entirely focused on the subgraph developer really for one to two years before we introduced the complexity of having to bring in the Indexer, the Delegators, the Curators. By that point in the lifecycle of the startup, we had a lot more resources, our team was bigger, so it was easier to give each of those areas the attention they deserve, but that’s still an area we’re trying to get better by the way, is making sure we’re giving each user persona a full product manager set of software developers, designers feed… Basically a complete feature team because each area really is quite deep. That’s one lesson.

(20:59):

Another lesson that I think I really came away from the first startup with is it’s really important to understand what your basis for competition is in the market that you’re trying to compete in. As a technologist and many entrepreneurs that have a software or some kind of engineering background, we tend to have a bias towards technical solutions to any problem. To a hammer, everything looks like a nail and not everyone thinks that way. To give you an example, if you were to present a restaurateur, a restaurant owner with a problem, their bias is towards a human oriented solution. So you say, “Hey, you have this problem.” And their instinct is, “Oh, I don’t need to buy a piece of software to fix this. I actually need to hire a person to fix this.” And just the fact that they don’t have that same understanding as you at the outset means that your barrier to selling them to get this product deployed is that much higher.

(22:02):

And the other thing is, so another example related to that came up with this first startup was understanding the role of distribution. That would be another one, so in many cases we would talk to potential clients or restaurateurs where they actively despised the technology that they were using and wanted to switch, but they had such a large vendor lock in or upfront cost with their installation, or they were working with a channel partner that had brought in this whole solution of technologies and they didn’t want to go outside the channel partner. The fact that there were so many customers not even making their choices on the basis of the quality of the technology is something that we didn’t anticipate and was something that was a really hard lesson for us.

(22:50):

A lot of this stuff you can learn in books, one that I recommend to a lot of upcoming entrepreneurs is Steve Blank’s, the Four Steps to the Epiphany, and that was a largely influential book for Eric Ries, The Lean Startup. In my experience, many entrepreneurs need to learn these lessons for themselves even after they’ve read it, but a really key observation from both of those books is that there’s more things to validate than just, “Hey, does the user have a problem?” That’s where many entrepreneurs start, but really you need to understand the sequence of things that you would need to validate is does the user or does the target user have a problem? Does the target user know that they have a problem? Do you have a solution to that user’s problem? Do they agree that you have a solution to that user’s problem? Are they willing to pay for that solution to their problem? And do you have a sustainable way to get that solution in front of enough users where the economics of selling that user are actually sustainable?

(23:48):

And that last part is was one where this first startup fell down, where the unit economics of each customer after you account for the amount of time it took to sell one of these customers, we were targeting S and B restaurants. The math really didn’t work out, and the amount of churn that restaurants have with respect to their employees meant that even after a sale was closed, we were spending hours and hours going back in and retraining the new staff anytime they had a new GM, a new set of servers. Even though we had correctly identified a problem that they had and they admitted that they had, and as well as a solution that many of those restaurateurs agreed would address their problem, there were more steps of validation that ended up being the linchpin pins in that business not working.

Nick (26:23):

When I hear your story and I hear all the details of how you got to where you are today, I see these different threads and I’m wondering if you’ve ever made this connection, and maybe I’m overstepping, but you talk about your days at Microsoft and seeing and understanding data for the first time, that being a thread through your life. Then you talk about some of the economics books you’ve read and understanding incentives, and then you talk about this experience you had in your first business where you had to understand different personas and different uses and consider the ecosystem. As I hear all this, it seems like it snowballs and inevitably leads to something like The Graph. Is that a too much of a stretch there?

Brandon Ramirez (27:05):

No, I don’t think it is. One of my favorite podcasters is this guy Sam Harris, and he basically has this kind of thing he’s talked about that you need to find your category to compete in and it’s not that you need to be the best in. When we grow up we’re raised to think in terms of these very predefined categories. We have these subjects in schools, you have math, you have science, you have English, you have history, and then we’re thrown into university, and then there’s categories expand a little bit more, but we’re essentially taught, “Okay, you need to come up with some category that you’re going to, that’s going to be your major and your track, and you need to be the best in that category.” And they’re very cookie cutter categories, and then when you get into the real world, the skills and experience that you build are so much messier and they intersect in really unforeseen and interesting ways.

(28:02):

When I was working as a software engineer later in my career, I was building applications with React, with GraphQL. I was using the whole modern web stack. Throughout my entire career I had this economics throughline as well as this UX design behavioral economics through line. I had this systems designed background from electrical engineering, and so those things intersected really well for me with The Graph. I think what most people, especially as you get to the end of this exploration phase of your career where you try a lot of different things, you can find these intersections that are really just unique to you, and that’s the way to create differentiated value.

(28:45):

In a lot of fields, it is well understood that advancements in that field come from outside the field. Some of the latest thinking or research in economics taking place at places like the Santa Fe Institute came from them bringing physicists into the room and applying like, “Hey, what lessons can we apply to economics from maybe the types of models that you guys have developed over here?” And so part of what I love working on The Graph is I feel like it integrates all my various interests and experiences in a way that makes me uniquely suited to work on some of these problems.

Nick (29:23):

Going back in time a little bit then, you mentioned that you and Yaniv, and I believe you said Jannis would meet for lunch and some of the conversations started trending towards crypto and the possibilities in that space. I’m just curious, at that point in your life, what were those possibilities? What were you talking about at lunch that seemed like opportunity?

Brandon Ramirez (29:42):

It was early days back then, and just to clarify, Jannis was still based in Germany back then, so it would mostly be Yaniv and I at lunch in San Francisco. I think a lot of what caught people’s imaginations early on was A, just what can you do with this new primitive of programmable money? And I think we were seeing some of the early experiments in that space early on with respect to ICOs, you were seeing prediction markets be talked about, you were seeing these crowd sales. I remember one idea we talked about was just the fact that you could have crowd sales where the thing that was being sold was the right to use that platform in the future, and you could imagine really that being applied to anything. Imagine satellite internet, so you could use tokens as a way of getting capital formation to put all these satellites in space, and then those same tokens entitle you to the future usage of that internet bandwidth.

(30:38):

And so those types of ideas I think were flourishing, but I think it was still really, really early when it came to some of the other ideas around the decentralized web and what are the promises of decentralization. I think a lot of the narratives in those early days were around censorship resistance and this regulatory no man’s land that blockchains, people hope blockchains would be. I think over time, I think we’ve matured to understand that web3 and the decentralized internet particular just has this unique set of value propositions beyond was well understood in those early days. That was actually, I didn’t mention this earlier, I first heard about Bitcoin in 2013 at the start of this startup in Austin. For me it was the right message, but the wrong messengers, and it was these two anarchists types, techno anarchists that were really interested in Bitcoin’s ability to, as they hoped, subvert governments and nation states. I thought it was an interesting idea, but it didn’t speak to, I think, the value of the types of applications and systems that we’re trying to work on now.

Nick (31:49):

I want to talk a little bit about that, and it sounds like you’ve thought about this, but there is an ethos, there is an ideology behind web3, behind a lot of the things The Graph is pursuing, and so how would you then characterize it? Because like you said, in the crypto space there’s a lot of different ideologies and some of them can be really to the right and some can be really to the left.

Brandon Ramirez (32:12):

There’s a lot of facets to this. I think the TLDR is really, I think web3 is about unlocking human progress, and I think there’s a number of dimensions in which it does that. I think that the more obvious narrative that gets talked about a lot these days is the one around the ownership economy. The idea that web3 creates an internet that in some ways fulfills the original vision, where users own their data, users own their identity, they can take those things with them, so they have this unprecedented level of choice in competition when it comes to choosing the applications that best serve their needs as well as leveraging their data in ways that wouldn’t be possible when it was tracked in these data monopolies or data silos.

(32:59):

In addition, users own the platforms themselves, so you either have these platforms like Ethereum that have this implicit ownership where the user can hard fork at any time or choose to. Ethereum had its hard fork where many users chose to stand Ethereum Classic and some choose to move to Ethereum, or you have platforms where the user explicitly owns the network because they’re participating in some kind of on chain governance. I think if you knew nothing else about web3, just even understanding the fact that web3 is an internet where users are in control, I think that would be enough. I think zooming out a little bit, I think there’s some other long-term narratives that I think are important to understand.

(33:45):

One of them is that web3 turns every application into a platform. This is a cycle that plays out naturally over time, where technology, many technological innovations, they start off as applications and then they become platforms. What I mean when I say an application is that something that delivers value to a set of end users, whereas a platform is something that can freely be built upon by businesses and other applications that then go on to deliver some value to end users. One example historically of this is the railroads. The railroads had this huge boom in the US in 1800s over this 50 to a hundred-year cycle. Towards the latter end of that, as that deployment of railroads reached maturity, you saw a lot of anti-competitive behavior where you were seeing railroads basically collude to set prices and basically act like an oligopoly. That was actually at the heart of some of the first antitrust regulations and policies that were set in the US was actually to target some of these railroad oligopolies and cartels.

(34:57):

Now, fast-forward a few decades, those railroads ended up being essential infrastructure to the mass production and automobile revolutions. Henry Ford had these factories in Michigan, Detroit that were integrated into these railroad lines, and imagine what the alternative history if the railroads were still run and controlled by cartels, but the important thing is that that played out over a long period of time. We’re seeing something similar with the smartphone app stores right now. The iPhone’s been around since I think around 2008, 2009, phones obviously much longer, and for most of that period they’ve had an uncontested monopoly or oligopoly if you include Android. On app store sales, you don’t see competitive pricing at all when it comes to the percent of sales that the platforms take from app developers, it’s been at 30%, I think literally for over a decade, maybe two decades at this point, which is a sign that there’s not competitive forces driving that thing down as you would expect in the free market.

(36:04):

And only now decades later are we starting to see some policy action that’s targeting these app stores. We’re seeing some large high profile lawsuits. We’re seeing Apple relax some of their restrictions on the app store a little bit, but again, this is a process that has played out over decades now. You fast-forward to crypto and you look at a project like Uniswap, initially started off as an AMM presumably targeting basically an on chain exchange using an automated market maker, presumably targeting end users so that those end users could have a better experience when trading tokens and access to more liquidity. Then after these initial wave of AMMs, you started seeing these decks aggregators, things like one inch exchange for example. The time it took for Uniswap to become an application targeted at end users to becoming a platform that other applications could build on took less than one year.

(37:00):

So it’s in the DNA of applications that are built on blockchain and on the decentralized protocols that they have all the properties of a platform from day one, and it’s really just up to the innovation of developers to decide, “Okay, how is this thing going to be combined and remixed and interconnected with either other existing building blocks or new ones that I create?” And that I think is a very fundamental shift in the way that technological revolutions develop, and I would expect that to see an acceleration in new technologies, new applications, new platforms that wasn’t possible in the era when platforms were locked down by centralized companies or monopolies.

Nick (37:43):

As you and Yaniv have this dialogue and you discuss the potential of crypto in what probably sounds like the very early days conceptually of what web3 could mean for the world. At some point you come up with this idea about The Graph, and I’m wondering if you can just take us back in time to what those early aha moments were when discussing The Graph.

Brandon Ramirez (38:06):

So Yaniv to had the original idea for The Graph. Some stuff that was I think relevant at that time is GraphQL was really changing the way that applications got built in traditional web apps in ways that you were outside the space or subtle and maybe underappreciated, but GraphQL among other things, gave companies and enterprises a way to behind a single API, represent all the data in their organization and have it be queried in a way that was efficient and flexible. Which was a large departure from the way that enterprises used to be managed, where you would have these various rest API endpoints that were rigid. They only returned a set of data, they weren’t collected behind a single endpoint. There would be disparate microservices in the background each with their own endpoints often and made it really hard to think about what was the universe of data that existed behind some application or enterprise or organization.

(39:13):

And once you start working with GraphQL and you start seeing how easy it is to express this large interconnected data domain, the obvious thing that comes as the next step is like, “Well, really if you think about the data in the larger internet, it also has this conceptual interconnectedness.” That’s not the way that we architects think because of the legacy primacy of the SQL database and the API servers that we used to build around them, but a user in GitHub is not different than a user in Twitter or user in Facebook. They’re essentially conceptually, you can think of them as a single entity. An account, for example, in one application might have relationships to a user’s activities and some other application.

(40:02):

The way that traditionally the web has been architected because we didn’t have the infrastructure that would allow you to use data itself as an interoperability layer, is that we would create these silos, so you would have to have your SQL database, which is very dangerous to let anyone access directly. Then you build these API servers around them that have things like access control, and they map these rest endpoints to the schema of the database. Then when you want to do this connectivity and integration of data, you have to do it at the API layer. You’ve had entire cottage industries like Zapier, Unito emerge that are basically bubble gumming and paper clipping these closed APIs to one another. When you integrate things in that fashion, you’re not really using the data itself as the interoperability layer, you’re really just creating these copies. You’re passing data back and forth to try and synchronize the data between a user in GitHub’s database versus a user in Facebook’s database or a user in Twitter’s database, but they’re fundamentally copies that are not synchronize at a fundamental level.

(41:12):

That’s one larger trend that was happening was just rethinking the way that we represent data. Actually for listeners that are interested, I wrote a blog post really early on this called GraphQL Will Power the Decentralized Web, where I go through in more detail a lot of the things that make GraphQL uniquely qualified to be the API endpoint for decentralized apps. The other thing that was happening was Yaniv and I had this experience with this first startup, I didn’t mention this, but one of the big pain points that we were trying to address for restaurants at that time was negative feedback on Yelp or inaccurate data on Yelp or other review platforms. There was this question of what is the verifiable public data with respect to some entity like a restaurant or some other business or a place or a location. We didn’t have the systems and the tools in place then to agree on what the true state of these public data sets were.

(42:17):

And so I know that’s something that Yaniv was thinking a lot about at the inception of The Graph is wasn’t just how do we make data publicly available, but how do we decide what data is actually true and deserves to be part of this large global graph? That’s an area where I think the, that latter part is an area where I think the crypto space as a whole still has a lot of work to do. I know there’ve been some projects geared towards deciding what is true, whether it’s prediction markets, whether it’s using Oracles, whether it’s trying to create reputation systems with domain experts. Today The Graph primarily addresses the issue of indexing and querying that public data, but once those protocols become more developed, you can imagine The Graph actually being a global open API of true data. It could represent some kind of global consensus on the data that’s being queried. Now it doesn’t have to, but those are the tools that are available to anyone building on The Graph and building on these emerging crypto protocols.

(43:20):

So that was where the initial vision started was this idea of a global graph of verifiable public data. I think Yaniv had the first spark of this probably in the summer of 2017. He was also reading a lot of white papers around decentralized databases at the time, and also trying to think through, “Okay, what would the application stack look like for fully decentralized applications?” The thing that we were missing was a strategy. The vision is where you want to end up and the strategy is the route you take to get there. I mentioned this earlier in the interview, some of the lessons we learned on the first startup around what are the sequence of things that you need to verify to get from A to Z? And it wasn’t until we pivoted our team into consulting in the blockchain space that we started experiencing some of the problems that decentralized application developers would go on to experience.

(44:19):

Just how difficult it was to index data from the blockchain for a whole bunch of technical reasons that we can get into and put them in a database where they could be queried easily to drive some kind of application. That was a problem that we were witnessing our clients spend tens if not hundreds of thousands of dollars to try and address, and so that was some really early validation that, “Hey, there might be a problem here that’s worth solving.” And it’s through finding that… We obviously could have solved that in many ways. We could have started a SaaS company, that would’ve been a completely viable business model once you identify a problem that users are willing to spend tens of thousands of dollars on, and that’s where the vision comes in.

(45:06):

Our vision was that we wanted to create this global graph verifiable public data. We wanted to bring to life the promise of the decentralized web and those things would only be possible if we sought to solve that problem as a protocol. In about December and January, February of 2017/2018, we started working on a demo. Yaniv and Jannis started hacking on a demo app built in Go, and I started doing the research for how this would work in a decentralized context as a protocol and I wrote the white paper. That was first thing that we showed the early supporters of The Graph when we were looking for financial backing to work on this problem.

Nick (46:25):

Are you saying that a lot of the early thinking and ideas related to The Graph came from these observations about APIs and the global treatment of data and access to it along with some of your consulting and identifying there’s a problem in the blockchain space on this very issue?

Brandon Ramirez (46:41):

Yeah, I think that’s a good way to sum it up. We had this vision of how we wanted to change the world. We saw what crypto was enabling in terms of putting users more in control of their data and identities, and we saw solving this problem as a way of building a platform that would enable that, and we saw it as important for it to be decentralized. That’s one of the things that I actually think makes The Graph unique when you compare it to some other protocols is that really, there might be an alternate history here where someone else came along and identified this problem sooner and started it as a SaaS product, and that product could have gotten mainstream adoption and huge network effects and traction, and people might not have stopped to think, “Well, what if we had solved this in a decentralized way?”

(47:28):

A lot of the projects that you are seeing today are, especially when you’re looking at blockchain projects like layer ones, layer twos, state channels, there’s no centralized analog. Really, it’s the blockchain was so fundamentally new. It’s not like anyone’s going to go use AWS Lambda instead of Ethereum. Whereas from day one with The Graph we had this vision of where we want to end up, but we really also approached things from a product manager’s mindset. Honestly, just because we knew that there was a risk that this could be solved in a centralized way, and there weren’t enough good examples yet of what building in on a decentralized stack looked like that we thought we could afford to lose this layer in the stack to centralization.

Nick (48:16):

It sounds like one of the early decisions you made then tied to the idea you just shared, was solving and addressing this problem and creating a protocol that to do it. Was that an early strategic decision and what went into deciding to create that protocol? Maybe as a setup, can you explain why that is a strategic important decision for listeners that aren’t even familiar why that might even matter?

Brandon Ramirez (48:42):

Sure. I’ll take it, I’ll answer the second question first. Why is it important for The Graph to be decentralized? It really comes back to some of the value of web3 stuff that we were talking about before, but the classic playbook, Chris Dixon has a really great blog post on this called Why Decentralization Matters. I’m sure a bunch of your audience has read this already, but he talks about the classic SaaS data monopoly playbook and really you see this with a lot of applications where in the early days you’re creating value for users and the latter days you’re extracting value from users, and so you get this S curve from value creation to value extraction.

(49:27):

This has been the playbook for most successful tech companies for the last two decades, whether it was social media apps that started with no ads for the first few years and then build up these giant ad businesses on top of user’s data in the latter years or SaaS products that basically lose money on acquiring a customer in year one, but then because they have this data monopoly they can extract and make money off them in perpetuity for the later years. It’s really the playbook, and so understanding how important the data that was going to be queried through The Graph was, the idea that it would be built in such a way that the economic incentive five, 10 years down the road would be to extract was unconscionable to us.

(50:18):

By the way, I don’t think these companies that are extracting or are necessarily doing anything evil, it’s the way that the current system is set up. They have a fiduciary responsibility to their shareholders to make as much profit as they can from the assets that are available to them. There’s an expression, show me the incentive and I’ll show you the outcome. Their incentive is to do this. And so that’s why it’s so important when you’re building one of these things from scratch, you need to have the right set of incentives from day one to avoid that kind of outcome in the future and I think we felt that decentralized protocols had that right set of incentives.

(51:03):

And then from a personal perspective, one thing we didn’t touch on the validation story earlier was we talked about a lot of user-centric things that you needed to validate or market-centric things. There’s also personal validation. There’s this idea of founder market fit or founder idea fit. For us, we just wouldn’t have felt personally motivated to work on this problem unless we could do it in a way that we felt aligned with our values. Even if there was a successful business to be had running this as a SaaS company, we just didn’t want to be a part of it. It would’ve been hard to show up to work every day to do that and I think it also would’ve been hard to recruit some of the world-class talent that we have now, both at Edge & Node and in the larger Graph open source ecosystem if we didn’t have that, if we didn’t have that strong values alignment.

(51:54):

And then one thing I’ll add is that not only did this ideologically align us with our own values, it also ideologically aligned us with many of the early users of The Graph who themselves were decentralized applications. They were building as dapps for a reason, and even though The Graph from day one, it was just an open source lab rate, there wasn’t a protocol or a network yet, because they knew that’s the long-term trajectory of The Graph and because the teams and the developers had been organized in such a way that would lead in that direction, I think they took a big bet on us in a way that they may not have if we were a SaaS company. Some of our earliest supporters, financial backers for the project were actually notable decentralized applications that went on to be the early users of The Graph, so that was part of our early product validation, but also just shows the degree to which other developers in the space really wanted this to exist in a decentralized way.

Nick (53:00):

This concludes part one of our two-part series featuring Brandon Ramirez. Be sure to tune in next week for part two when Brandon talks about Edge & Node and the design and thinking behind the protocol incentive structure and the emergence of stakeholder roles such as Indexers, Curators and Delegators.