Meeting the Needs of Your Product’s Core Demographic

Problem

The company that I was a part of dealt in the construction-project management space. The technology that they had built was designed to solve problems in the field. The products being developed needed to be as versatile as possible in order to accommodate all of the different workflows in construction, especially on a larger-scale project.

It amounts to a lot of data entry meant to track an ability-risk type of perspective. Imagine getting a shipment of wood or steel. You need to track who received the shipment on site from a reliability and safety perspective. The salaries paid to subcontractors and vendors also need to be accounted for.

The issue: the central office wanted to have as much visibility on one job site as they did on all of their other job sites. That was the market problem. We wanted our tools to be implemented with one another; one tool that tracks labor and another that serves as a dashboard on labor.

The problem was that this cross-functionality was being met with bad reviews. I was hired to take this product over and to turn it around for the company.

Actions taken

I did a bit of investigating and felt that something was not fitting. We appeared to be receiving more requests for the aforementioned functionality — what you have for labor, I need something like it for scheduling, or for inventory tracking.

On the one hand, we had our existing product, which was not doing very well on the market at all. On the other, we were getting lots of requests for things that were similar. I started first with the users who appeared to be detracting the products that we were already producing. I listened to their feedback and gained some sense of where I felt we could be pushing our current product further.

The feedback that I was getting: each implementation, schedule-tracking versus labor-tracking, for example, is different. You don’t have the same needs or capabilities when generating a report in either category. Consistency, then, would be one problem for us. What else? We actually needed to be relating these things together; change-orders could be used to create a ripple effect between overtime and the increased wages that would come as a result.

That was really the light-bulb moment for me. These implementations could not be tool-specific. The entire picture needed to be accounted for within the system if the product was going to be what our customers needed it to be. From the nitty-gritty bottom line, all the way to delivery and risk management, all of this information needed to be included in this larger story that our product was trying to present to the user.

Our data model was overhauled completely. We built an entirely new product that was situated at the top of the UI across our entire suite of products. A slew of new features made maintaining comprehensive records much easier across each site’s home office network. We had effectively standardized, simplifying everything and optimizing for the real-world challenges of the construction management industry.

Lessons learned

• Above all else: listen to the market. Do not develop in a vacuum. That’s what had our original product so far off-base from what our customers needed. Constantly be going back to your users and your customers.
• In industries like construction, you really do need an insider’s perspective on what makes a product useful. Experts will respond well to a product that is savvy and takes care of a real problem that they face daily.
• A lot of people get wound up in thinking about what comes next. Before going there, you need to make sure that where you are is solid first. In our case, the problem was never really solved correctly in the first place. We could not go on to what’s next, because we had no platform to build overtop of. You should always be iterating toward product-market fit.