The benefits of data monetization that result from embedding analytics into applications are well known. Solutions with analytics built in let end-users efficiently and effectively use the valuable data sitting idly in systems for critical business decision making. However, few data product owners have mastered unlocking the data analytics treasure trove to create new revenue streams and increase user engagement.

Many data product development journeys are riddled with ‘bear traps’ that cause trepidation, or inhibit or halt project efforts. A trap’s existence should not render the journey hopeless. While it’s possible to get caught in a trap, the resulting frustration development teams face is preventable. Simply knowing how to sidestep pitfalls can help them evade the snares that render a solution unwieldy or cause them to abandon ongoing development.

Avoiding common traps ensures teams can produce a robust, scalable data product. They can build a solution with the complete range of analytics functionality that users need, and create value from previously unavailable data.  

Awareness of these bear traps is invaluable as data product teams navigate through the growing range of viable BI platforms, developer tool kits, charting libraries, ETL tools, and data preparation platforms that are available to data product teams evaluating the right mix of solutions to use  when delivering their data product.

Ignoring Product Lifecycle Needs and Producing Impossible-to-Maintain Products
This first trap goes unseen until it’s too late. Only after the product launches does the team realize they based the solution on a hard-to-maintain business intelligence (BI) platform.

Beyond the obvious maintenance activities (data extraction and cleansing, or data visualization), development teams must remember that a great data product performs core activities essential to keeping it operational over the entire product lifecycle.

Typically, analytics tools developed for internal use are not designed for use as commercial data solutions. Enterprise BI vendors may not anticipate widespread external use of a data product – including support of custom reporting, dashboards and self-service BI for tens of thousands of users. Their platforms may miss data product owners’ basic needs: adding functionality or administering tenant and user permissions so users see the right analytics for their roles. Data product ready solutions offer support of the full product lifecycle and recognize that functionality and requirements vary significantly between different stakeholders.

It’s easy to avoid this trap by selecting an analytics vendor that offers a robust platform with an integrated product lifecycle management ecosystem, and demonstrates an ability to operate at scale. BI vendors that have considered the details of supporting data product management will have concrete examples to answer these questions:

  • How many clients and users does your largest customer support?
  • How does your largest customer manage support and scalability?
  • How long does it take to onboard a new client?
  • How does your solution publish report and dashboard updates across single and multi-tenant instances?

Lack of Future Proofing
This bear trap is sprung when a lack of future proofing appears late in the development cycle. Showy and elaborate functionality and features that demo well may please the team, but over time prove ill-suited and create development challenges.

Future proofing starts by considering issues of scale — can the solution store millions of rows of data, or support tens of thousands of users in a multi-tenant environment? Most modern BI platforms easily handle scaling. However, many have functional limitations that complicate the data product’s ability to meet demands that come with customer growth.

To avoid investing resources in a dead-end platform, consider future needs when selecting a platform today:

  • How will it meet different customers’ compliance requirements?
  • Will using iframes result in lost customers due to a lack of responsive design?
  • Is there an open front-end that allows for customization?
  • Does the analytics software complement the application’s architecture?

Look for an open and extensible solution to avoid rigid platforms with bolt-on embedded capabilities.

Developing with Blinders On
Companies that have deployed a solution may think they’ve avoided all the traps. But one catches product teams as they prepare for the next iteration of the data product. Today’s BI platforms allow for building powerful, data-rich charts and graphs that help bring data analysis to life. However, they lack utilization analytics – reporting on product usage and the functionality used.  

Data products provide insights that help users perform their roles efficiently and effectively. Data product teams need the same benefit of analytics, which is necessary for future development efforts.

Avoiding this trap requires asking a few simple questions:

  • Are utilization analytics available?
  • What are the most and least frequently used dashboards, reports, etc.?
  • How can this information be used to find opportunities to improve adoption rates?

Taking time to identify the traps and steps to avoid snares will empower data product teams to walk the development path with confidence, leading to successful data monetization.