Construction teams are adopting technology faster than ever before. But do you know how your new tools are actually built?
If you’re exploring new technologies to bring on-site, it’s helpful to be able to look behind the curtain and see how they’re made. This answers a few questions that may be on your mind, such as: is my drone software vendor actually focusing on my needs? How will this tool evolve over time? How easily can I give feedback, and will it actually be heard and implemented?
In this interview with Jess Lam, our Director of Product, we’ll answer all of these questions and more, giving you an inside look into how we build products here at 3DR.
Hugh: What’s your product philosophy for Site Scan? What are the principles that guide the way we build new features and products?
Jess: I started as a Product Manager at 3DR two years ago, and one of the first things I worked on with the team was defining a clear product philosophy. What we came up with was simple, but it covers all the important points for us: “We build measurable solutions from our customer’s point of view.”
Breaking this down: we build solutions—which solve real problems—not just features. They’re measurable, so we know what kind of impact they make. And most importantly, this is all from our customer’s point of view: what we build needs to matter to our customers. What we can and want to do as a technology company is secondary.
What were some of the main things you learned in the early days of building Site Scan?
In the early days, we spent a lot of time on-site with our customers, learning, observing, and understanding how they work. This was crucial, because we learned more than we ever would have by doing industry research or talking with them over the phone.
When it came to drones, we found that our customers had two top priorities: safety and security. It’s no secret that safety is priority number one on any construction site, and we wanted drones to help with this, not create more headaches. So, we took extra steps to focus on safety in Site Scan: such as investing heavily in test engineering and building checklists and failsafes into the flight experience to reduce errors.
The second thing that stuck out to us was data security. The construction industry is using cloud technology more than ever before, which naturally raised data security concerns with many customers. So, we made data control a key part of Site Scan: our customers have full control over who can view their drone data, and what they can actually do with it.
We knew that if safety and data security weren’t baked into our platform from day one, it would never take off. We’ve invested in that right at the beginning, and over two years later, it’s still a top priority for us and our customers.
To this day we go on-site with at least one customer every month. We’ve visited all types of projects and worked directly with the teams in the field. There is no better way to learn.
Many of the features we build are brand new, and come as a result of talking to customers and uncovering their pain points, but understanding customer needs can be hard. How do you do effective customer research?
To me, the most important thing is that when we visit a customer, we don’t go in with solutions that we want to pitch and see what sticks. That’s often an approach that technology companies take—they’ll say, “How cool would it be if you could…?” without fully understanding the problem in the first place.
Instead of doing that, we visit our customers with questions that we want to answer. We have a long list of problems that we’ve identified—some are specific, some are a bit higher level—and we drill down on one of the problems with them. With their team, we walk through workflows step-by-step, observe activities in the field, and ask a ton of questions. Then we gain insight on what we need to do to solve these problems. This approach forms the basis for how we do good research: we go on-site, interact with people across teams, and observe their entire workflow.
Once you’ve done your research and found problems that you can help solve for your customers, what’s your immediate next step when it comes to actually building that solution?
It often starts while we’re still on-site with our customer: we immediately start sketching out the workflow of what this new feature could look like. We’ll do this sketching with our customer, while we’re in their trailer on the jobsite, when ideas are really fresh. We build features together, and interestingly, a lot of times it’s our customer that’s actually driving the details of the workflow and helping mock-up its interface.
Then, once we have the groundwork done, our product and engineering team will flesh out the design, start development, and try to catch all of the edge cases that we didn’t originally consider. Before the release, we’ll take that same feature back to our customer and have them try it out. This helps us make sure it’s actually solving their problem—if it’s a little off the mark or hard to use, we make improvements and test again.
One interesting thing to note is that we run extensive beta programs for big features. We just finished one for the all new Site Scan: we had 18 customers from across the world, including Australia, Japan, Qatar, Canada, and the US. They have different backgrounds and roles, some are surveyors and engineers, others are superintendents, project managers, and VDC managers. Having this variety of feedback helps us touch all the edges of what our product can do.
What it comes down to is that our customers are integral to the way we build our products. They have input and feedback on features both before and after we launch them.
Our customers are integral to the way we build our products. They have input and feedback on features both before and after we launch them.
How do you go about understanding and analyzing customer feedback, then making it actionable?
We get a ton of requests for new features from our customers, so what we focus on as a team is deciding what to build, when to build it, and how to build it. We have a diverse customer base, so we try to find common problems and come up with a solution that works for everyone. We check and rank feature requests every day. When it comes to deciding what to build, obviously an important factor is the sheer number of times something has been requested.
Another important factor is how widely adopted a particular feature might be. For example, if we’re considering a new feature and our research shows that know that 80% of our customers would actively use it, we’re going to build that feature before the ones that might sound flashier, or will generate more buzz, but with only 20% of our customers expected to use it.
It can be tempting to build whatever the hot new technology is in Silicon Valley, but we’re mostly focused on creating the tools that our customers can use today, in a month, or in 6 months. Because they need value now—they don’t need something that sounds great but doesn’t solve an immediate problem.
On that note, technology companies tend to have different power centers in terms of what drives the evolution of their product. We’ve always thought of ourselves as a ‘product-driven’ company. What does being product-driven mean to you?
I think of being product-driven as solving problems. We want to take our customers current workflows—the things that are really slowing them down or making life difficult—and exponentially improve them. To me, that’s what being a product-driven company boils down to.
Here’s an example: last year, we found that it was fast and easy for our customers to fly their drone and collect data, but they were getting slowed down when it came to collecting and tagging ground control points. So we focused on that bottle-neck and designed a new ground control point workflow that was simple and completely cloud-based. This helped take the workflow of surveying a 20-acre construction site, for example, down from a few days of surveying to less than a day. This might not sound fancy, but this is the kind of innovation that’s exciting to me because it’s exactly what our customers need.
The more we focus on automating slow or inefficient workflows for our customers, the more time they can spend focusing on their work and solving critical problems.
Can you give me some more case studies of this in practice?
Absolutely. We recently visited one of our customers, a mining company in Mexico. They had a specific use case in mind for Site Scan, but when we met with their team and learned about how they work, we uncovered a new potential capability for them: using the drone for geological surveys and mineral exploration. Their team was doing exploration on foot and taking photos by hand, a process that took months, even up to a year to finish fully.
We quickly realized that a drone could do this in a matter of hours, helping our customer find new areas to dig. By the end of the visit, we were starting to build a new feature with our customer to enable that capability, and it’s now under development by our team.
Another example comes from working with one of our construction customers, PARIC Corp., a contractor based in St. Louis, Missouri. They’re advanced users of Autodesk tools, especially BIM 360, Civil 3D, and Revit. PARIC was looking for a way to connect their Site Scan data to their BIM 360 account to streamline their workflow for transferring drone data. So, we flew to St. Louis to spend time on-site with the PARIC team, learning about their current workflow, its pain points, and how we can make this workflow more efficient. We ended up building a prototype of our native BIM 360 integration while we were still on the jobsite. The integration launched earlier this year, and we owe a large part of its unique features to the time we spent on-site with our customer and understanding their pain points.