Effective Developer Product Design w/ CNCF, Tailscale, Sanity, Hasura Mina Benothman
In this DevGuild: Developer-First GTM panel, learn from the founders of Hasura, Sanity, and Tailscale about how they actually did the work of developer discovery, where they found success, and how they failed along the way.
Priyanka Sharma: Hello everyone. I'm Priyanka Sharma and I'm the Executive Director of the Cloud Native Computing Foundation. CNCF, as we are called, we are the home for Kubernetes, Prometheus, Envoy and 100 plus projects besides that, and host critical infrastructure technology components that, as you may be aware, have created this whole ecosystem of cloud native computing.
I have a long history in the developer tool space, I've been deeply engaged with Heavybit for a long time. I used to work at a portfolio company called Lightstep and then served as an advisor to the organization. After Lightstep I was at GitLab, there I was Director of Alliances, Technical Evangelism, served on the CNCF board and then finally ended up in my current role. So I spend a lot of time around developers, developer products, and so far no plans to go anywhere else because this is a great space to be.
Today, I have with me some amazing founders who have built great products for developers, and we're going to talk to them about how they conceptualized what they were going to be build, what was their vision.
Then once they executed on this vision, how did they continuously do developer discovery? Or in other words, how did they continuously stay engaged with their audience with their users? Know what feedback to take, where to iterate, how to do that, so that they're continually successful beyond that initial spark of an idea.
So without further ado, I would love to have our panelists introduce themselves. Rajoshi, would you like to go first?
Rajoshi Ghosh: Absolutely. Thank you so much for having me and really nice to meet all of you here. I'm Rajoshi, I'm one of the co-founders and the COO at Hasura. I come from a bioinformatics and genomics background, but that's really back in the past, I've been spending most of my time at Hasura working with the marketing and community teams. I've been working with developers and product creators for the last 10 years of my life. So this is a space that I'm deeply passionate about.
At Hasura just for those of you who haven't heard of Hasura, Hasura is an open source product that gives developers instant GraphQL and rest APIs on their data. What does that mean? Hasura allows the developers who are closest to building experiences for your users the access to the data that they need without any layers in the middle, be it software or people even.
Priyanka: Awesome. Thank you Rajoshi and welcome. Magnus, why don't you go next?
Magnus Hillestad: Thank you Priyanka. I'm Magnus Hillestad, I'm CEO and co-founder of Sanity.io. Sanity is a platform for structured content. We help businesses build better digital experiences by providing a platform for structured content. It's a developer tool that helps developers build a new CMS in the way that the businesses really should have it. So it's a developer tool that also serves a broader organization and tries to unify the way companies work with content.
Priyanka: Awesome. Thank you for joining us Magnus. Then last but not least, David.
David Carney: I'm David Carney. I'm the COO and co-founder of Tailscale. Tailscale for those of you who don't know, it's what some people would call the next generation VPN. It's a full mesh, incrementally deployable overlay network that's built on top of WireGuard. So a lot of people will use it as say the incremental zero trust solution or an open VPN replacement for interconnecting their devices' service, what have you, no matter where they are in the world. It acts just effectively like a LAN did back in the '90s but designed for the modern day security.
Priyanka: Very cool. You all are building dev tools, but in totally different spaces. Right? We have a CMS, we have a VPN- Rajoshi, how do I describe Hasura in one line?
Rajoshi: I think we have a GraphQL solution.
Priyanka: Okay. So Rajoshi tell me, what vision did you and your co-founders have that made you decide "we are going to be a GraphQL solution. This is the place where we are going to make a difference."?
Rajoshi: Absolutely. This goes back a long time. My co-founder Tanmai and I, we started building a couple of products and we realized that the process of building an application just takes a lot of time and a lot of learning, you just have to learn too many things across the stack. So we got to a feeling of "there has to be an easier way of doing this." So we wanted to make application development easier, but that was a big vision and we did not really immediately see how that would be a product or a business.
So that was the vision. How we started out was actually as a consulting and services firm where we just said, "Let's just build a lot of products for lots of different types of companies, different industries." We always had a theme that was building tooling that could be used across these products. So we came to this product that made our team super productive. And that was the genesis of Hasura.
But in terms of when we launched it as a company, we realized what we built was a larger platform. We started taking it apart. And one piece in this entire puzzle was the data access piece, which is the piece which we realized after speaking to a lot of people was the biggest bottleneck in this application development space.
There was a lot of innovation happening on the front end space. Databases were getting more modern, lots of innovation there, but that piece in the middle, which just is the piece that put it very simply, gets the data from where it's stored into the hands of the developers seemed like it was very bloated. So we realized that that was the biggest bottleneck and also something that could add value to businesses right off the bat, all sizes and shapes.
So that's how we came at the problem. We didn't actually come at the problem from GraphQL first, we had a version of GraphQL. I think maybe we were building it around the same time GraphQL was being born, but it was very similar in solving the same problem. So when we came to market, everybody was like, "You should just pick GraphQL."
So then GraphQL was the tailwind or almost the language to communicate this data access piece that we were solving. So that's how we went from that vision, which is still the same. It's still "make application development easier," but the way we solved it evolved along the way.
Priyanka: That makes a lot of sense. It's like people say vision, mission, execution, and you can narrow the funnel as you go it seems like. And what is your story like David on that front?
David: There's I guess a bunch of parallel stories I could tell. But the main one was that in very early days, the three of us co-founders, we complained a lot, and we all was seeing the way things had gone, I guess with network connectivity and cloud computing. I'm in my forties now. I started working in the field in the '90s, and I remember how easy it was back in the day to set up a network, to set up an application, to bootstrap a simple service.
There's been a lot of change between then and now. Things like SaaS opened up a whole bunch of opportunities for new businesses, but having worked on SaaS over the past decade, every year things seemed to get harder. Why do I need to worry about all these problems and security concerns when it's trying to set up a simple dashboard? Why do I need to worry about authentication? Why do I need a cluster and a DevOps team to bootstrap an application?
So these are the kinds of problems that really bothered us as a team. So we set out basically to start talking with customers about how to solve them. That's where we literally over weeks and months we slowly started chipping away at the problem and narrowing it down to something where we thought that in particular like network connectivity and security were areas that we had expertise in, and that we could actually make a difference.
So we narrowed the problem further and further down till we found a way to essentially, from a certain point of view, bring back networking to the simplicity or rather the way it was in the '90s. But for the modern day. So really trying to eliminate a lot of the common problems or the explosion of problems that people have to deal with nowadays.
Priyanka: Makes sense. And has that been evolving, changing over time or maybe refining?
David: Oh, for us definitely refining. We started with talking with literally, I think it was about 100 or 150 different people in organizations over the first six months. Just interviewing them, asking them "what kinds of problems are you working with? What are the kinds of problems you don't want to deal with? What's slowing you down?"
In parallel to that, we started talking with the bank. And that bank had a lot of existing problems. And in particular their problem was they had a lot of legacy infrastructure and they wanted to secure it with two factor authentication. They couldn't without doing a significant rewrite and they approached us to figure out how to do it. We thought it was going to be a rather simple off-the-shelf solution.
After we did a fair bit of research we realized it wasn't. So we actually built an initial prototype of what later became Tailscale, but it was just a way to use WireGuard in conjunction with our identity provider to control access on the networking level to legacy resources. And we launched this for them and set it up and it worked. It was full of bugs and stuff like that at the time.
But then we realized and reflected on all the previous conversations we'd had. And we took the same idea back to all these people who have been complaining about these different problems and were like, "Well, would this solve it in this particular way?" Then all these lights started going off as people started realizing.
That's when we realized we were onto something and that's when the vision became much, much more narrow and turned into a bit more of a mission of "we're going to make the world adhere to this vision specifically by addressing network connectivity and security."
Priyanka: Sweet. Awesome. You touched on a bunch of things around developer discovery too, and I am eager to come back to those, but really quickly, Magnus, I'd like to hear your journey and story around how your vision came to be and what is it today?
Magnus: Our service is a bit different, it started as an agency. My co-founders had an agency, I wasn't part of it back then. There's a really famous architect in Rotterdam. He's called Rem Koolhass, and my cofounders were running this tech agency building bespoke software for people, and his team approached them after seeing them on Vice and said, "Could you rebuild our website? Could you build this out of WordPress?"
It wasn't a web agency, so it wasn't the kind of work they did. But because he's like the Michael Jackson of architecture they said yes. And say, "okay, let's build something really cool and it needs to be really bespoke." And the whole focus was on the front end really. What ended up being oma.eu and it's still that product today. But what they quickly figured out was that the problem, in the backend, there's old CMSs, they don't do the work.
If you want to do something that is really bespoke and really magical, there's no software for actually letting you do that. So they built up something to enable them to build this highly rule based website, et cetera. And they went on to build an image carousel for MIT's Center of Advanced Visual Studies, which is something you still can't really build with the CMS' backend.
And in order to enable developers who build these amazing tools with content managers and have them work together and have them iterate and have them continue to develop these amazing experiences, Sanity was then born. And it took a couple years in rebuilding actually before it ended up being the Sanity that we launched in 2017.
The vision has always been the same. That's why we often say we're not a headless CMS. It does the same, but the vision was never to take a CMS and add an API to it. We come from the complete opposite side. We think CMSs are inherently terrible.
And I think different from some of these other stories, we were the guinea pigs and the user in the beginning. And it continued to be for a long time. So it wasn't until we really launched that we started to get external customers, and then started iterating with them. Started to talk to them a lot. So it's a little bit different, but the vision is mainly still the same, and
we've still only built 10% of that whole vision.
Priyanka: Right. Okay. So you're staying true to that high level vision and this is one way of executing.
Magnus: I think so. Yeah. We're still building features that was thought of in the initial spec. And we still add to that. I think the way we think about it has changed, and the way we are articulating it is changing all the time. But the core story of us at least has always been the same.
Priyanka: Okay. So if I'm hearing correctly, the vision is in some ways immutable, but it's also that way because it's visionary. The vision is at a higher level. So the execution can comfortably change and iterate and you can still be attacking that same end problem. Am I following that right, founders?
Magnus: For us that's true at least. But I think also the vision gets bigger. Because the opportunity at the beginning seemed smaller and it was never like let's conquer the world and change the CMS space. But it changed into that from that initial product, but it still centers around the same pain points. It just turned out the opportunity was bigger.
Priyanka: So one interesting thing about this vision that all of you developed is that it came from your own experiences as development teams. And Magnus in your case your co-founders were in that boat. Now, you folks are in a different position of being founders and organization leaders. Do you still feel you are the user for what you have built?
David: The short answer is yes. And I was I guess quickly outpaced by my peers. I'm an engineer by training. The people I work with can run circles around me, in terms of their technical abilities, but from very early, we built Tailscale for us. It was just very fortunate that a lot of other people had the same kind of problems and they wanted to take up the solution and eventually start paying for it.
I think there's a lot to be said for what we've built so far. I'm sure that the features that we are building, they're going to quickly outpace our needs, internally. Then it's going to be an interesting question of how do we build stuff for customers? We're not the users at this point. But right now we're still in a very sweet spot where we're building it for ourselves and our customers, it's a great feeling.
Rajoshi: Absolutely. This is something that's been very cool to us. It's the genesis of Hasura.
As we've moved forward, from agency to the product company that we are today, we've continued to try and find ways to continue to use Hasura.
The fact that we're open source has always kept us very close to the community and the feedback loop is always available. But using it internally has always been something we wanted to do. And our managed cloud solution, Hasura Cloud uses Hasura and so we're a huge user of Hasura the core engine. So I think that's how we continue to use it in a big way, but the community teams, the open source aspect of it keeps us really close to our users and product.
Magnus: We also do that. We use Sanity for a lot of things. We built the support system on Sanity first, we built a bunch of things on Sanity, you could use it for so much. I think it's essential because it makes it authentic. It's also a weakness though, because I can see that as we dive further and further into this project, we get so close to it. We see so many issues that can bother us. But we lose the blessing of ignorance and the fresh look on this.
So we try to use every new employee to get a fresh look, but even then, we often have people who already know about Sanity. So I think it's a super strength, but one strength to be cautious with and find ways where we can find other perspectives.
And also because a lot of our developers are extremely skilled and they become very skilled in Sanity, how do you find people who are fresh to this? So we're focusing actually almost as much on that, and we have a huge community and that's also a blessing where we can find that. So if you find the right balance, that's when you find the superpower I think.
Priyanka: This leads me to the next section of our conversation, right? Which is around developer discovery. You all built something that you knew was a pain point. You created it, you started using it, other people joined you in that journey. Now, presumably there are more people than you folks, right? So you have to do the difficult job of learning from what their experiences are, understanding them, looking at product usage data as well as what people think and how they talk about your product.
Then there is going back to that vision piece, your own point of view, which just may sometimes compel you to build something which maybe nobody said anything about. So in this section of the conversation, my first question to you is, what is your process for qualitative feedback? Do you do user interviews and how have you structured that? Then we'll talk the same thing about quantitative and go from there. So maybe David you can start us off.
David: I mean, in very early days it was us just reaching out to people and asking for 20 to 30 minutes of, "can you spare time over your lunch break? Can we bounce ideas off?" Then we would try to end every conversation with, "can you refer us to somebody else to whom we should speak?" And sometimes those would be dead ends. Sometimes it'd be great conversations because then as founders we'd go off and spend the next 30 minutes just talking about all the answers.
Once we started actually building and launching a product and customers started to use it, I think it really just comes down to the fact that our engineers were our support staff, and we were just talking with customers on a daily basis. That's still the case. We don't have everybody on the engineering side obviously on frontline support, but it's still very, very tightly integrated. A
Because it is a product that we use internally and it is an extremely technical product, we feel the customer's pain very quickly.
The urgency is conveyed very quickly. We can feel customers' pain with not much of a delay. So that's been very helpful with keeping us on track.
Priyanka: If I may dig a little deeper, I think I absolutely agree. There are segments of your users where you will feel the pain very quickly and empathize really fast. But the bank you mentioned earlier, I would guess you folks are building a very different organization, a very different product. So the concerns and challenges that a large bank might have using a product would be different from what your inherent experiences.
So how do you look at feedback from folks who have a different perspective and needs? Do they come first? Do they come last? How do you structure the feedback?
David: Well, that's actually one of the beautiful things about Tailscale, is that it's designed to be incrementally deployable by small teams. We intentionally don't go after the conventional approach to VPNs, which is top-down sale. It's designed to be the kind of thing that an individual can tinker with at home and bring into work, start sharing some devices with a colleague and then it expands from there.
So even with this bank in particular, they were definitely not a massive organization, but the people we were dealing with there, it was like the head of IT and then one of their colleagues. And we literally started with an extremely small rollout, just with a handful of users. So there was just a lot of incremental feedback all throughout those deployments, up to a couple of hundred employees.
If it were more of a top-down sale with a very different kind of organization and enterprise we would have been very different, almost like mixing oil and water by the way our team works, which is the way those customers work. But in early days we decided, no, we're not building an enterprise-first product. We're doing it bottom-up, very product-led growth, which is unusual in this space, but it's worked pretty well for us.
Priyanka: So would you say that the bank has become a design partner?
David: I suppose. Tailscale is designed to get out of your way as quickly as possible. So it's almost anti-design. We will install it and it will disappear and everything just works. In some ways it's detrimental because then people forget that we're even running and then our rest is like-
Priyanka: It's like Kubernetes under the hood, isn't even there.
David: Exactly. There are some great tools like that that we use too. And I forget that we're paying for them until the invoice shows up now and then. But I mean the bank was instrumental in a lot of the feedback in debugging and some of the early feature requests. And honestly just getting the feedback from their users-- for instance, us as a team we use a lot of Linux and MacOS internally, not so much Windows, whereas the bank is a heavy Windows user.
So it uncovered certain problems and things that we just hadn't thought to solve for. So that was invaluable. But at the same time we have opinions on how networking should work. We could bounce this off the bank and incorporate that into I guess our deployment with them. So it was a mutual way to exchange information and learn from each other.
Priyanka: Got it, got it. So design partner lite, where it's not a formal engagement, but you are going back and forth and working together to build something out.
Rajoshi, you have the open source component in your product, so you probably naturally get so much inbound feedback and ideas and thoughts. How do you look at it? How do you prioritize? Would you go after and call multiple times to get detailed information?
Rajoshi: I'd like to share the initial days of when we were making that transition into what was the product. So once we added GraphQL, once Hasura had that GraphQL support where you instantly got GraphQL, it was a new product. We were just prepping it for launch and it wasn't really a product feedback exercise that we did as much as it was a messaging feedback exercise that we did at that point, because we built this product over the years.
So we had the five key features that we were really excited about that everyone in the product and engineering team were like, "This is amazing." So we pretty much put that onto a spreadsheet, reached out to everybody. This is getting very tactical, but I think it's interesting from early founder journey. We pretty much reached out to most people who were working in GraphQL at that point.
We pretty much went through these five things. And just watched their expressions and saw whether the things that we were excited about-- we might have been excited about it because the engineering was really cool or it was a really hard problem to solve. But just seeing
that feedback in terms of what excited them, what would make them try Hasura given it was absolutely new, gave us amazing input into how we spoke about the product when we launched.
Some of the things that we really downplayed were the things that people really got excited about, like instant subscriptions or something. So when we worked on the website, we really took that feedback and that was very helpful in that initial spike of virality. So that was I think a very different feedback gathering experience.
Open source plays a huge role. The product team looks at most upvoted issues and we use that to prioritize. And of course we also have our enterprise users who also have product feature requests, but it all ends up in GitHub. A user is a user. So that really helps us prioritize and take in things and build it into the product.
One key point that we've realized as we've spoken to lots of users over the years is that when you're speaking to developers and when people are giving you their ideas of what you should be adding, it's very feature-specific. But I think it's important to dig deeper one level to, "what is the problem that they're trying solve?" It's not easy, but when we're able to get that insight, we've seen that
that helps us design a better solution for the problem, which may or may not always look the same as the feature request.
And has actually ended up in providing more elegant solutions that are more scalable. So I think that's one tip for interviews from what we've seen with our customers.
Priyanka: Makes sense. So Magnus, I'll ask you a slight twist on the question. In your organization, how would you rank qualitative feedback? It can be interviews, it can be GitHub issues, anything that's said or asked for? Wersus quantitative information, which is actual production usage data, what you see in your telemetry? Versus instinct from the founding team, from the product leadership of, "I really think we should go build that."
How do you rank those when you're deciding what to do next?
Magnus: I'd change the last one to the team, not just the founding team, because we have lots of people on the team that would chime in and have great ideas on the product. So we have, and I wouldn't say this is a good thing, but because Sanity is half open-source, it's a database product we call the Content Lake with an open source application, which is the Sanity Studio.
As open source we're very careful about putting in telemetry in the beginning. Because we've always been extremely focused on taking down the friction and making it easy for developers to use us. Which resulted in us only having the data stream of the API calls instead of actually having any telemetry into the actual application. I think we should have done a lot more. If we were to do it again, we would have done a lot more there in the beginning. There are ways to do that where developers are ok with it.
Priyanka: Everyone listen to that. I am an angel investor and advisor and people are constantly asking, "should we just not do any telemetry?" And it's like, "No, please don't do that." And I think that's what you're saying? Right?
There are so many things we think about developers that aren't necessarily true.
You can have opt-in, opt-out, there are ways to do it, but you don't need 100%. So you can get that data because that would give you a much better image. We're working on that.
We're also building a better organization. We're 70 people now, so we got product managers, we have analytics people. Things we did do well though in the beginning are two things that I recommend people to do. We're product-led growth. Meaning it's free. We want as many people. Community comes first before revenue and enterprises.
The first thing we did that I'm proud of and that was good, is that we emailed every single signup in the beginning. And we asked them just one question, "what kind of feedback do you want to give us?" There was nothing we were trying to sell. We're still not trying to sell it to the community.
We would jump on the phone with someone administering a website for a small church in Milwaukee or someone working for Procter and Gamble. It actually wouldn't matter for us, because we wanted that span. We wanted to be ubiquitous. But we're also a product. So that's the one thing I recommend people to do.
The other thing is to be bold because we're also a product that quickly gets enterprise tension. Because the problems we're solving, they are exponentially worse for a complex organization. So after six months we had companies like Burger King, et cetera, contacting us. I think that the advice I would give people then is to be very careful on what your motive is for starting to work with these kind of companies.
We have turned down some very large American organizations because we saw this would drive the product the wrong way. They have the wrong expectations. They will work us in the wrong way. We would not build features for just Burger King, we still don't. We build features for the community. We build for enterprise sometimes of course, and we're building a business and our revenue is growing well, but we're always being careful the kind of enterprises that we work with.
I think especially if you have high ambitions to grow really fast, a lot of people are afraid that VCs would ask you to have revenue. I think that's completely wrong. That's a wrong VC. Don't work with them. Work with folks who understand us like Heavybit, who understands the reason for this bottom-up motion.
Of course you would have to understand how people would buy your things, but you want the right kind of enterprises. And if you manage to do that, great, then you could get something that continues to be ubiquitous. You don't choose between a 1, 2, 3 GTM motion, if you've listened to Adam Gross' talk, you actually want a balance. It's harder, but if you get it right, that leads you to exponential growth.
Priyanka: So I want to double click a little bit so that hopefully the audience can get more out of this very meaty answer you just gave. You mentioned that if an enterprise like Burger King is asking for certain features, you have in the past said no. But if there is a community member or developer who happens to work at the Burger King and they have certain asks, does that change the dynamic? Can you give examples of some things that you say yes to and somethings you say no to?
Magnus: We don't just say no, we're empathic people. We say we understand and "this is why we're thinking like this and that and we may do this at the right time." But I think of all enterprise customers as being part of the community. There are still developers inside organization. But what has always been guiding us is that if it doesn't serve the community, think twice before you think about making it.
Priyanka: So what I want to ask you really quickly Magnus is, when you say "we will build it if it's good for the community," what do you mean by that? Is the community all users?
Magnus: So when I say community, I mean all the users. This is unique to us, because we want this ubiquitousness. It may be different for other companies, but for us, if it doesn't benefit a smaller team, we should think twice. Sometimes we do that. It could be security features, it could be other things.
But I think especially what you want to watch out for is these use cases and features that drive you down a particular path. Because very often, sad as it is, these enterprises they need to solve a problem, but they don't have the same criteria for solving that problem. They don't look for really low friction, instant gratification, or these aha moments that you really need to win broadly.
So if you have big ambitions, you need to listen to those smaller communities because they would go otherwise if you don't convince them in three minutes, whilst the enterprises may have to invest like 10 hours to fix that problem. We love everyone. We just love them in different ways and want to interact with them in different ways. We want to be careful with our motives, and that has guided us from day one.
I also do some angel investing and I see that that's a problem for a lot of young founders especially
when they start to get traction and there's money dangling and they think that's the way to get funding. And I think actually it's not.
If you manage to do it right, you could do it right.
Priyanka: That is really, really helpful.
So continuing on, Rajoshi, I'd like to ask you, in your experience, can you share some time where people may have asked for a product or a feature request that you have had to make a difficult decision to say no to? How has that impacted you folks? Do you regret it? Was it great? Would love to hear.
Rajoshi: Yeah, we actually have a really interesting answer to this one, and this comes from how we built Hasura again. Specifically about adding authentication. People look at Hasura as an application development, like you're building your application on it. We give you data APIs. So everyone's like, "why don't you just solve authentication for us?" And we have battle scars.
We had authentication APIs from agency, that platform that we broke apart and went to market with this piece. We had authentication. And we realized that as we spoke to a lot of people at that point that that doesn't end up scaling, most people have their own authentication solutions, there are amazing companies solving it. We wanted to make it incredibly easy to integrate, and not build it in-house because that wasn't core to that data access piece.
So that's a very specific example, but this has come up a lot because we are also that bottom-up community-led option. So people wonder, "I'm already using this. It just feels like why wouldn't you add this? It makes so much sense." So we've had to say no to that very explicitly.
And I bring this up because this is probably the most asked question that we've had. And it's also something we have opinions about, and so it's easy for us to talk about it and that's because it's really something that's at odds with the vision and the core problem that we're solving, where we can have a 10X impact. We are not going to have a 10X impact ny being your next authentication provider.
Having said that, that also means that people want this problem. So we're not going to ignore it. We just make the developer experience around integration much better. As some of these companies and teams have scaled, they've seen that, they've come back and realized that the fact that they went with a separate provider was not a bad decision. So I think that's one very specific example that we have.
But at a more abstract level, I think the way we think about it is that anytime there is a request which is some kind of bespoke request, it comes back to the team.
We look at it from a product vision perspective.
It might already be part of the roadmap but a little bit in the future. Sometimes it's a little bit different from what we had initially thought about, but it felt very compelling and we could see that it's not just a problem for this one user. Again, it's about being able to talk about the problem and not of the specific feature.
So if there's conviction that this is something valuable and it is also a user that is 90% there with Hasura, then this is helpful and it's going to help us with not just this user but many more. We have to think about how it can be integrated back into the product. That path is planned out from day one.
So it's not like, "Hey, we'll do this and then it's suddenly a different product deployed for this company." No, it's a solution that is designed in a way that it could come back into the product and become a part of that solution. So it's used for POCs but it makes its way back.
That's happened a few times and it's actually added some incredibly interesting features to our product that has been appreciated, not just from the larger companies, but also across the community. So we've had some really interesting use cases like that.
Magnus: This made me think about another thing. The same way I said we as users become so into the product that we need to take a step away, I think the same thing happens in a community if you have a good community. Because you have some people and those are often those who speak the most, who really love your product and they're fantastic. They're the cornerstone of your community.
At the same time you need to think about what you're trying to solve. Because you can't solve everything. And a lot of those users really engage, they have some problems that are really deep into your product. And especially in the early days, that isn't necessarily what you should go and solve, because your product may be good enough, the best product doesn't win, it's about distribution.
It's about taking down the friction in the beginning. This is something we had to tell ourselves many times, and that's often when we say no. We're not going to build that because we're trying to fix this thing that nobody asked about. Because most people in the world have no clue who we are and haven't used it yet, and we're actually making the product for them.
Priyanka: So David, I want to ask you a different spin on this question, which is, have you ever built something no one asked for? Something very esoteric, but because you knew it's going to be useful. Even if maybe small subsection of people will use it, either it'll be just game changer for a certain audience or it'll help you so much in the marketing, in the go-to market that it's worth it. Do you have any stories around that?
David: Yeah. A few come to mind. A big part of Tailscale is open source, a lot of our clients' software are as well. That really helped with our initial go-to-market and getting us into good graces with our community.
But it also really helped in the way we were launching too, because people would often approach us with very esoteric devices and they're like, "I want to run Tailscale on this. Can you make a build?" And we're like, "Oh, you can make a build for it. Here's the code. Just go compile it and install it." And in early days, some people with network addressing a storage like mass devices started approaching us being like, "Can you make a Tailscale client for my Synology mass? And we were like, "Well we don't really have time to do it. Here's the source code."
Then very quickly some people started turning around these things and publishing branches of open source repos, and support for this, and even writing blog posts. Like "here's how I got Tailscale running on my mass." It got to the point where there was enough chatter, and things on Twitter and HackerNews and elsewhere, we were like, "Okay, we should really just do this ourselves," because we want to give something back and we also just wanted to take, not control, but just put more effort into this.
So we did with Synology and in particular we reached out to Synology and they were keen to help us out with this stuff as well, because I think their users had also been asking them for a better remote access solution for masses, but the long story short, we built and published an efficient Synology package and got it into their store. Then literally the same week the numbers just jumped.
And it was surprisingly, I think it was probably 10 times what our CEO was predicting in terms of the impact. We see it now, we go over week and it's just one of those things, it's like, "Oh my gosh, there's an entire community here. We didn't even realize." And I think to the engineering team's credit on our side, it didn't require a massive amount of work, but it just required some dedication, and some focus to get it through. But now we're in this phase where we're like, "What are we missing? What's the next big opportunity?"
Priyanka: What else should we build more?
David: Yeah, exactly. What else should we be doing? But how do we prioritize those? We've got this massive list and probably a lot more uncertainty now, but it's also extremely exciting. In some ways it feels like the early days of Tailscale. Because it's just like, "oh, there's all this untapped potential."
Priyanka: Yeah. So "go beyond the sniff test" is what I'm hearing, for when you're looking at a potential product development or a feature to build, because as you found out, you thought it was a small win that was coming and instead you got a whole community. That's pretty great.
David: Yeah. And a big part of that was just getting into the Synology store. Our users, for instance, a lot them use Tailscale at work and build their own versions of the client. They're extremely capable developers. I'm sure they can do stuff the same way our team can do. But that's not really what unlocked this particular opportunity. It was definitely a business side to it, which we didn't understand at the time.
As a company grows it has to just move beyond its comfort zone. And this is what we're learning as well.
Partnerships and integrations and collaborations and what do those mean for us and how do we fit into this broader ecosystem?
That's the phase we're in now. We're just uncovering it. Oh, there's so many different ways we can work with other people, and it's extremely exciting but at the same time how do you go about validating those opportunities and prioritizing them? That's a whole other set of challenges.
Magnus: Yeah. We see the same. It feels like until you have a proper product organization that we're looking at building out now and get a lot of more structure around it, then it really comes down to getting a lot of signal. Then getting the team together, of course including founders, but also others on the team to say, "Okay, what do we think really makes sense here? What is are gut feel?" We'll make some good bets, we'll make some bad bets.
But I don't think you could quantify your way from a community and all the feedback before you do it properly with product people. That's been my experience at least, maybe I don't know if others see it otherwise. We struggle to find a good way to make a good system. We've been making GitHub requests, make all these GitHub issues, look at them, quantify them and all of those things.
Rajoshi: I agree. Yeah, that resonates very strongly. We're still trying to problem solve that. We should talk.
Magnus: Let's talk about that. So far it goes to what David said, the gut feel and trusting yourself.
Just because it didn't turn out well doesn't mean it wasn't the right thing to do. You just have to iterate.
Try to keep things small, has been a thing for us. The times when we made something really big we had to have higher conviction. It also turned out well for us, but it is also often then been on gut feel as well. There's a lot of gut feel on our side, there are probably better ways to do it. But that's been our journey.
Priyanka: I was just going to say even back in my GitLab days, iteration was so important because you're bombarded by signals. Some of which may be noise and then you have your own instincts. So one of the things I remember from my time there was
minimum viable change, not minimum viable product.
And it's funny because now I run an ecosystem. And even in that, with any changes we bring I'm realizing iteration is key because nothing works out of the gate the way you think it's going to, whether it's in people, processes, tools, technology, it doesn't matter.
Rajoshi: One quick interesting things that I wanted to point out because this has happened I think twice with us-- the flurry of requests, which are of the same type, and not being able to service them fast enough, it's resulted over time. It wasn't like we woke up one day with this, but it's resulted in a slight shift in the product strategy, where you're able to make things a little bit more pluggable, and that's amazing when it's an open source community and product, where then suddenly it becomes accessible to folks.
One of the things we're working on for next year, which is what I was talking about earlier re: integration with the auth providers, but any integrations with any API. Making that system more pluggable so you're not restricted by what Hasura supports, but you're able to go add that. So that's come sometimes from this not being able to service the flurry of requests and having being forced to come up with a more elegant solution which you hadn't thought of earlier.
Magnus: Same. We've done the exact thing this year, invested a lot in rebuilding our own stuff so it's easier for us to build, but also easier for the community. Totally with you.
Priyanka: Yeah. I think that's a big part of the beauty of having open source baked into your product, right? One of the big value-adds of having an open source-first approach is that people will help you. People will build with you, and there's no way you can build everything everybody wants, but this way they can go do it if they want it enough.
Magnus: I think this goes for anybody, but you shouldn't always listen to your customers. They don't know exactly what they should have, but also you have to of course listen to them. Although you don't think it's the right thing to build, you still have to sometimes build what the community wants, because if not they're going to stop caring.
So we've seen that at times when we've been very focused on building our own things, we've had to realize, "Okay, we actually been not attending enough to the community." And if you neglect them for too long, they will stop caring because why should they spend their spare time giving you feedback? So even though you may have different views and perspectives, you have to also give the community what they want. So there's just a bunch of balances and trade-offs.
Priyanka: Absolutely. And I think you folks do it every day. It's not an easy job, but you all seem to be doing a great one of it.
As we draw this session to a close, I would love to ask all of you to share, if you had just one piece of advice to give first-time founders who are figuring all this out, how to transform their vision into a robust product that's used by hundreds, thousands, millions of people, what would you say? And I'd like to start with David.
David: I've got lots of different pieces of advice, especially as an operator. But I think the one I would like to leave this call with is, choose a small problem at the beginning, like a specific use case and get it to 100%. A lot of companies fall into this trap of thinking they need to build more and more features to get customers. But in reality it's the fact that
they're missing the one thing that would just get everybody else over the line.
So it's really important to realize what those barriers are as opposed to just trying to keep on adding more and more things.
Priyanka: What about you Rajoshi?
Rajoshi: 100% on what David just said and to add to that. I think the one thing that I would say is, if you're able to find a natural distribution or an easy distribution channel right from the get go, then you get to ride on some of these tailwinds.
So as you're thinking about what is that one thing that you're solving in a 10X better way, also think about that distribution factor and see if you're able to align with a distribution factor, because then you take that 10X and you figure out that one piece that you're going to hit, and then that immediately takes you to the close.
For us it was open source and GraphQL and that made it really easy. It's very focused. So yeah, that would be my one tip.
Priyanka: So focus on the problem that you're solving and the people you're solving for, is what I'm hearing from both of you.
Rajoshi: Or rather cherry pick an audience, or a distribution channel.
Priyanka: Yeah, I 100% would underscore that. The tailwinds that you get when you get a euphoria in a community is so much bigger than a dispersed product. Magnus, what about you? What would you like to tell the budding founders out there?
Magnus: Yeah, very good points already mentioned. Mine would be, think about distribution from day one. And if you don't believe in product-led growth and open source and free, go back and think again, until you do. Because the only way that you could really win big is if you think big.
I's harder, but it works much better, and there are so many companies doing it successfully. So a lot of founders say, "Of course, I'll do that." But there are still a lot of founders who find it hard.
You cannot do PLG as an afterthought. It has to come from your heart in the beginning, of how you think about it, and find your way to build a community.
If you have open source elements or whatever, that of course makes it easier and fantastic. But in many ways, to build communities, you just have to have that mindset from the beginning, you have to care about the ones who don't pay you because they're part of your product.
Priyanka: Oh, that's a very good way of thinking about it. They are part of the product. That's cool. Awesome. Well folks, thank you for giving me your precious time today and sharing with all of us here in the Heavybit community your stirues on developer discovery, product development, and your journey so far. I am confident that a lot of people have benefited from this and I hope you enjoyed it too. Thank you so much for joining it.