Open-source-led growth with Project Discovery founder Rishi Sharma

by Andrew Askins 3 years ago 9 min read

Rishiraj Sharma (Rishi for short) is the Co-founder and CEO of ProjectDiscovery… and also their lead designer, which is an unusual combination for a security company.

ProjectDiscovery is an open-source software company that has built multiple popular security tools (they have more than 20,000 stars on Github). In early 2021, they raised a $1.7 million seed round to build out their community-edition Attack Surface Management tool.

Before founding ProjectDiscovery, Rishi worked as a security engineer for 7 years. His career started with bug bounties and quickly shifted into pentesting and the area of apps and product security. He’s an incredibly talented designer and ProjectDiscovery is gaining a lot of traction in the security community, so I’m really excited to share this interview with all of you.

My favorite highlights:

ProjectDiscovery built a community of thousands before raising a dime through open source and word of mouth
Founders should understand design, because design is ultimately about communicating your ideas in the simplest way possible
The PD team uses Orbit.love to categorize their community and then reaches out to individual users to test new features and ideas

Here is the edited interview with Rishi Sharma:

AA: Can you tell folks a little bit about what ProjectDiscovery is and what you're aiming to do?

RS: ProjectDiscovery is an open-source software company, we are developing tools and products that are used in the day-to-day workflows of application security engineers and enthusiasts. We began as a side project; we had no idea it would turn into a company; we were just doing it in our free time. And, thanks to open-source adoption and the community we created as a result, we were able to raise funds and go full-time into PD six months ago.

AA: Your background is as a security engineer. So how did you learn design?

RS: I used to work pretty closely with the product team and I've worked in different startups as well as different security companies. My day-to-day work was to explain the features we were building to the product team. So I used to collaborate with different designers, for example explaining to them how to turn specific workflows into UX elements.

If you have a designer who is not from security, it's really difficult for them to turn complex ideas into designs. Within a few months, to minimize the effort that I was putting into the design, I started wireframing; then I started editing the files designers used to compose. It was the era before Figma, so we worked in Photoshop and Sketch at that time.

So I started directly editing the files and within a year, I got really confident. Then I started designing and building the tools for myself. Historically, even before working with the designers, I was always interested in design and music, and I'm also a really OCD person so that helped with precision as a designer.

AA: Were there any resources that helped you as you were learning, as someone who didn't come from a traditional design background?

RS: I would randomly browse through various profiles on Dribbble, where I found designer profiles from some of the companies I was really a fan of: FrameIO, Stripe, and Framer. I used to read their changelogs and use their apps almost on a daily basis to see how they approached UX fundamentals.

I would also directly go through the Sketch files my designer had worked on.

Apart from that, InvisionApp's blog was one of my first reads, and it was extremely useful in allowing me to gain insight into the perspectives of some of the top product designers from leading enterprises. That allowed me to improve my UI/UX skills as well as my product thinking.

AA: What does your design process look like now for PD?

RS: First, I dig deeper into the details of the expected features, and then I create high-fidelity mockups and then within a few back and forths, I turn them into the final design.

With PD, our team gets to work with a really diverse community of thousands of users. So, you can really easily empathize with different types of users and dig deeper into their workflows.

Right now, we are doing it on a very small scale. We have categorized different user bases on Discord internally so we know who are appsec, who are red team, or who are bug bounty. We go and talk directly to them on Discord and see what they are expecting around certain features.

We also use a tool called Orbit.love. Basically it scrubs your users from GitHub and then correlates their different profiles on Twitter or LinkedIn, so you can easily categorize them and create a community insights report.

Also, all of our engineers have a security background, so I can work closely with our team and see how they react to new ideas.

AA: How do you sort out which user feedback is valuable and which isn't?

RS: It’s difficult in security because you have a diverse user base: some are using the product in their personal workflows, others are using it internally in their organization, so it's difficult to define what we ultimately need to make.

Right now, our approach is to make sure everything is modular enough that it can easily be adopted by different users.

Also, with a large user base, we constantly receive all sorts of feature requests that we need to prioritise. For example, right now we are focused on the attack surface management workflow. So, we only include features that align within that framework and don't create clutter.

AA: Can you talk a little bit about the early days of building the open-source tools that became ProjectDiscovery?

RS: I was using Subfinder in my day-to-day workflow at my previous company and found it really cool. I met the authors and top contributors of the repo, Iceman, Marco and Sandeep through Github.

So we started chatting about different ideas we were using in our companies and since we were all engineers, we started building out those ideas. Within two or three months we became really good friends.

What we wanted to achieve at that time was ASM (attack surface management). If you are in AppSec working in an enterprise, your typical workflow revolves around ASM.

I think within five or six months, once we completed the initial prototype, we thought: since we all met through GitHub, why not make it open-source? And I still remember when we open-sourced one of the first components, we got around 100 stars on GitHub within a month, and one or two comments on Twitter too (all of the growth was and still is word of mouth).

We were flipping out, like: this is great, people are loving our tool. That gave us enough motivation to continue building it. And within a year we got more than 10,000 stars just by releasing other components that were in that framework back-to-back. At that point we were seeing more than 10,000 weekly downloads across our repositories. That was crazy for us and that was when we started receiving emails from VCs (Venture Capitalists).

We never thought PD would be a company, we were just doing it in our free time, so it was really tough for us to decide whether to raise or not. But then we realized if we went full time on PD, we could actually contribute a lot to this area of tech. At the same time, since we all started from GitHub, it was really difficult to push into the area of commercial and we were very particular in our raise planning.

Fortunately, we found really great investors who understood the ecosystem of open source and how its adoption works. It's now been six months since we raised the funds.

AA: How do you think other founders or product people should think about that decision of whether to release an open-source product or even start with an open-source tool?

RS: I think Infosec needs more open-source companies. If you go check out our initial repositories that we released a year back, they are completely different from what we have right now. The constant feedback we received from the community allowed us to build highly technical tools they could use in different areas of their workflows.

We strongly believe the open-source model is the best way to understand and solve some of these technical challenges by establishing a community where people are engaged to discuss, help and solve issues.

So for security, I think we really need more and more open-source companies that start with a bottom-up approach where they build the community first and then they build the product on top of it. Because it really shortens the time to design the best experience for your product’s features, as well as solve some of the technical challenges with the community.

AA: Are there any situations where someone in security shouldn't open-source or shouldn't pursue a product-Led growth approach?

RS: If you have IP that you really want to protect, don't open source it, and if you're making consumer-oriented products where technical challenges aren't a major issue, the open-source community isn't really needed.

But if you want to work on a bigger framework with diverse people who contribute to or use that product, then you should start from an open source approach where you give customers direct access to the product and see how the feedback and designs overlap.

Innovation should be independently thought out, implemented, and tested, and only then can we imagine it fitting into various user scenarios. Commercialisation is a difficult process in and of itself, as it necessitates developing business-sustaining strategies. This is an extremely difficult process; some companies have failed to do so, while others have successfully built the right transition.

AA: When does the UI become important in a security tool? And when is an API or a CLI (command line interface) a better option?

RS: We started with a CLI. We were still polishing the technical components that were needed to make the engine efficient enough that we could easily put it behind the UI. Also the CLI and API are still going to be there once we build the UI. They are needed for integrations, or for users who want to plug them into one of their workflows.

Once we polish the engine we want to use behind the UI, then the interface comes. The point of the UI is to minimize the learning curve of the tool and speed up the workflows that you constantly use.

AA: What skills do you look for in a product manager?

RS: It's been really difficult because there are very few companies in Infosec that are built from an open-source, bottom-up approach. So, we are looking for someone who is deep into security and understands the open-source ecosystem, the advantage of community, how the community works, and how to drive the product through it.

They really need to be able to empathize with users. Most of the community users are basically enterprise users, enterprise engineers. So it is crucial that we can empathize with their workflows and can design the product for them.

Product Management is a really long process: you start from researching, all the way to the making of the product. And once we get into the stage where you have finalized the product, then there's another long process of making it simpler or the UI more friendly.

AA: That leads perfectly into my next question, which is: what are some of the challenges that make security products so hard to design?

RS: If you work with a designer who is not from CyberSecurity, it's very difficult for them to convert ideas into an end product. It's a really technical thing. First, you really need to empathize and understand what the users’ workflows are, and then you need to create some ideas around it.

Now, leaving this task entirely in the hands of your designers won't help the end product; you'll need a commitment from one of your founders or PM to work closely with the design approach. That's why the majority of the cyber security products we have are overly complicated, as most of them lack the commitment (from founders and PMs) to account for UX and design during the product development stages.

AA: How do you think we can attract more designers to CyberSecurity and make it easier for a designer to get up to speed?

RS: I think one of your founders should know about the design process or the UI and the strategy around it. If you have a founder who knows about design, then it's easier for the company to build the end products. You can more easily hire ideal designers and work with them to turn your ideas into reality.

I think the process of design should be taken into account by the PMs as well.

AA: When do you think the right time is to prioritize design?

RS: If you are a very early stage company and do not have any great visual designers in your team, or you do not have a budget to outsource that, you should still focus on turning your ideas into a really simple interface, there are many open-source frameworks, libraries, and design systems available to help you do so.

Design is not just about the visual form of an end product: it is also a simpler manner of explaining your ideas to the end users— and that's something all founders need.