Sunday, January 17, 2016

Data Driven Products

In my previous post (Data Needs & Making it Useful), I talked about 4 levels of data needs and how each level serves a particular purpose.  Here, I want to dive deeper into the second level, Products.

(Important Note) When talking about each of these data needs "levels", I want to make it clear that in order to be successful you need from the first level (data pulls) and continuously deliver each level after it (Products, Alerts, & Predictive).  Any gaps within these levels, can cause your clients to have an unintended experience.  For example, if you start by building out a bunch of products but you don't give the flexibility to have data pulls, you will be stuck building hundreds of products to match to every request and every new metric.  Rather if you start with data pulls, you respond quicker by adding the new metric and ensuring this is good quality and was built for what it was intended for before you build a product around it.

Now, lets dive into Products.

First, I define products as any tool, report, or presentation of data to solve a specific use case.  This could include building a weekly sales report, this could be an A/B test tool, this could be an executive dashboard.  Whatever the product may be, these products are being built for a specific reason and ultimately making life easier than if data pulls were just delivered.

In my experience, I have seen too many times that products are built as the first deliverable.  Long hours are spent gather requirements, building out data structures, and building out these detailed products.  This is often done because of how organizations are structured (i.e. product/project teams), because the data teams are focused on delivering the "home run" of I will solve your problem with this amazing product, etc.  While the products are delivered, if the data pulls are not available, the clients still turn out unsatisfied over time.  Requirements evolve and data needs change which often causes product teams to go back and work off of a long list of enhancements.  This then causes either the original product to over engineered to a point where it can become unusable or additional products are built which causes the client to now to go two or more products to answer their current question.

Below is a typical timeline of how the product cycle happens without a data pull environment.

  1. Product teams are built
  2. Requirements are built for a new product from the client requests
  3. Data is gathered and a product is built
  4. Product is delivered (the client is happy!)
  5. The client asks for enhancements (new question, new data needs, or discovery question)
  6. Product teams work off a long enhancement list
  7. New products are built or the existing product is over engineered causing the client to spend more time to solve their question

Now how would this product level look if a proper data pull environment was available?

  1. Teams analyze current usage of data from the data pull and suggest a product to optimize the process to answer the question
  2. Product teams are built
  3. Requirements from both the client AND current data usage make up a new product
  4. Data is gathered (utilizing existing data pulls) and a product is built
  5. Product is delivered (the client is happy!)
  6. The client asks for enhancements (new question, new data needs, or discovery question)
  7. New data is built and made available through the data pull level first
  8. Depending on if usage is consistent from new data or question, then a product is built or enhanced

Bottom line, with the previous data need level (data pulls), this allows your team to make data driven decisions on where to focus.  Spending time to build out data and make it available for a data pull is a better use of time than building out product teams and making a product that may not get used.  Instead build the new metric or data set out and allow your clients to pull the data manually.  Have them prove out the use first before building an elaborate product to "optimize time".  Then your data team can focus on the right problem, the right product, and deliver the right value.

No comments:

Post a Comment