Back to resources

Meeting the Needs of Your Product’s Core Demographic

Product
Users

17 May, 2021

Shivan Bindal
Shivan Bindal

Head of Platform Products at AuditBoard

Shivan Bindal, Head of Platform Products at AuditBoard, goes straight to the source when assessing product-market fit for a product.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

How to Successfully Rebuild Your Product

6 June

Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight