Guided Products vs Discovery Products

When developing content for end users, it is important to ensure that the content is targeted to the style of audience it is intended.

In the Agile Application development world, we would use a User Experience (UX) method to define how to build the application screens. In this world, we have complete control over how the screens are laid out, the placement and style of interaction widgets, the styles and colours of all objects.

One of the challenges in the world of BI is that we are often using commercial off the shelf (COTS) software to deploy our content, an enterprise reporting tools such as Business Objects, dashboard-centric tools such as Dundas or a business analytics tool such as Qlik or Tablaue.

While these tools often offer flexibility in defining the layouts, widgets and styles you are still constrained in each of these areas.  It’s the trade-off between the effort required to build your own vs. the flexibility in having prebuilt capabilities.

In the past, we would often use a user pyramid to describe the different audiences and the tool that was best suited to deliver the content that meets their need.

[[user pyramid]]

This was based on the idea that we would always have different tools for each of the content types, reports, dashboards, analysis applications.  Whether these were products from separate vendors that used the same data from an integrated data store or different modules from the same vendor that used an integrated metadata layer.

There has been a shift in the market from these BI vendors to add functionality across the reporting spectrum (reports, dashboard and interactive analysis) which means we are more likely to use only one BI tool for delivery of content.

The benefit is an increase in agility as we spend less time integrating multiple tools, learning ways of delivering content using different tools, or arguing which tools is the right tool for the content we are delivering and the audience we are delivering to.

The risk of this approach is that we may lose the focus on delivering content that matches the audience.  Examples of this would be delivering an analysis application with a large number of selection widgets to a senior executive.

[[discovery app screenshot]]

These Discovery Products are targeted at analyst users who want to be able to interactively work with lots of data to explore it to find insight or answer questions that haven’t been asked before.

A senior executive will often find these applications overwhelming, and they will not have the time to explore their data.  They require an application that answers a small number of business questions quickly.  We refer to these as Guided Products.

They contain a small number of filter widgets to enable limited interactivity, but, as a result, are perceived as easier to use.

[[guided app]]

These Guided Products require more effort to develop than Discovery Products.  The reason is we have to gather both requirements for the business process that the data needs to support and the business questions that need to be answered.  Often the business question requires the application of business rules to create derived data as well as the definition and creation of measures. As compared to the Discovery Products that just require the identification of the business processes and data and transformation into the raw data layer.

Then we need to spend time going through the content prototyping process to ensure we are answering those question in the simplest way possible, as compared to providing the data in interactive graphs or tables and allowing the analyst to explore it using the BI tools native capabilities.

So when defining the content to be delivered during the planning session, we quickly determine if the content is a Discovery Product or a Guided Product and adjust our [[BOM]] estimates accordingly.

Order of priority
When we get a choice in defining a priority between delivering a Guided Products vs Discovery Products we will typically develop the Discovery Products first.  This is for a couple of reasons.

We can typically deliver the Discovery Products faster as there is fewer requirements required and fewer business rules required.  And AgileBI is all about delivering value to the customer quickly and continuously.

Once an analyst has used the Discovery Product to explore the data we find it much easier to engage with the business users to refine the business questions they would like answered.  This ability to start by looking at something first rather than working with a blank piece of paper seems to accelerate the process.

(One should be careful though when using this data-driven approach to defining business requirements, as it may lead to the business user just picking easy questions to answer from a “shopping list” rather than thinking about what business questions should be answered to improve the health of the business)

It is typically quick and easy to cut the Discovery Product down into a Guided Product version by removing some of the superfluous filters and widgets and simplifying the visualisation widgets, for example moving from a using a heat map that shows multiple dimensions of the data to a bar chart that display only two.  Again this allows us to deliver the value to the customer quickly and continuously.