How to Successfully Pivot a Product, in 3 Steps

How to Successfully Pivot a Product, in 3 Steps
By

Fundamental to Enigma’s mission is the ability to provide contextual public information to augment the private data housed within enterprises. As we were building out Concourse, Enigma’s flagship product that acquires all of our public data, we were using the same processes to merge this public data with our customers’ private data for further discovery in Assembly. While Concourse was tuned to ingest a wide variety of small to medium sized data formats found in the public wild, enterprise data is often well-structured, consistently-formatted, and gargantuan in size.

To get us closer to our utopian goal, we needed to adapt Concourse to not only retain the agility to acquire multiple public data sources, but also to allow our enterprise users to efficiently process large SQL or Hadoop-based data in the same pipeline. The results of those efforts meant that we continue to acquire more public data to augment our view of the world, but we’re now also faster, scalable to large datasets, and allow our customers to share that same view with their own data. We took some bumps along the way - our first field tests of the pivot taught us a lot about how the different use cases had opposing needs in some applications (e.g. speed of development vs maintainability over cumulative data growth). This post highlights some of our lessons learned.

1. Always Consider the User

Product pivots like this often happen when something changes with the user base—either we want to target a new set of users, or our existing users are changing attitudes towards the product (or with the ecosystem in general). In our case, it would have been very easy to go down the technical route of juicing the performance of our existing products to handle the depth of private enterprise data, which would have ultimately hit a hard performance cap.

For Concourse, we essentially had two user personas to consider:

  • Data Engineering at an enterprise organization that need to consolidate multiple data sources in a single location.
  • Data Engineering for acquiring a growing number of public data sources, each existing as separate and distinct sources of truth.

We initially had completely separate product roadmaps to solve the needs of both of these users. However, to get us closer to the goal of unifying data, we found a way to make Concourse accelerate our ability to curate public data sources as the primary user, while also enabling our envoy engineers to use the best tools to operate in our clients’ specific environments. By narrowing the scope of the available product features to those that benefit your hierarchy of users, it forms a foundation for estimating ROI and determining test metrics for your pivot, which are described below.

2. Determine ROI

One of the core pillars of product management, especially in startups, is evaluating the return on investment for every feature that’s tied to a user. This is a core, if not *the* core function of a product manager. When considering user features, it’s always important to evaluate whether doing so will create value for the user while capturing some for yourself. Hitting this sweet spot forms the foundation for sustainable growth of the product as a whole.

In product, determining ROI is mostly an estimate or projection of the expected user growth, but the key idea here is to identify a specific measurable outcome tied to your target user. While different products in different domains can take different specific measures (e.g., unique visitors per month for AdTech, or conversion rate for eCommerce), generally they are just different ways to represent the multiplication factor of your target user personas. With Concourse, we projected the expected multiple of our 2 user personas to establish the viability of the pivot.

3. Execution <> Testing

When determining ROI, there is often a saying I leave with newer PMs—‘If you have enough data to tell you with absolute certainty that ROI will be positive, you’re already too late’. ROI should always be a statistically likely estimate that balances benefit and mitigates risk, but it is still based on a raft of assumptions. Every user feature created should be placed immediately in the hands of users to validate those assumptions, and more importantly, to start realizing the ROI to turn the estimates into reality.

Specifically for Concourse, we had just begun to test the market with our initial offering and the pivot to accommodate enterprise data was inspired after rank ordering the most critical user feedback in terms of our ROI measure. Once we embraced the feedback, we started to see greater interest from enterprise user customers, achieving a 3x multiple on our projected growth. We’re excited to see where our customers take us next!

____________________________________________________________________

Interested in solving complex, unique problems? We're hiring.