While working on a product in SaaS domain, I came across a time when the customers asked for a feature to have no of downloaded apps in last X weeks or Y months. I could see that more similar analytical feature requests will be coming soon. So, I thought of building an analytical system to support such features rather than supporting only that particular feature. I briefed my engineering team about the request and expressed my interest of building the analytical platform. The engineering team shared their concerns of timeline, effort, and architectural/technical changes needed for building a new analytical system. Hence, they wanted to quickly provide that one feature.

I understood their concerns and asked them to provide me with estimations for time/efforts (in weeks) and changes needed for implementing that specific request and effort for a new analytical platform.

The team took 1 week of time to come up with the estimation for both. The estimation suggested 3 weeks of implementation time for one feature vs about 3 months for the analytical platform. The new analytical platform needed to have setting up a new analytical database, periodically transferring data from the other databases, and building a UI on this db.

I asked them if they can come up with an approach to provide that one feature in 3 or 4 weeks (I relaxed the timeline) but also work on the new analytical platform in parallel. In response, they came up with a plan to implement that one feature depending on existing platform/database and started architecting the analytical platform and putting sprint-wise deliverables for that for next 5 months. I worked with the project manager and the engineering team for the next 5 months to make sure we’re on track and answer any questions they might have.

Finally, after 3 weeks, I provided the customers with that specific feature and meanwhile, I continued to take other analytical requests in the product backlog. After 5 months, the engineering team implemented the new analytical platform/UI and this feature was moved to this new platform instead of existing platform and databases. Other analytical feature requests from backlog were also supported easily from this new analytical platform.

This is how I convinced my engineering team to implement an analytical platform rather than providing features in silos.

When I joined Company X, the team was working on building a new product, which was made of 10 out of box dashboards. The project was already 3 months behind schedule, and it was preventing us from selling our solution to customers because these dashboards were the main way the users would interact with our solution.

When I looked into reasons why this was so delayed, I found out that the team was trying to build a custom dashboard experience: they were using a charting library and developing all the dashboard features around these charts. But I knew there there are many data visualization solutions (like tableau, Looker) out there that we could OEM and integrate into our product, that would allow us to build these dashboards much faster. In addition, with a visualization tool, we could give our users the ability to create their own reports and dashboards, which was a feature that all our customers wanted.

I first investigated why we didn’t consider integrating one of these visualization tools and why we chose to build it ourselves. I found out that 2 main reasons: 1) everyone thought that our users needed sophisticated filtering and drill down capabilities that these tools would not be able to provide. 2) There was also a concern from from engineering, because they didn’t believe we could find a solution that would fit into our architecture and platform.

Working with our customers, I wrote down the user interactions that we wanted to achieve as user stories. Working with dev team, I wrote down all the platform level requirements that we would need this visualization tool to meet. I identified a list of 8 companies that provide visualization tools and reached out to them to see demos of their solution and go thru my requirements. I made sure out CTO and head of engineering was part of this evaluation process as well.

We were able to find a visualization tool that met all our high priority requirements. The cost of OEM’ing this solution was significantly lower than hiring a full time engineer. In addition this would accelerate our roadmap by 1 year, by allowing us to develop the self-service dashboard building experience to our customers one year before we could have with the custom dashboard approach. This cost/benefit analysis convinced our CTO and engineering to integrate this tool as our dashboard visualization solution.

As a result, we successfully launched the two products (10 out of box dashboards and custom dashboard building experience) 3 months after making the decision.

Background Context

I’m a PM at a venture-backed SaaS in the legal tech space. We provide end-to-end contract management experience for our customers with the following features:

• Upload – Contracts signed in DocuSign, etc. automatically uploaded to our system through API integrations.
• Data Extraction – Contract terms such as payment terms and key dates are automatically OCRed and extracted using ML.
• Analytics – Contract terms are searchable, filter, and customize for reporting.
• Workflows – Business processes are created around contract events such as renewals, terminations.

The customer portal consists of table views and data visualization of those features described above.

Problem

Although our products provide insights into our customers’ contract terms, we don’t have a good sense of what data the customers value or want to see. Our customer portal doesn’t provide any personalization capabilities, given the current table views layout.

As part of the ongoing product development process, I spent a lot of time conducting user interviews to understand our users’ jobs and how our product impacts their work. Based on those user discussions, I develop a product vision to bring personalization to the customer portal so that our users can see content that matters to them as soon as they log in. For this to happen, we need to change the table layout for our users to customize the contents, which will require a lot of engineering efforts.

We have a small team of full-stacked engineers who work on all the front-end and back-end work. Unfortunately, we don’t have dedicated front-end engineers that can work on some of those initiatives. From my current experience of working with our full-stacked engineers, they don’t get particularly excited about working on front-end work, which sometimes entails fixing on bugs related to tables.

Epiphany

From talking to engineers in the past, I have developed the insights that engineers don’t feel particularly excited about front-end work because our current work culture doesn’t have enough emphasis on collaborations. Engineers have repeatedly mentioned to me that they don’t regularly see the impact of their work or have visibility of our customers. While implementing this particular feature is my main focus, I feel that it’s more important to figure out how to gradually change the culture of how we work at the company level.

Action

To solve this problem, I initiated the following steps:

• Bring engineers to user interviews so that they can see the impact of the product on the users’ work and develop empathy towards users’ problems.
• Organize white-boarding sessions with products, designers, and engineers to brainstorm and collaborate towards finding solutions.

I also researched how much time the engineers have spent on fixing bugs related to all the table views. The solution we developed also addressed the number of potential bugs post-release.

Result

Users were happy with the new table layout, where they can customize to see the contents that matter to them. We were able to collect data on what the users customize that would eventually be helpful towards the personalization product roadmap.

From my post discussion with engineers, I was able to get some positive feedback on how we worked together as well as other improvement opportunities.

Learning

As a product manager, I sometimes focused too much zooming in on the project itself. For this project, I was able to zoom out a bit to focus on the more significant problem of how we work together in the company. I think it’s essential to develop that thinking at times on how I work.