Forging my own path for product development

When Wesley Elfring was a child he wanted to grow up to work in film. Now, as a product manager at Hadrian, he is still telling stories just in a different way. In this blog post, Wesley talks to us about how to determine your product priorities at different stages of development, how to unite talent across different disciplines, and how interactive storytelling can be useful to showing the value of your product to customers.

Product manager is a role that has many definitions and responsibilities. So, to start with a simple question, how do you define your role as product manager?

I’ve never been in two companies where the role was the same. Everyone who is a product manager has a formal set of responsibilities, and then many responsibilities outside of the role itself. There is a quote that everyone uses that talks about product management. It’s from Martin Eriksson and he says that, “Product management is the intersection between the functions of business, technology and user experience.” It’s a very variable role where you’re constantly thinking about how to build the best technology, how to fit it into the market, and of course how to create value for your users.

Do you feel that different responsibilities and focuses become important at different stages of the process?

I think it depends on the team you’re working with and the product you’re building. When I joined Hadrian, we were growing really fast on the development side. We were onboarding so much top quality development talent, and it was about structuring the workflow, and product requirements as the team grew. Especially with such an influx of new developers it was important to make sure that they were all aligned on what we were building, and then creating a process that would help them work efficiently towards that goal.

Hadrian has come a long way since 10 months ago. How do you map out the path that you want the product to take, and what the focus is going to be at each stage of the process?

At Hadrian we were really lucky because we had such a strong base of people who were experts in the field. It was never a situation where the founders had a great idea but didn’t know what they were building. They had a great idea and knew what needed to be done to build it.

The hacker talent was crucial to mapping out the product’s directions. The hackers have so much experience and know what the customers would be looking for and which technology we would have to target to be able to deliver that. In that sense it was easier to define the road map. In addition, there are similar companies already on the market. In that sense the field had been mapped out already in terms of a baseline set of features. We knew we needed to establish those features, and that gave us the opportunity to already start thinking about how we were going to differentiate ourselves, and add unique features on top of them.

Was it difficult to sift through all the information that you had available, and to really establish priorities?

In all honesty, as someone who does not have a background in cybersecurity, the amount of information we were faced with was a bit daunting. At first I found it difficult to make sense of it all and target the right priorities, but I’ve become so much better over the past months that I’ve worked here. The process has been challenging and illuminating.

To make sense of it I read a lot. There are a lot of great blogs available, and I also took courses. HackerOne - the bug bounty platform - have courses that teach you how to hack. I’m a hobby developer so I knew where vulnerabilities were likely to be, and understood how vulnerabilities are added to software, but I used this as an opportunity to learn how to find them. It really helped me to understand what the hackers were doing.

What really struck me as I became more familiar with the infosec industry was how many different roles there are. It’s not just one hacker. There’s someone doing triage, there are infrastructure teams repairing the bugs, and there are red teams who are actually hunting for the vulnerabilities. It expanded my understanding of the number of internal users we were actually creating the platform for.

Have you felt that the priorities of product development have changed at all since you arrived?

I don’t think the actual priorities have changed too much, rather our understanding of the product’s value has grown. Our partnership with HackerOne has been really interesting. To be able to take the attack surface management aspect of the product and make it accessible to another company and its users has really proven its value.

We always knew that attack surface scanning was an important commodity, but for us it was almost a prerequisite to the real work we had to do. To have built something that was this good, this early on in the process, has really shown us how useful Hadrian can be.

What’s the most exciting project that you’re currently working on at Hadrian and how do you see it fitting into the Hadrian product in the long-term?

We’ve gotten to the stage where we’re able to build the unique features that differentiate Hadrian as a product. Currently we’re about to start a big project which revolves around web application scanning.

Previously we’ve done a lot of tools related to network scanning. This new project is an opportunity to dive deeper into building intelligence software to test web applications. One of the goals is for automatic detection of APIs, automatic testing of vulnerabilities in the endpoints we find. We plan on building a big set of knowledge based on what we can see and query. Then we’ll combine all that information to make sure the application isn’t vulnerable. It’s a big step forward for us.

What has been the most interesting aspect of working with hackers to build automated tools such as this web application scanner?

Honestly, the importance of manual scanning. The goal is full automation, but in order to go beyond standard open source tools to create something really unique, you need to do manual scans as well. If you do a manual scan on a client, you can immediately see the gaps within your existing software. It really forces you to think about where a hacker would start the process, which at the end of the day is the premise of our product.

For instance, there is quite a common vulnerability that the hackers found, which we can now begin the process of automating: subdomain takeovers. Basically, it’s a subdomain misconfiguration, where someone forgot to remove some configuration which we can then exploit by using the same cloud resources as them. If they gave permission to their cloud service provider to run those domains, we can configure the cloud server to also host our domains on our behalf, with our content, allowing us to take over subdomains within their company. We began implementing this tool a few weeks ago.

Finally, I wanted to ask about your background in visual effects and interactive media? How did you come to work in cybersecurity, and have you felt any of the skills are transferable to working as a product manager?

If you ask a child what they want to be when they grow up, none of them will say product manager. For me, the answer to that question was always film.

I loved telling stories. In the Netherlands, however, the film industry is not really commercial. If you want to be in film you have a very limited selection of projects to work on. One of the roles that I had was in set supervision. I had the opportunity to work with many different individuals from different disciplines in post-production. We took the raw footage and made it into what it would be in the film.

In a lot of ways, working in post-production was similar to working as a product manager. You have a group of people with different backgrounds and skills and you have to help them be productive and focused. When I switched into development I jumped at the opportunity to be a product manager because of these similarities. I’ve loved it ever since.

How do you feel that telling stories plays a role in creating a product that is useful to customers?

Essentially, you’re telling a story about the assets that you have. You’re finding the asset, getting to know more about the asset, and then explaining the specific path of how you found that asset. When you find a vulnerability the path continues, and you want to show the different tools you used and the specific story.

These stories really tie into the visual graph that we’re building. The visualization helps to show the different paths to the asset in a way that is more intuitive than in a data table. When we start to bring UI into how we tell that story it becomes a very powerful visual tool.