Beyond the Technical_Interactive

©2015 Birst, Inc BEYOND THE TECHNICAL The complete guide to designing, pricing, & launching embedded analytic products

BEYOND THE TECHNICALThe complete guide to designing, pricing, & launching embedded analytic products

2©2015 Birst, Inc BEYOND THE TECHNICAL The complete guide to designing, pricing, & launching embedded analytic products

WELCOME

CHAPTER 1 - Basics

CHAPTER 2 - ProcessMethodology

Interviews

Setting the course

Workshop

Elevator pitch

Personas

Linking personas, missions, workflows

Create the offering

Product tiers

Pricing

Lifecycle support

Operational readiness

The launch plan

A tale of two analytic products

CHAPTER 3 - Where next?

CHAPTER 4 - Conclusion

ABOUT BIRST

END NOTES

Contents3

6

1111

13

14

15

18

20

23

30

34

41

46

52

53

55

60

61

62

67

3©2015 Birst Inc. BEYOND THE TECHNICAL The complete guide to designing, pricing, & launching embedded analytic products

Welcome

Hey! We’re glad you’re reading our Guide on how to create great analytic products.

Since you’re here, we assume that you plan to use data generated from your product – your “core application” – to deliver new insights to customers and users. This is a great idea. Too often software companies treat data like “exhaust,” a by-product of their primary business; they fail to take advantage of data to drive engagement with customers and new markets.

But that’s why you’re here. And you might feel a little overwhelmed right now. You may have researched business intelligence platforms and realized, “Wow, there’s a lot out there!”

Creating an analytic product is a daunting task – or so it can seem at the very beginning. After all, for even the most seasoned product people, this is the first time they’ve built an analytic product. Unlike CIOs who may have implemented business intelligence multiple times over the course of their careers, analytics are probably new to product experts, traditionally the masters of their applications’ features and functionality.

Building an analytic product also can feel very high risk to the first-timer. The last thing you want to do is jeopardize your core product by making mistakes that could’ve been avoided.

How to use this Guide

Don’t worry – we’ve got you covered. This entire Guide is based on the lessons Birst has learned in building analytic applications for our company and for our customers. It

incorporates the vast knowledge of our team, many of whom were product owners themselves, faced with the challenge of “How do I best create analytic insights for my customers”?


This Guide collects every one of those lessons (and, to be honest, missteps), all of which can add up to big headaches. We’ve created a methodology that can help ensure a successful analytic product implementation from Day One. Our methodology goes beyond technical nuts and bolts, covering critical issues including product design, pricing, launch, and beyond.

We will take you through basic concepts and terminology; how to get your team aligned around your analytic product strategy; how to understand users, their needs, and how to select analytics to solve their problems; how to structure your analytic product; how to price it; and, finally, how to build the support processes that will ensure a successful lifecycle after launch.

This Guide is intended to put you on the right path to building a profitable analytic product. Read through it once to understand the general flow of building an analytic product. Then, during the course of your project, use it as a reference guide. We’ve included lots of specific sections, templates and lists to speed the process and get you un-stuck, as needed.

For some companies, using the Guide will be enough to develop a successful data product. But others may need more help in working through the squishy parts of the process. If that’s you, Birst Consulting is happy to step in. Our experienced team of consultants can help you sort through the issues and possibilities, to accelerate the development and launch of your analytic product. Contact us at [email protected]. Thanks!

Our Guide lays out all the steps necessary to build a successful data product, Birst style.

mailto:info%40birst.com?subject=


A cautionary tale

Recently, folks at a large, well known technology company decided they needed to do something more with their data. They wanted to move away from static, tabular

reports that took 45 minutes to generate, and deliver real-time insights to users.

They wondered, “How should we go about doing this?”

They started by surveying the business intelligence vendor landscape, evaluating more than a dozen OEM providers to find the right fit. BI vendor selected, the technology company jumped into the hard work of building analytic capabilities into their core product.

About 90 days later, they were ready to launch. The team had done extensive work to extract and normalize data, integrate the analytics into the core application, and ensure that a single sign-on worked flawlessly. They were ready to go.

When they launched, the product seemed to be a huge hit. Even the technology company’s most demanding customers were excited about the new analytic capabilities, both what was offered today and the roadmap for the future. The team thought they’d found a major new revenue stream.

But they hadn’t. After the newness of the product wore off, customer engagement slowly started to decline until, a year after a flawless launch, the product team was faced with a big decision: Should we keep or cancel the product? New users hadn’t appeared, existing users hadn’t increased utilization, and new revenues were nowhere to be found.

Why did this happen? How does a great analytic product supplementation go wrong?

That’s what this Guide is about: how to avoid mistakes and build an analytic product that will attract new customers, get existing customers to buy more, and differentiate your company from the competition. It’s more than a how-to guide; it’s an explanation of Birst’s methodology for creating great analytic products. Integral to that, we present our way of thinking about users, their goals, and how analytics can make their lives better.

And remember, if you come across issues that are more complex than the scope of this Guide, give us a shout at [email protected]. At Birst, we love building analytic products and we love sharing our knowledge.

!

6©2015 Birst Inc.

1

BEYOND THE TECHNICAL The complete guide to designing, pricing, & launching embedded analytic products

Business Intelligence Basics

Types of BI

Before we get into product creation, let’s define a few key terms and concepts. This will make sure you and your team are on the same page when you talk about business intelligence, or BI for short.

You might be thinking, “Doesn’t everyone know what BI means at this point? Charts and other analytics accompany pretty much everything we do in today’s business world.” That is true, but the concept of business intelligence can mean very different things to different people, colored by past experiences and/or current business objectives.

Some people think BI means info graphics. Others imagine interactive charts with drill-down capabilities. Still others have predictive analytics in mind. These are crucial differences to consider and, while they are all aspects of business intelligence, you need to establish a common goal for the project.

Here are the primary types of business intelligence:1

Types of Analytics

Capa

bility

Prescriptive

Predictive

Diagnostic

Descriptive

Questions Answered

• Optimization• Randomized testing

• Predictive modeling/forecasting• Statistical modeling

• Data exploration• Intuitive visuals

• Alerts• Query/ drill-down• Ad hoc reports/ scorecards

• What’s the best that can happen?• What happens if we try this?

• What will happen next?• What is making this happen?

• Why did this happen?• What insights can I gain?

• What actions are needed?• What is the problem?• How many, often, where?

7©2015 Birst Inc.

1


Your embedded analytic product eventually may contain all of these elements, but make sure the team agrees on what is to be delivered initially.

Descriptive

Descriptive analytics, as the name suggests, describe the current state of the business organization. They show what is happening, current values, and trends over time.

Descriptive analytics are the simplest type of business intelligence. They paint a picture only of the current situation, without insight into root causes or actions you might take to improve. But they are the ideal place to start; descriptive analytics are the building block of almost all dashboards, helping you to understand the current state.

Once you’ve implemented descriptive analytics and have a comprehensive understanding of the current performance landscape, diagnostic analytics are the next level up on the BI hierarchy.

Diagnostic

Diagnostic analytics address the question, “Why is this happening?” You’ve seen the current state of performance with descriptive analytics, but now want to go to the next step and find out why things are as they are.

Diagnostic analytics tools let you drill down and across your data, explore patterns, and try to determine the root causes of the current situation.

Predictive

Predictive analytics are concerned with the future. These tools can include things like regression analysis, trend lines, or even sophisticated “what-if” analysis that shows what might happen when various factors are changed.

Predictive analytics are the logical next step after descriptive and diagnostic functionalities have been implemented. Predictive analytics answer the ultimate question: “If I pursue a different course of action, what is likely to occur?”

Prescriptive

Prescriptive analytics are the most sophisticated category of BI. They answer the question, “Given the current situation, what is the best possible course of action to pursue?” Prescriptive analytics not only show what is happening and why; they also recommend a course of action based on the effectiveness of things you’ve done in the past.

8©2015 Birst Inc.

1


Key terminology

Now that you know about the types of business intelligence, let’s review key terminology you will likely encounter when building your analytic product:

• Core product or application: Your product into which analytics will be embedded.

• Dataoranalyticproduct: The set of features and functionality you will embed within the core application to provide insights to users.

• Embedded: Analytics that are tightly integrated into your core product.

• On-premisebusinessintelligence: An analytic platform that is served from hardware located in a facility under your control or your customer’s control.

• Cloudbusinessintelligence: Analytics that customers access via the web, that are centrally deployed, managed, and maintained by the business intelligence provider, i.e., your software company.

• Fullstackbusinessintelligence: A business intelligence platform that performs all essential functions – from data extraction, to data transformation, to visualization – to deliver insights to your users.

• Pointsolution: A business intelligence application that delivers one component of analytics, such as visualization or data extraction.

• White-labeledsolution: An analytic platform that is completely integrated into your core product and displays no evidence of being provided by a third party. All of the third party’s logos, messaging and BI platform-specific text are suppressed.

• Black-labeledsolution: Analytic capabilities that are clearly provided by third party Black-label solutions typically show a logo or other messaging to make it clear that a third-party BI platform powers the analytics displayed.

9©2015 Birst Inc.

1


Elements of a great analytic product

With the basic terminology out of the way, let’s talk about what’s required to create a great, engaging analytic product.

Building a great data product with “legs” has three important requirements.

A data product that attracts new users and engages your existing users by providing key business insights

Great technology that won’t limit your opinions down the

road

Ability to embed the functionality into your

product preserving the use experience

The go-to-market process to help you avoid all of the traps that can kill a data

product

1 2 3

10©2015 Birst Inc.

1


No limits

First, your product’s analytic functionality shouldn’t be limited by the platform you choose. The last thing you want is to pick a platform that works well today, only to find out that you need to rip-and-replace it a year later as customer requirements evolve.

You need options. You need flexibility. You need to make sure the analytic platform you choose handles not just today’s requirements, but also the items that are on your roadmap.

Easy to maintain

A great analytic product also should be easy to maintain. You want to focus your engineering and development team on the core product, not the care and feeding of the BI platform.

Too often, product roadmaps get derailed as ever-increasing amounts of engineering time are required to support an analytic platform that’s not quite as easy to maintain as you first thought. When selecting your analytic platform, make sure that it can support your future needs without extensive technical intervention.

Great user experience

Today’s business users have high expectations when it comes to analytics. They expect drill-down, filtering and the ability to change charts on the fly. They expect these things to be easy to use, not just for engineers, but also for the average business user.

A great analytic product keeps these requirements in mind. It anticipates the user’s needs, arranges analytics in a logical order and makes options easy to understand. It also maintains the user experience presented by the core application the analytics are embedded into, and doesn’t jar the user with an abrupt transition from the main application.

11©2015 Birst Inc.

2


The Process

Methodology overview

With any journey, it’s always a good idea to start with a map to see the steps you’ll take and where you’ll eventually end up. For the journey to an amazing analytic application, we’ll follow the map atthe bottom of the page.

We’ll start off by talking about alignment, and how you can make sure everyone on your team is working toward the same goal. This is accomplished through a series of interviews with key stakeholders, to confirm they have the same vision of where they’d like to end up.

Next, we’ll discuss the product workshop, a critical on-site, in-person meeting conducted between the members of your senior leadership team. During the product workshop you’ll cover the elevator pitch, the product boundaries, and key user personas and their goals.

As an output of the product workshop, you’ll likely have more work to do in the creation of personas, their missions, workflows, and pain points. That’s the next step in our journey. Birst’s methodology will teach you how to choose personas and build out persona cards, to help you empathize with each user type and what it needs to achieve.

Product workshop (kick-off)

Develop personas/workflows

Technology implementation

Initial interviews

with leadership

Support Process Development

Marketing readiness sessions

Legal readinesssessions

Sales readiness sessions

Support readiness sessions

Create product

functionality tiers

Develop pricing strategy

Technology kick-off

Develop metrics &

reports

Develop launch

strategy

The Birst Methodology for creating analytics products helps you consider all of the critical elements prior to launch.

12©2015 Birst Inc.

2


With the personas behind us, we’ll then enumerate all the features and functionality we might be able to offer to our users. We will organize these options into a tier structure; each level offers enough functionality to get the job done, but not so completely that the customer has no reason to buy more advanced capabilities.

The next stop on our journey is pricing – the topic that always raises numerous questions and concerns. In this section of the Guide we discuss pricing strategies and the key elements you need to determine the best price points for your product’s tiers.

After pricing we move on to support processes, the essential foundation of a successful analytic product. We will discuss building a team to create necessary support processes, effective ways to build those processes, techniques to minimize any gaps and to plan for failures, and to make sure responsibilities are well understood.

Finally, the launch! In this section, we cover how to launch a hit product including the beta phase, organizing customers into tranches, and planning a reasonable schedule.

Align the team

Let’s get started by talking about team alignment, a key step in the product creation process. You don’t want to get halfway through your project and find out that the CEO wanted to build sophisticated machine learning, the CTO was looking for simple info graphics, and the product team thought they’d be creating raw data extracts.

We begin by conducting a series of interviews with key stakeholders.

13©2015 Birst Inc.

2


Interview stakeholdersA best practice we highly recommend is to interview three key groups at the outset of the project. These groups are: the CEO or product sponsor, key internal stakeholders, and, finally, key customers.

During these interviews, each 30 to 45 minutes long, the goal is twofold:

• First, to understand the interviewee’s vision, goals, and the items they consider to be essential for the analytic product’s success.

• Second, and perhaps even more importantly, you are trying to assess whether the three key groups agree with one another.

Here’s an example: Let’s say you talk to the product sponsor and she says the goal of the project is to roll out predictive analytics to all customers by the end of the year. You then talk to the head of development, who says he thinks the goal is to scatter a few charts throughout the existing application in the first quarter.

Whoa! You just encountered one of the biggest problems a project can face: misunderstandings between key constituencies.

This isn’t insurmountable, but it requires an intervention. Here’s what we recommend: Start off the product workshop by having each participant spend two to three minutes describing his or her ideal end-state for the product. This gets the group talking and moves people toward agreement on overall project goals.

Here are the three stakeholder groups to be interviewed and the questions you might ask.

CEO/ ProductSponsor

What is your vision? What are your goals? What’s the timeline? Why are you doing this?

Key internal Stakeholders

Key customers

1

What are your goals? What’s the timeline? Why are you doing this?

How do you work today? What are your pain points? What would help you? Would you use this?

2

3

Agree?

14©2015 Birst Inc.

2


Setting the courseIt’s an important question to consider, and one that may seem so simple it gets overlooked: “What are we trying to accomplish with our business intelligence implementation?” Here are some follow-on questions:

• “Are we trying to differentiate ourselves from the competition?

• “Are we trying to create such compelling insights for our customers that the competition can’t possibly catch up?

• “Or, does our competition already have analytics and by comparison, we look weaker already?”

As a team, you need to consider two distinctly different product directions – differentiating from the competition versus upgrading an existing product to neutral. The direction you choose has substantial consequences.

For example, if you pursue a neutralization strategy to achieve BI parity with a competitor, but spend resources like a company that’s trying to differentiate itself, you may end up spending far more time and budget than is necessary.

Two product strategies that you may choose to pursue (adapted from Escape Velocity, Geoffrey Moore, 2011.)

Differentiate(we’re the leaders!)

Neutralize(we’ve got BI too!)

Separation

Comparability

Unmatchable

Good enough

How far?

How fast?

15©2015 Birst Inc.

2


In this situation, you should be spending just enough to achieve a comparable level of functionality, not to put distance between your company and the competition.

For example, if you pursue a neutralization strategy to achieve BI parity with a competitor, but spend resources like a company that’s trying to differentiate itself, you may end up spending far more time and budget than is necessary.

The product workshopAlthough great products can be created remotely with teams working via conference calls, we’ve found the best way to kick off a successful embedded analytic product is through a face-to-face product workshop.

The goal of the product workshop is simple: to get the project’s key leadership aligned and in agreement as to what will be built – before the first line of implementation code is written.

The workshop is generally a full day (six- to eight-hour) session. It’s essential that everybody you consider a key stakeholder attends. Plan on rolling up your sleeves and working; this isn’t a presentation or a “sit back and listen” session. It’s a working meeting, to lay the foundation for a successful analytic product.

Differentiate

Neutralize

As good as the competition

In this mode If you choose Instead of You get

Best-in-class

Unmatchable functionality

Good enough

Squandered resources as competitors

quickly catch up

Wastedbudget

VS

VS

Two product strategies that you may choose to pursue (adapted from Escape Velocity, Geoffrey Moore, 2011.)

16©2015 Birst Inc.

2


Workshop participants

OK, let’s get down to business. Exactly who should attend the product workshop? Participation is select and focused - attendees should be decision-makers who can speak definitively on key topics including the analytic product’s target audience, pricing, go-to-market strategy, and lifecycle support.

Ideally, the participants should include the:

CTO or Chief Product Officer

Head of engineering or development

Head of the user experience team for your core product

Head of marketing

Head of sales

Head of operations or customer support

Finance representative

Legal representative.

The product workshop is where your strategy, product structure, and pricing model are crafted

17©2015 Birst Inc.

2


Just as important is who should not attend this session. Everyone at this meeting should be in a position of authority and responsibility. That disqualifies people such as:

• Those who are not decision-makers

• People brand-new to the organization who don’t understand the goals or the context of the project

• People without a track record for successful implementation.

Workshop agenda

So exactly what are you going to do in your all-day, senior leadership workshop? You’re going to design the product strategy and make sure you’ve got the highest probability of success.

Here’s why: many times, teams jump right into analytic product projects – they’ve chosen a platform, reports to replicate, and have an idea for the user interface before they’ve really done the necessary planning. This is a mistake. It results in an application designed for you, the internal team, not for your users and their pain points. Take the time to think through the strategy at the beginning and your odds of creating an engaging analytic product will skyrocket.

A summary of the key stakeholders who need to participate in your product workshop.

Product Workshop attendees

Head of Marketing

Head of Sales

Head of Operations

CFO or senior Finance representative

Head of Development/Engineering

Head of Customer Support

Project manager or project lead

Senior Legal respresentative

User experience representative

Product Owner or Champion

Chief Technology Officer

Chief Product Officer

CEO

18©2015 Birst Inc.

2


Below is a sample agenda for the product workshop. You may change the topics, or just the times, but this is a good basic framework.

It’s almost impossible to get all of these items done in a single session, so plan on follow-up meetings to review anything you weren’t able to accomplish in the workshop.

The elevator pitchImagine this scenario: You’ve done all the hard work, you think you’ve done everything exactly right, and you’re ready to launch your new analytic product. At your prelaunch meeting, you talk the team through what’s been built and what you are just about to launch.

But wait, there’s a problem. The CEO thought you were building predictive analytics for senior marketing leadership at customer companies, but the head of sales was prepared to sell diagnostic analytics that would show users why problems occurred. Meanwhile, the marketing team worked up collateral describing the wonders of your new machine learning analytics system.

Yes, you’ve got a problem.

The best way to prevent these kinds of disconnects from happening is to ensure that everybody envisions the same end-state. That is, everyone has the same mental picture of what a successful project looks like. At Birst, we like to do this with an “elevator pitch” exercise designed to align all members of the leadership team on the product vision.

Here’s how it works: Imagine yourself at a venture capital firm asking for money to build your new analytic product. You’re seated at a large conference table facing potential investors who ask, “What

A sample agenda for your product workshop.

Topic Duration

Introduction to the project 15 min

Build elevator pitch 30 min

Brainstorm personas 1 hr

Develop persona cards 1 hr

Determine workflows/analytics for persona missions 2 hrs

Begin discussing tiers and pricing model 2 hrs

19©2015 Birst Inc.

2


is your elevator pitch? Describe the product you’re trying to build – the product you want us to give you money for – in one or two simple sentences.”

Could you answer this question?

Know your users

A big mistake frequently made by people creating their first analytic product is to simply replicate existing reports inside the new BI platform. This is a mistake because it doesn’t adding any new value or any new insights to the new product. It simply replicates what customers are used to seeing.

Another common mistake is taking the “shotgun approach” to analytics creation. This involves thinking of every conceivable analytic and blasting them across one or more pages, forcing the user to find their path to eventual performance insights.

Neither is a great method and both are highly prone to failure. When you see an analytic product without high user engagement, chance are that it was developed in one of these two ways.

The good news is that there’s a better approach. It yields a highly engaging, highly valuable product by linking every element on the page to user needs. Nothing is on the page without addressing a user need, and no user needs are left without an analytic on the page. This approach works well, but requires a deep understanding of users, their goals and their pain points.

The first step is to select the key personas you’re trying to serve.

A great 30-60 second elevator pitch is crucial to the success of your analytic product.

20©2015 Birst Inc.

2


Select personasA persona is a representation of a group or class of users. For example, a “Chief Marketing Officer” persona would represent the goals and struggles of the typical CMO using your product. A persona isn’t any one specific user, but rather a representation of the broad needs across that user type.

Here, a best practice is to have your team brainstorm a list of all potential user personas. They will probably come up with 10 to 20 candidates. This is far too many personas for Phase 1 of your project. You need to narrow this list down to two or three personas that can be addressed with the initial launch.

To narrow down your list, divide the personas into three categories:

Here’s what each of these categories means:

Executiveendusers are the senior executives and managers at customer companies who will use your dashboards and analytics. Generally, they’re concerned with trends, patterns and gaining insights into overall performance. These people may also be referred to as “strategic analytics users.”

Tacticalendusers are more concerned with daily workflows – that is, achieving the day-to-day work of the business. Examples include sales representatives, operations personnel or order entry team members. Instead of overall patterns, these people need to see the total amount of work to be done, how much has been done already, and how much remains.

Internalusers are personas for people within your own company (the company offering the analytic product to customers). Examples include your operations, billing, marketing, sales and product management. Here, the personas are interested in the product’s utilization, patterns of usage and issues that may impact the customer user experience.

Tactical end users

Executive or managerial end

users

Internal users

21©2015 Birst Inc.

2


A word of caution: Although you may be tempted to address more than three initial personas, don’t do it! In the next steps of this process you will define the mission, workflows, pain points and analytics required to serve the personas. Trying to do this for more than three personas quickly becomes overwhelming. You can create analytics for other personas in later stages of the project, but again, limit yourself to two or three for Phase 1.

Create persona cards

Use a mind map to divide your users into three groups when determining which needs to address first.

Potential Data Product

Users

CMO

CTO

CPO

Head of Sales

Head of Operations

Executive End Users

Internal Users

Tactical End Users Installation

team

Sale Reps

Marketing team

Customer Service

reps

Your CPOYour Head

of Operations

Your Head of Sales

Your Finance/

Billing team

Your Marketing

team

Persona cards keep a wealth of customer insights in a simple, at-a-glance format.

“I feel like I’m operating blind. I don’t know what campaigns are doing well and which are doing poorly until it’s way too late to take action and correct any problems”

Salesforce.comMarketoExcel spreadsheetsFunnel toolNetSuite

360 view of customers360 view of campaignsSee gaps and coverageSee geographic overview of campaign reach

Can’t see performance by region, team, or campaignCan’t perform “what if” analysisGuesses at best course of actionCan’t see if campaigns touch customers multiple times or if gaps exist

Key Wishes or NeedsTools Used TodayFrustrations or Pain Points

Needs to develop marketing campaigns that attract new customers and encourage existing customers to try new products and featuresMission

Key CharacteristicsThe focus of all demand gen programsA trusted advisor to the executive and sales teamsPulled in many different directions

VP of Marketing Role or Title

22©2015 Birst Inc.

2


1. Identify the key characteristics of the persona. What makes this user unique? Are there particular attributes that differentiate this user from others?

2. Identify the primary mission for the persona – what is the user is trying to achieve? What is the objective for the persona’s role? If you had to sum up this persona’s role in one or two sentences, what would they be?

3. List the persona’s frustrations or pain points. What keeps them up at night? What causes them stress when trying to complete their mission? Be specific, since the pain points will directly link to the analytics you’ll be creating.

4. What tools does the persona use today to accomplish the mission? You may want to expand this section and list how each tool is used, and detail how it might fall short in accomplishing the mission.

5. Finally, list the persona’s major wishes or needs. If this persona could have anything to help accomplish their mission, what would it be? Keep the wish list realistic – these are things you should be able to actually develop within your analytic product.

6. Repeat this process for each persona you’ve identified. Try to strike a balance between detail and the time spent on each persona card; this shouldn’t be a multi-day exercise. The cards function as guides to determine which analytics are required on each dashboard. They should contain enough information to do exactly this.

1

2

3

4

5

6

Once you’ve selected two or three key personas to pursue, the next task is to create a persona card for each.

You may be familiar with the personas used for marketing purposes, but these are different. These are “user experience” personas – that is, personas focused on the goals, objectives, and frustrations a user in a particular role might experience.

Don’t spend a huge amount of time on each persona card; an hour should be plenty. Here’s how to build a persona card:

23©2015 Birst Inc.

2


Linking personas, missions and workflowsWith your persona cards created, you’re ready to start using their elements to determine which analytics to display. Here’s the basic process flow:

Start by creating a basic procedure or flowchart – five to seven steps at most – that describes how the user will accomplish the mission. In the example below, the persona is a Marketing executive. This person’s mission is to create high-performing marketing campaigns using these steps:

1. Identify target markets

2. Build a target list

3. Select collateral to serve to the customer

4. View what might result from the campaign

5. Finally, launch the campaign.

Once you have detailed the workflow steps, take the pain points from the persona card and link them to the steps of the workflow where they occur. Each step may have multiple pain points or none at all. This is fine – the key is to highlight where frustrations occur in relation to the workflow the user follows.

Select Persona Determine Mission Create Workflow for Mission

Mission: Create high performing marketing campaigns

Workflow: create campaign

Identify target markets Build target list Select collateral

to serve

View potential results from campaign

Launch campaign

A typical workflow for a Marketing executive persona.

1

2

3

4

5

24©2015 Birst Inc.

2


Next, step through each identified pain point and indicate an analytic that might solve the problem. For example, for the first pain point in the Marketing executive persona, is the user able to filter campaigns by various dimensions? The analytic solution might be a table view with drop-down filters that let the user select dimensions and instantly see the results.

Follow this process for each pain point in the workflow.

Workflow for a Marketing executive persona with pain points added.

Identify the analytics which will address each pain point and help the user accomplish their mission.


Workflow: review and adjust performance

Review status of campaigns

ID underperforming

campaigns

Determine regions or segments

underperforming

Adjust campaign target list or

collateral

Project revised results

Pain point:I can't see benchmarks for

performance

Pain point:I have to guess at the best

changes to make

Pain point:I can't easily filter

campaigns by dimensions

Pain point:I can't compare campaigns

to past performance

Pain point:I can't see performance vs

target

Pain point:I have to wait 24 hours to see my changes reflected

Pain point:I can't predict what may result from my changes

Possible analytics that you could display to address the pain points for this persona




ID underperforming

campaigns


underperforming


collateral


Pain point:I can't compare campaigns

to past performance

Pain point:I can't see performance vs

target

Pain point:I can't see benchmarks for

performance

Pain point:I can't predict what may result from my changes

Pain point:I have to wait 24 hours to see my changes reflected

Pain point:I can't easily filter

campaigns by dimensions

Pain point:I have to guess at the best

changes to make

Table with filters Clustered bar chart Bar/line chart Predictive analytics

25©2015 Birst Inc.

2


Once you’ve completed the first workflow, identify the pain points in the subsequent analytics. Continue the process by repeating this set of steps for each mission and each workflow in each group of the persona’s pain points. Then repeat this whole process for each persona. You can see why we recommended only two to three personas to start – it gets to be a lot of work quickly!

The analytic workflow

With the persona cards completed and missions defined, you’re ready to start linking users to analytics in your application. The most effective way to do this is with an analytic workflow.

The analytic workflow is a concept unique to Birst – it’s about selecting the right analytics to solve a user’s pain, and arranging them on the dashboard in a way that intuitively guides the user through the process of analysis. This lightens the user’s cognitive load because they’re not presented with so many options they don’t know which one to choose.

Using an analytic workflow helps establish your company as a trusted advisor, guiding customers through the problem-solving process. It’s an opportunity to reinforce your brand by proving that your company, not the competition, will help the user resolve critical pain points.

Most teams start off this process thinking, “This is easy! We just take the analytics and group them on the page logically, like by region or team.” This is a serious mistake because it forgoes a huge

Multiple workflows comprise the Marketing executive’s mission to create high performing marketing campaigns.


Workflow: create campaign



ID underperforming

campaigns


underperforming


collateral


Identify target markets Build target list Select collateral

to serve

View potential results from campaign

Launch campaign1

2

Workflow: identify new audiences

Review audience list coverage

ID underserved audience segments

Adjust list to increase coverage

Project revised results3

26©2015 Birst Inc.

2


opportunity to make your product more engaging, and to reinforce your brand and point of view.

Specifically, if you simply “shotgun blast” the analytics across your application, you’re doing your customers a disservice. There is a reason they bought your product and not your competitors’. They see value in the way you view the world and in the way your application presents information. They view you as a trusted advisor.

You need to reinforce all of these customer beliefs with your analytic application. It should reduce the user’s cognitive load by effortlessly answering their question, “What exactly am I supposed to do next?”

Additionally, the analytic workflow makes your job easier by presenting the answer to the question, “Exactly which analytics should we show our users and how should they be arranged?”

Creating an analytic workflow

Here’s how the analytic workflow is developed:

1. Start by picking a persona and a primary mission for it.

2. When you examine the mission, decide, “What is the persona trying to accomplish?” The answer to that question is the theme for your dashboard. For example, a Marketing executive’s mission might be “Understand overall campaign performance for my organization,” for a dashboard theme of “Understand campaign performance.”

3. Next, develop a workflow or set of steps the persona might follow to accomplish the mission. For example, given the mission “Understand campaign performance,” a Marketing executive persona might follow these steps:

The steps to developing the analytic workflow.

Done in previous steps

Determine mission

Select persona

Create workflow for

missionSelect

workflowSelect step in

workflowIdentify

analytics that assist in step

1

2

3

Identifycampaigns that have completed

Gather campaigndata including performance

and budgetary information

Determine campaigns that underperformed for the budget

spent

Repeat steps 3 & 4 for high-

performing campaigns

Try to identify commonalities

27©2015 Birst Inc.

2


Understanding the process the Marketing executive follows will tell you exactly how to select your analytics and organize your dashboard. Here’s how:

For the above example you may decide to build a dashboard, “Understand campaign performance,” which is directly tied to a major theme for the CMO persona. Then, you will use the steps the Marketing executive follows to determine how you can provide insights that were previously obtainable through manual processes, otherwise difficult to obtain, or even impossible without a BI platform.

Then, as illustrated below, use a template-like flow to relate the persona, mission, workflow, and associated analytics.

The analytic workflow is deeply useful because these charts are not scattered across multiple pages, tabs and dashboards – they’re all right next to each other in a logical, structured flow. The customer doesn’t see a chart and wonder, “What should I do next?” They are guided through the thought process – your point of view on analyzing this data – by the structure of the dashboards and the placement of the analytics.

Following this process helps the customer make the most of your analytic product.

Detailed breakdown of an analytic workflow.

Persona:

Mission:

VP of Marketing

Understand campaign performance

Identify campaigns that have completed

Gather campaign data including performance and budgetary information

Determine campaigns that underperformed for the budget spent

Infographic showing total campaigns in-flightInfographic showing total campaigns completedFilter to select timeframes, regions, campaign types

Table showing campaign title, budget, and performance dataFilter to select timeframes, regions, campaign types

Ordered/ranked bar chart showing top performers by leads producedLine on bar chart showing average performanceOrdered/ranked bar chart showing top performers by leads per dollar spent on the campaign

Step Workflow Step Possible Analytics

1

2

3

28©2015 Birst Inc.

2


Refining the workflow

Once you’ve selected the analytic elements - the charts and graphs to display to the user - the next step is to refine the workflow and determine the order in which to present these items.

Here, we recommend using a technique called the “card sort” to both lay out the analytics and test the workflow with users. The card sort process will test how well your ideas on presenting the analytics actually work when shown to a user.

Here’s how a card sort works:

1. Start by writing the title of each analytic, including KPIs, tables, charts, etc., on a 3” x 5” index card.

2. Next, group the index cards into a stack for each persona. Stack all of the CMO cards together, all of the CEO cards together, etc. If a persona has multiple missions, create a stack for each mission. You may need to create duplicate cards if an analytic is used by multiple personas. If this is the case, use colored index cards – i.e., all of the “sales funnel bar chart” cards are red, all of the “marketing campaign performance” cards are yellow, etc.

3. Pick a stack of grouped cards and lay them out in the order you want the user to see them. This should be directly based on the analytic workflow you developed to help the user accomplish their mission. It’s easy to get sidetracked and start grouping analytics according to other criteria, such as chart type or data type – don’t do it! Stick to the workflow.

1

2

3

Write the title of each chart on a 3”x5” index card

Group the indexcards into stacksby persona

For each stack, layout the cards in the order you wantthe user to view them

Take a photo of thearrangement

Test the order with users - let them re-arrange the cards

Repeat for each persona & mission

29©2015 Birst Inc.

2


1. Take a photo of your initial layout so that you can “reset” it if necessary.

2. Now it’s time to test the workflow. Show the card layout to as many users who are familiar with the persona’s mission as possible. Ideally, test the paper flow with actual users. Let them comment on the flow and re-arrange the cards as they see fit, but keep two things in mind:

3. See if you can get to consensus, a flow that your testers is logical and still conveys your vision of how customers should examine the data.

As you go through this exercise, remember the goal: to create a workflow that reflects your company’s expertise in working with the underlying data while helping the persona achieve their mission.

KPI showing CampaignConversion Rate

Bar chart showing performance over time with trend line

KPI showing Total CampaignBudget

KPI showing BudgetRemaining

Table showing top deals

Old-fashioned index cards provide an indispensable tool for testing analytic workflows.

1

2

3

• Don’t explain the workflow/layout to the users - see if it intuitively makes sense to them.

• Capture their reasons for moving cards. No moving without a rationale! These reasons often point to flaws or oversights in the workflow you initially created.

30©2015 Birst Inc.

2


The next step is to define exactly how you’re going to offer these analytics to your user.

What won’t you do?

First, you’ll need to establish broad guidelines for what your product will and won’t do. We like to start by working with the product team to determine three items:

1. What will you do as part of the core product?

2. What will you do for an extra fee?

3. What will you not do under any circumstances?

Create the offering

Let’s check in and see where we’re at. At this point, you’ve:

1

2

3

Aligned your team on the goal

Selected key user personas for the first phase of your

project

Built the persona cards detailing the needs and pain

points for each persona

Established the workflow and analytics required to resolve the

issues with each persona

Tested the workflows using the card sort technique

31©2015 Birst Inc.

2


By framing your product in this manner, you help to establish boundaries, guidelines to help the product team make decisions when they encounter a fork in the road. Here’s what we mean by each of these three categories:

• Partofthecoreproduct: Items that are part of your standard product offering. These generally available features and functions, which may be offered in a tiered structure, are available to all customers.

• Extrafeeitems: Out-of-the-ordinary items a customer might request and you are willing to build, but not as part of the standard product. Examples include connections to unique data sources, customized dashboards, unique one-off metrics, or other unusual configurations. You’ll create these capabilities, but will charge a professional services fee and perhaps even an additional monthly recurring fee.

• Thingswewon’tdounderanycircumstances: Product features or capabilities that are off-limits. Here’s an example: While building out their analytic product, a company was approached by a customer who asked, “We like where you’re going with this, can you enhance the application to also do invoicing and billing for us?” This seems like an easy question to answer: “No, of course we won’t do that. It’s not part of our application, our analytics, or really even our focus.” However, this situation was made more difficult by the customer’s offering a substantial fee for this functionality. It put the product team in a quandary; the client would pay a huge sum of money and, “well, we never really said we wouldn’t do invoicing did we?”

In product development, as in life, it’s essential to set boundaries.

Stuff We Won’t Do

Stuff We Won’t Do

TheProduct

Stuff We’ll Do as Part of the Core Product

Stuff We’ll Dofor an Extra Fee

32©2015 Birst Inc.

2


As you can see, it’s a slippery slope. But you can mitigate dilemmas like this by very clearly delineating, at the outset of the project, what your product will do for an additional fee, and what it will absolutely never do. This process helps to focus the team and will make decisions like the one above a little easier to make.

What could you include?

The next step is to list all the potential features you can offer to your customers. Think about this – how could you break up your product’s feature/functionality to make it compelling for customers who just want to get their feet wet, as well as an for those customers who want an advanced analytics package for power users?

We do this by building a simple “menu” of functionality and breaking it up into logical chunks. For example, you might have three levels of data to offer three different tiers of service – one year of data, three years of data or five years of data. In other cases, like predictive analytics, you might have just two levels: no predictive analytics included, or predictive analytics turned on.

The idea is to think through all the elements you may offer and the various “settings” for each of the pieces of functionality. This menu of functionality will be used in our next step: creating product tiers.

Category Details Typical Options

Benchmarking

Predictiveanalytics

Can users compare their performance to other teams, regions, or companies?

What will happen if we change things? Will we hit our goals? Are changes cost effective?

None; internal (compare teams, regions, product lines); external (compare yourself to the industry)

No predictive; trend lines for specific analytics; what-if type analysis

Amountofdata

How much data will you allow users to see?

12 months; 36 months; 60 months

33©2015 Birst Inc.

2


Category Details Typical Options

Custommetrics

Drilllevels

Data velocity

Custommodel

Datalayers

Can the user build new metrics in addition to what you’ve provided?

Can the user drill down? How far?

Will the data be refreshed daily or in real-time?

Can the user create entirely new data models (mash-ups of data from various sources)

Can the user bring in new data sources to augment their picture of performance? Will you provide these as options or will it be done on a case-by-case basis?

No - use only the pre-defined metrics; Yes - create, use, and save your own metrics

No drill down; drill down a few levels; drill all the way to the source data

Daily; hourly; real-time for select analytics

No - pre-built model only; Yes - user can modify the model

No layers; pre-built options; customizable by the user

Adhocanalytics

Can users create their own charts and other analytics or are they locked into the pre-defined dashboards you’ve established?

No - pre-built dashboards only; Yes - users are free to perform ad hoc analysis

34©2015 Birst Inc.

2


Creating product tiersOne of the biggest mistakes product teams make is creating a single analytic product level and within it, giving the users every feature imaginable. This is a problem for a couple of reasons.

• First, it overwhelms the basic user, showing them functionality they may well never use, and perhaps even causing confusion when they see all the options available.

• Second, it creates the perception in the user’s mind, “Since I’ve bought ‘the analytics package’ I assume I’ll be getting new features, upgrades, and other additional analytics functionality over time for the same price.”

A good way to get around these problems is to create analytic product tiers. Three is a good place to start: basic, plus, and pro.

We recommend that all customers start on the basic tier – it’s not an opt-in level of service, it’s opt-out. This gives all customers the chance to experience the analytics, see the value, and understand the insights they can expect. If the customer never gets the chance to see the analytics because they didn’t opt-in, it’s going to be very hard to convince them to buy a plus or pro package in the future.

In other words, the customer needs to see the analytics to understand exactly how valuable they will be.Thebigquestionis,“Whatdoweputineachofourtierstocompelcustomerstomovefromthebasictier,totheplusorprotierovertime?”

Included for all customersUses standard templateRead-only dashboardsNo benchmarking1 year historical data

•

•

•

•

•

•

•

•

•

•

•

•

•

Uses standard templateCutomization for an additional feeRead-only dashboardsInternal benchmarking included2 years historical data

Uses standard templateCutomization per customer needsUsers can modify dashboards (ad hoc analytics)Included external benchmarking3 years historical data

Basic Plus Pro

1

2

35©2015 Birst Inc.

2


Each product tier should offer distinct features and benefit.

The answer is to go back to the personas, their missions and pain points. You want to identify what each persona is trying to accomplish, give them enough in the basic tier to partially accomplish that mission, but then show how a higher-level tier would help them achieve further success.

For example, in the basic tier, you might show something like sales performance over time, but only for the user’s company as a whole. In the plus tier they could add the ability to compare the performance of various teams within their own company. At the pro level, benchmarking is enabled and they can now see how their performance compares to the industry as a whole.

Basic is valuable, plus gives even more information, and pro provides the whole picture.

While doing this, it’s important that you help the customer understand what’s available in the next tier level up, and the valuable insights they’re missing out on. This can be done by graying out certain functionality; you can see that features like benchmarking are available, but only at the next level. Once the user sees all the great functionality available in the next tier, it’s extremely hard to suppress the urge to move up the analytic stack!

Ok, I’m hooked but am I missing out on

other insights?

Basic

Customization, comparisons, and

more data but I want more...

Plus

I’m set - ad hoc analysis, more

data, and detailed benchmarking

Pro

36©2015 Birst Inc.

2


Ways to create value

Unfortunately, it’s not enough to understand personas, missions and pain points, and then create analytic workflows for your users. You need to provide even more value. Here are three great ways to make your analytics product engaging and highly useful: deep drill-down, comparisons and data layers.

Deepdrill-down: This technique allows users to start at a high level, big-picture view of business performance and then drill down deeply to the source data. If you’ve heard about “The Five Whys”3 in doing root cause analysis, this is closely related. Deep drill-down allows a manager to see overall performance, identify if it’s not going to right direction, and then drill down and understand why this might be happening.

For example, a sales executive might see that overall sales are trending down. She clicks on this chart, drills down and realizes it’s the West Coast region. From there, she drills down further and sees that a particular team is underperforming. Still further down, she realizes that although this team’s deal volume is high, it comprises low-value deals. Now she starts to gain a sense of what she might do to remedy the situation.

Comparisons: This technique allows users to benchmark their performance against peers, to see if they’re ahead or behind. Here, you’re adding value by placing performance in context. You’re showing your company’s performance versus the industry, team A versus team B, or product line 1 against product line 2. Insight is created by understanding whether you’re ahead of or behind the competition. This doesn’t have to be a peer-to-peer comparison; it can also be a target line, a line showing last year’s performance, or a “best practice benchmark.”

Datalayers: This analytic technique layers data sources on top of one another to generate new insights that haven’t been available in the past. It can be a little bit more complex to implement, but the payoff can be tremendous.

Creating data layers is similar to compositing a photograph in Adobe Photoshop: you start with a source photograph, and stack layers of images on top until the result is a completely different picture. With an analytic application, you’re doing this with data layers.

Here’s an example. You have information on traffic to your product line website. This is useful information but pretty basic. But let’s say you also have Salesforce.com data available. Take the sales opportunities in Salesforce and superimpose that information over the website traffic for each product line. Now you’ve got something interesting.

37©2015 Birst Inc.

2


That big opportunity that was supposed to close next week? You can see how traffic to the product webpage has dropped significantly. Is the opportunity really going to close? Interest seems to have tapered off quite a bit; maybe you should reduce the probability of the opportunity closing in Salesforce, and adjust the sales forecasts based on this new information.

Data layers are another way of letting users establish context. Each source of data is no longer isolated, but is now seen in relation to other data. Done correctly, this can be tremendously valuable.

Making your product sticky

In his fantastic book Hooked: How to Build Habit-Forming Products, author Nir Eyal describes a model to build engaging, sticky, addictive products. We like to use this same model when we’re creating analytic products. Here’s how it works:

The components of an engaging analytic product.

Asticky,engagingproduct

Trigger Action

Investment Reward

1 2

34

38©2015 Birst Inc.

2


A product that engages users and keeps them coming back has four components: a trigger, an action, a reward and finally an investment. You’ll need to consider each of these for your product if you want the best chance for success. In an analytic product, here’s what these elements entail:

Trigger:

This is the “call to action” or stimulus that tells the user they need to visit the analytic product you’ve created. If they’ve already purchased the product, a trigger might take the form of a notification or alert. If they don’t already use the product, the trigger might be noticing that the competition seems to know more or be able to act faster. It could also be the realization that their information is delayed or difficult to obtain that drives them to your product.

By building triggers into your analytic product, you help ensure that the first vital element to success – the user actually visiting your system – is present.

Triggers may be either internal or external in nature.

• Externaltriggers are things like alerts, notifications or other system message that tell the user, “Hey, you need to come look at me.” These triggers are easier to build, but may be ignored if they lack meaningful information or if the user benefit from responding is too low.

• Internaltriggers are messages that come from the users themselves. At best, internal triggers are the product of the user’s high level of engagement with your product; the user is simply curious about what’s going on. Other internal triggers include things like the “fear of missing out,” or that nagging feeling that your peers know more than you. Internal triggers are more powerful than external triggers, and typically occur after a user has learned to use your product effectively and has come to rely on the information it provides. Simply put, great information quality is the best way to organically generate internal triggers to your product.

1

2 Action

The action is what the user does when they visit your product, after being triggered, to generate the promised benefit. The critical element here is that the action must be “low friction,” that is, it must be easy to perform and not overload the user’s brain by forcing them to think too much about what to do or how to do it. To make your product more engaging, make your actions easy to understand and perform.

39©2015 Birst Inc.

2


3

4

Reward

This is the benefit the user gets from visiting your product and using the analytic functionality. Research shows that habits are formed when two components are present: frequent usage and high utility or value.

If a user visits your analytic product frequently but doesn’t get much value, they’ll stop visiting. If the value is high, but users aren’t visiting (the trigger is poor) habit won’t be formed, either. Make sure you provide real value to the user by aligning specific personas, missions and pain points to the analytics you present.

Investment

This is the most overlooked of the key elements of an engaging product. It’s where the trigger to use the product is re-loaded, and an “itch” is formed.

Investment means that the user adds something to the system that will generate the burning questions like, “Did anyone respond? Is there something waiting for me?”

Examples of investment are a user posting a comment to a Facebook thread, a manager attaching an action item to a Salesforce opportunity, or a business colleague sharing an article on LinkedIn. You can add investment to your analytic product in several ways:

• Allow comments on your dashboards

• Let the user create action items for analytics

• Perform root cause analysis for troubling trends and show the results on the analytics pages themselves.

Investment is the secret sauce that can turn a good product into a great one. By thinking of ways to engage the user by adding their own data to the analytic application, you can help to form their habit of using your application, gaining insight, adding their own thoughts, and then coming back later to see if their ideas sparked a new conversation.

40©2015 Birst Inc.

2


How do you ensure that your analytic product will become a daily habit? Here are a few pointers:

• Make sure your application uses alerts and notifications. Don’t rely on internal triggers to get a user to check their analytics each day. Use external triggers initially; the internal desire to know what’s happening in the product will develop over time.

• Make sure the actions the user takes inside the analytic product – the dashboards, the charts, everything – are easy to understand and use. Eliminate all ambiguity about the meaning of functionality and the interpretation of charts. Use context-sensitive help and plain-language definitions to make sure that the user is never confused about the meaning of the analytics. Frustration and confusion are the enemies of an engaging product.

• Optimize the rewards part of your application by linking personas, missions, the analytic workflow and the resulting analytics. A chart randomly placed on a page may be a valid reward that satisfies the user, but a chart tied directly to their needs definitely will.

• Think of anything you can do to move the user from passive consumer mode to active participant mode. Add investment. Finding innovative ways to get users to add their own information, such that they are driven to see the response, is a sure-fire way to increase stickiness in your analytic product.

41©2015 Birst Inc.

2


Pricing

It always comes down to this: “Can we make money with analytics? How do we charge for it?”

All too often, product teams simply punt. Doubts are raised when, typically, someone says, “Analytics are expected, they’re table stakes, we can charge for that.” This to be true, if you haven’t created additional value through the way you’ve structured your analytics. If you followed the three techniques discussed in the “Ways to create value” section, you should be delivering new insights for your customers – and you charge for added value.

If you are still struggling, we recommend you go back and revisit the ways to add value – the personas, missions, and analytic workflows – to make sure that you are. Often, product teams will unwittingly try to replicate existing reports when building new analytic capabilities; since this just presents a prettier version of what customers already have, they can’t find enough reason to charge for the new functionality.

If this is the case for you, revisit how you linked personas, missions, pain points and the analytics to see if you can find a way to create new insights.

Pricing scenarios

As you can see in the figure below, product teams generally face one of three scenarios when establishing pricing for their analytic product. The scenario you’re facing will determine how to price your analytic product.

Three pricing scenarios for analytic products.

Trying to catch the competition Question: Can we charge for closing

the gap?

Making the core engaging Question: Is the increased value of the

core product enough?

Competing on analytics Question:

Can we create enough value to charge a premium?

42©2015 Birst Inc.

2


Tryingtocatchthecompetition: Your competitor already has analytics and you need to play catch-up. In this situation you may not be able to charge a premium for your analytics. Ideally, you can raise the price of you product, now with analytics, to match the price of the competition. Worst case, you might not be a charge an additional fee.

If customers have been complaining about your lack of analytics and threatening to leave, you may need to offer analytics simply as a cost of doing business in a more competitive environment.

Makingthecoremoreengaging: In some cases, analytics may make your core application look better and be more engaging. But face it, analytics present beautifully, they demo well, and they get customers excited. In a scenario like this, you might introduce your updated product as “Version 2.0, now with analytics!” and charge a slightly higher fee. The added attractiveness of the core product, and subsequent increase in customer interest, may be enough to offset the cost of providing analytics.

Competingonanalytics: Here, analytics provide a significant competitive advantage over the competition. By linking personas to pain, structuring analytic workflows, creating new insights through data layers and allowing comparisons, you are adding real value to your application. You may decide this is a major new thrust for your product, and that you will compete on analytics.

In this situation, you’ll place a lot of emphasis on developing your analytic product and evolving it over time. You are adding so much value with the new analytics that you can charge a premium. You can charge more than competitors because, while they may have analytics, they haven’t thought through the structure of the analytic product to the degree you have. They used the “shotgun approach”; you followed an analytic workflow. They chose analytic elements because they were available; you linked every element on your dashboard to a specific persona and pain point. You added new value; they didn’t.

You can charge a premium for your analytics and use it as a major competitive advantage in this situation. Price accordingly.

The pricing model

As you determine the price you’ll charge for the analytics, you need to understand four key numbers:

1. The cost to build/maintain your product without analytics (cost of goods sold [COGS])2. The cost to provide the analytics3. The price you currently charge for your product4. The price your best competitor* charges for their product, which includes analytics.

* When we say best, we mean the most compelling alternative to your product. The alternative that, if your product didn’t exist, customers might choose.

43©2015 Birst Inc.

2


Once you have these four numbers, arrange a pricing spectrum similar to this:

The pricing spectrum helps you understand the range of viable pricing. Obviously, you should price above COGS, but the upper end of your range depends on the competitive scenario, as discussed above. If you are playing catch-up, you might want to price at or below the competition. If you’re competing on analytics – depending on the value you are able to add – you may be able to charge more than your best competitor.

1

2

3

4

The cost to build your product without analytics

The cost of the analytics (platform, services, etc.)

The current price you charge for your product (without analytics)

The price your best competitor with analytics charges their users

Four key numbers will influence the price of your product with analytics.

Plotting a pricing strategy is easier when you approach it visually.

Potential Pricing Zone CautionZone

DangerZone

CautionZone

DangerZone

Price your data product along this range

Cost of Goods Sold —

WITHOUT analytics

Cost of Goods Sold —

WITH analytics

Current Product Price

Price of Best Competitor

BasicTier

Price

PlusTier

Price

ProTier

Price

44©2015 Birst Inc.

2


Whichever scenario you face, the pricing spectrum is a good way to see the relationship between costs and the price you’ll ultimately charge for your analytic product.

Keys to making pricing work

Once you’ve determined price points, you need to make sure you present the new analytic product’s pricing in the best possible manner. Here are a few keys to pricing success:

Don’tmakeanalyticsanoption

Teams often make the mistake of setting their new analytic capabilities as an “opt-in” feature. But if you’ve set your price a little too high, or haven’t marketed the new analytics well, customers won’t opt-in. Then you’ve got a problem; they won’t see how you’ve solved problems for key personas, or understood their missions and created workflows, or how you’ve added value.

If customers don’t see the analytics, there’s very little chance they’ll ever subscribe to a plus or pro package, much less the basic analytic offering. Don’t make this a possibility. Give all customers analytics (for a fee) and let them experience what you’ve created.

Fitanalyticsintotheexistingpricingmodel

If your analytics are part of a core product, offer them that way. Here are four common pricing models:

Potential Pricing Zone CautionZone

DangerZone

CautionZone

DangerZone

Price your data product along this range

$100/userCost of

Product w/o analytics

$120/userCost of

Product w/ analytics

$150/userCurrent

product price

$200/userCompetitor’s product price

$165/user for Basic

$20/usercost of analytics

$180/user for Plus

$200/user for Pro

The analytics pricing model in action.

45©2015 Birst Inc.

2


1. Price is a flat, recurring fee

2. Price is based on the amount of transactions performed

3. Price is per user

4. Price is a percentage of some asset base (such as inventory or money managed)

Whichever model is used for your core product, make sure the analytics are priced the same way. If you charge a flat fee annually, you could increase the fee by 10% for the new analytic capabilities. If you charge per user, you may increase the per-user price by 10%.

They key here is that you don’t want to mix and match; don’t charge per user, for example, and then show a line item in the sales contract such as “Analytics: 1 year, $10,000.” Pricing differences stick out and quickly become negotiating points that customers may try to exclude from the deal. Again, you don’t want anyone opting out from the awesome analytics experience you’ve created.

Establish pricing for professional services

If you’ve decided to structure analytics into tiers, as previously recommended, one of those tiers probably includes some customization to fit specific needs. If so, make sure to determine a price for the professional services required to make the necessary customizations.

Who will be doing these customizations? Will it be your company, or will a partner or an implementation firm perform the specific changes your customer is requesting? A good way to approach this – since every customization is, by its very nature, custom – is to set an hourly rate, include that rate in your pricing schedule, and then scope each request individually.

Make sure you can monitor usage

The best pricing model in the world doesn’t matter much if you can’t monitor utilization, and identify if and when a customer has moved to a new pricing tier. In many cases this is quite simple: A customer needs the functionality found in a higher tier, they request it, and you activate the functionality and adjust their billing.

But in some cases you may decide to price based on the amount of data, whether how many years available or quantity of data (i.e., gigabytes or terabytes) stored. In these situations it can be hard to build in warnings or cut-offs as customers approach pricing boundaries.

When you price based on volume, how will you identify when a customer is approaching the next tier? Depending on the number of customers you have, this can be a nontrivial exercise. You should account for this as part of both the pricing model and your support ecosystem.

1

2

3

4

46©2015 Birst Inc.

2


Lifecycle support

Congratulations! You’ve done the hard part; you’re pretty much done with the product – time to celebrate, right?

Not quite. Now the hard part begins. You still need to figure out how to make this set of analytic capabilities a true product. And that means figuring out all the processes many companies tend to ignore: customer installation, change management, issue handling and support, marketing, sales, training, billing... Whew!

But like everything else, it’s not so bad. Let’s get started on the support processes that will ultimately make your analytic product a huge success.

The support ecosystem

It’s true that building out support processes simply isn’t as fun as creating analytics. But it’s absolutely essential to successfully go to market. Nothing is worse than spending time and resources to create a new analytic product, only to find out you can’t support it post-launch.

Avoiding post-launch disaster is easy. All you have to do is plan.

BI Functionality

Core Product

What companies spend their time on...

What they forget...(until it’s too late)

Billin

g

Supp

ort

Ope

ratio

ns

Mar

ketin

g

Prov

ision

ing

Trai

ning

Chan

ge

Man

amge

men

t

47©2015 Birst Inc.

2


Here’s the way we approach building the analytic product support system:

Gatheryourteam: You need members who are empowered to make decisions and who can drive projects through to completion. These people and processes should be part of your support ecosystem team:

• Sales• Marketing• Operations• Billing/finance• Product management• Customer support or Help desk• Change management (this could also be someone from Development/Engineering).

Once you establish the team, schedule a kickoff meeting so you can execute step two.

Assigntasks&timeline: In your kickoff session, the primary goal is to brainstorm all the tasks that need to be completed and set a timeline. Do this through role-playing: Pretend you’re about to install the product for a new customer. Walk through exactly how you will accomplish this task.

As you move through the steps necessary to bring a customer on board, write down the items you discover. Continue role-playing the process through the entire customer lifecycle, including:

• Performing a sales demo• Installation• Training• Provisioning of individual users• Customizing the product fit any specific customer requirements • Billing for utilization, handling a trouble ticket, handling requested changes• Sunsetting the application for that customer.

Developcontrol systems

Gatheryour team

Assign tasks& timeline

Buildprocesses

Conduct walk-throughs

48©2015 Birst Inc.

2


Buildtheprocesses: Next, the team members need to build out the processes brainstormed in the kickoff session. A good way to accomplish this is to start from scratch – because when you build a new process on top of a pre-existing one, it’s easy to include many steps

that aren’t absolutely essential. (Basically “process plaque” that has built up over the history of your organization.) You can avoid this by setting starting and ending points for the process and then trying to get from start to end in as few steps as possible.

Once the processes are documented, the next step is to test them and make sure they’ll be effective.

Conductwalk-throughs: How do you know if your processes are performing well or if they have issues that need to be corrected? Metrics and tripwires will tell you.

Metrics allow you track the performance of each one of your critical support processes. The metric for the installation process could be the number of activations in a week. For the help desk process, the number of issues received over a given time, or the number of issues per customer. Establish metrics for:

• Cycle time• Throughput• Quality or fallout• Customer satisfaction as measured by complaints, issue, or trouble tickets.

Tripwires for processes are like alarm systems in your house that let you know if somebody is sneaking in the front door – they let you know if something bad is about to happen. Tripwires are pre-established thresholds for metrics you created that, when exceeded, indicate you need to take action.

For example, let’s say you receive an average of 25 customer support tickets per week. You may want to establish a tripwire at 35 tickets. If you receive 35 tickets in a given week you will take action, but – and this is important – you need to predetermine what that action will be. Examples of tripwire actions are:

• Conduct a review meeting• Stop new activations• Increase the amount of monitoring performed• Add headcount to the help desk or installation team.

The reason to establish tripwires ahead of time is so that when faced with a problem situation, you don’t waste valuable time trying to decide if action required.

49©2015 Birst Inc.

2


Developcontrolsystems: Process flow charts aren’t always 100% effective in reflecting what really happens. It’s too easy to skip over small but critical elements when you’re pounding away on Visio or OmniGraffle. But, they are necessary evil that everybody understands.

One way to make sure you didn’t miss any critical elements in your process is to conduct a walk-through – yes, physically walking through the steps of your process.

First, print out each step of the process you designed on an individual sheets of paper. Then, find a large room and lay out each piece of paper (flowchart style) on the floor in the appropriate order. Then literally walk through each step, stepping from one piece of paper to another, reading out loud the activity that is supposed to occur. You might feel a little silly doing this, but the simple act of walking activates the kinesthetic part of your brain, causing you to think about process steps you otherwise might have overlooked.

Holding the team accountable

Of course, it doesn’t matter how well designed your processes are if it’s unclear who’s responsible for their execution. We recommend that once you develop your support processes, make sure everybody in the organization understands who’s responsible for which steps.

To make sure there is common understanding, we recommend using the “R-A-C-I” matrix, which specifies who is responsible, accountable, consulted, and informed at each step.

The RACI matrix is pretty effective at getting the team to think through who actually does what within the process being designed. We recommend that for each support process developed, you build a RACI matrix.

Here’s how it works: List the steps in your process in the first column on the left hand side. In each subsequent column, list the roles that may be involved. Don’t limit the roles to a specific organization, but consider any role that may claim any part in the specific step. Finally, indicate the involvement for each role at each step in the process.

The example below is for a software installation process. For the first step, “receive request,” the sales representative is responsible for executing the step but other roles such as order entry, account management, and the help desk are informed that the step took place. Executive management is ultimately accountable for making sure the step happens properly and the analytics OEM vendor – i.e., Birst – is consulted if the request is out of the ordinary.

50©2015 Birst Inc.

2


Failure planning

As much as we like to think we’ve thought everything through, mistakes happen and problems crop up. It’s a fact of life. So, it makes sense to plan, minimally, for the most severe issues you may encounter. The failure modes and effects analysis (FMEA) matrix is a great tool for thinking through possible problems and planning your response.

The FMEA matrix lists everything that could go wrong and then scores each potential failure for severity, likeliness to occur, and how hard it is to detect the failure if it happens. It then assigns each failure item an overall score.

In addition to being a useful tool for planning emergency responses, teams love building FMEA matrices. They give everyone a chance to think about all the bad thoughts lurking in the back of their minds, all the reasons the product might fail. It gives the team a chance to get it out of their collective system.

The R-A-C-I matrix makes it easy to fully think through business processes, reducing the number of surprises that occur.

• Receive requestStep Sales Rep Order Entry Help Desk

Account Manager

ExecutiveManagement

Responsible

Accountable

Accountable

Informed

Informed

Responsible

Consulted

Consulted

Informed

Consulted

Responsible

Accountable

Informed

Informed

Informed

Responsible

Accountable

Informed

Informed

Informed

Receive request

Implementrequest

Performtraining

Handle level 1 issues

Roles

51©2015 Birst Inc.

2


Start with a brainstorming session in which the team members (the key support process stakeholders) list all of the possible product failures, and any other issues that may occur within support.

Next, for each listed failure, determine the score for:

1. Severity: If this problem were to occur, how bad would it be? Would it be an absolute catastrophe (score it a “10”) or of very little consequence (score it a “1”)?

2. Likeliness to occur: What’s the probability of this issue happening? Is it almost certain to occur (10) or exceedingly unlikely (1)?

3. Difficulty to detect: If the issue does occur, are you likely to notice that it happened? Very tough to detect is a 10. If you’d notice right away, give it a 1.

Once you’ve scored the failure, multiply the values in each column to find the overall “failure score.” Rank order the scores from largest to smallest. You now have a completed FMEA matrix!

The next, and most important, step is to take the top 10-15 issues and for each, figure out a mitigation plan. If the failure happens, who will take the lead in responding and what will they do?

A fully populated FMEA matrix.

• Receive requestPotential FailureHowSevere?

(10 severe - 1 minor)HowLikelyto

Occur?(10 High - 1 Low)

HowHardtoDetect?

(10 Hard - 1 Easy)

10

8

10

9

9

8

4

10

6

8

9

3

New customer instance fails to provision via API call

SSO call fails and customer is not properly authenticated

Winged monkeys attack the data center

Support email is missed in support system and trouble goes unnoticed

3

2

1

FailureScore

540

512

360

270

52©2015 Birst Inc.

2


Operational readinessDon’t stop now – there’s still lots to consider before you’re ready to launch!

Operational readiness encompasses the million other little things you may overlook when preparing to launch your analytic product. Here are some areas you may want to review to assess readiness:

Sales

• Is the sales team trained? • Do they know the boundaries of the product? • Do they know critical launch dates? • Do they know the rollout plan? • Are the sales overview or “pitch” presentations updated to reflect the analytics? • Are demo instances of the application prepared? • Have you prepared industry-specific demos?

Marketing

• Is the product collateral created/updated?• Have logos been created? • Do you have a launch campaign prepared?• Have you prepared press releases?• Does the analytic application conform to your corporate visual brand guidelines?

Training

• Have you trained the support team?• Have you trained the operations team?• Have you trained the sales team?• Do you have training available for your customers’ users?• Where is documentation available?• Do you have a dictionary of the various metrics available in your application?• Do you have an FAQ?

53©2015 Birst Inc.

2


Legal

• Have your contracts been updated to reflect the fact that data is being processed by third party, such as Birst? Although most customers are fine with this, you’ll want to make this fact perfectly clear in your contracts.

• Have your customers opted in to benchmarking so their anonymized data may be used in the benchmarking process? If not, will they still be allowed to use benchmarking?

• Do the service level agreements (SLAs) for your core application match the SLAs in the analytic product?

• Are there any security or intellectual property concerns that need to be addressed?

• How will you get customers to sign these new contract terms? New customers? Existing customers?

The launch plan

The last thing that you want, after building a great analytic product, establishing all the support processes and ensuring operational readiness, is to then have the whole thing fall apart at launch. That’s why you need to develop a reasonable launch plan.

But first, let’s list the things you don’t want to do:

Don’t try to launch to all customers at the same time

Don’t forget the beta

Don’t plan to on-board customers in rapid succession, back to back to back

Don’t group all of your “high touch” customers in the same launch tranche.

54©2015 Birst Inc.

2


OK! Now let’s talk about best practices for your analytic product launch.

A phased rollout is the safest, most effective plan.

Divide the entire base of customers (to which the analytic application will be deployed) into tranches or buckets. Make sure that you don’t group very similar types of customers – such as all brand-new, all strategically critical, or all low technical experience customers – into the same bucket. Doing so invites extra work during the rollout.

Plan a sane rollout schedule. Allow some time between each rollout tranche to learn from what you just experienced. If you encounter problems, either with the product or the rollout process, you’ll need to be able to make adjustments before the next group of customers goes live.

2

3

Establish a beta period when “friendly” customers can evaluate the analytic application and give you their honest feedback. Make sure these customers run the gamut from large to small, brand-new to longtime supporters, high utilization to infrequent users. You want the beta to test the far edges of both your product and your processes.

1

Finally, establish a command center during this critical time. Select stakeholders from the essential support processes (covered on pages 47-49) and make sure they are available during each rollout. If there’s a problem with provisioning a customer, a technical implementation, or training a user – you want to know immediately whom to call.

Yourmantra: Plan a sane schedule, don’t group all of your “challenging” customers together, and leave some time to learn. You’re on your way to a successful launch!

Productready

Betacustomerrollout

1sttrancherollout

2ndtrancherollout

3rdtrancherollout

newcustomersonboard

learning period learning period learning period learning periodlearning fromoperations

readinessprep/drills

55©2015 Birst Inc.

2


A Tale of Two Analytic Products

Now that you understand the process for creating a great analytic product, let’s see that process in action. To do that, we first need to introduce a cast of characters.

Meet Jill

Jill is an experienced product leader at GlobalLlamaTech.com – the worldwide leader in online llama management technology. For several years now, she’s been heading an effort to build a SaaS-based llama tracking system for llama farmers all over the world.

As you can imagine, in the course of managing a global llama population, GLT generates quite a bit of data. Llama feeding patterns, correlation between rainfall and overall llama yield, and llama-to-shepherd ratios are all information GLT feels might be important to the average llama farmer.

Jill has been charged with embedding analytics within the GLT application.

Meet Rachel

Our other player is Rachel, the Chief Product Officer at My-Medi-Share.com, an innovative new service that lets users publish all of their medical records online and share their information with friends. It’s projected to be a very lucrative market.

As with GLT, Medi-Share generates huge volumes of data in the course of doing business. Information such as drug interactions, most popular medications in a user’s network, and common side effects can be very useful both to patients and doctors.

Rachel is also charged with embedding analytics within the MMS product. Her goal is to be up and running in the next 60 days.

Getting started

Jill is a little concerned about this project. After all, she’s a llama authority but isn’t really an expert in analytics. She’s never done a project like this before. However, like you, she’s read through this Guide and has the basic concepts down.

Jill starts by interviewing key stakeholders – GlobalLlamaTech’s CEO, heads of the various organizations that will support the product, and two or three key customers who expressed interest in the product. As she conducts her interviews, Jill notes key differences in the goals and objectives of each group. She writes these items down for later discussion in the product workshop, where she’ll focus on getting team alignment.

56©2015 Birst Inc.

2


Rachel approaches this problem little differently. She’s implemented analytics before and is pretty confident about her ability to be successful yet again. Although her previous experience was in using analytics inside her company, Rachel figures, “Heck, how different can building a product be?”

She starts her project by gathering a list of the reports Medi-Share generates today and delivers to its users via Microsoft Excel spreadsheets. She knows that this will be a great starting point for her analytic product. After all, if users like it today, they’ll love it tomorrow once it’s prettier.

Workshops and decisions

Jill convenes a product workshop with all of the key stakeholders present. No one is present who doesn’t need to be there. She leads the team through a discussion on their elevator pitch, the key personas that should be addressed in the initial phase,

the boundaries of their analytic application, and then starts the initial thinking about pricing and tiering.

After an exhausting day, the GLT team has agreement on the desired end-state for the analytic product and a phased approach to get there. Although they aren’t in complete agreement on how to price the product, the team at least agrees to a tiered structure for it, and to charge customers an additional fee for the new analytics.

At Medi-Stat, Rachel doesn’t need to conduct a product workshop. After all, she’s done this before. Earlier in the core product’s lifecycle, she looked at various competitors’ offerings and realized they all included analytics within their applications.

Based on this evidence, Rachel concludes that MMS needs to offer analytics as part of its core offering, without any additional fees or charges. “Analytics are table stakes,” she decided. “We can’t charge for things that customers expect to be included in the core app.”

Given this decision, Rachel also decides that all customers will get analytics as a single bundle. “No tears, no upset, no options. As long as you opt in, you get analytics. Free,” she says.

Measured, methodical progress

After the product workshop, Jill held several more sessions with the organization’s leadership. They settled on offering three tiers of analytics – basic, plus and pro, each for an additional fee – with all customers starting on the basic level.

GlobalLlamaTech decided to try pricing the analytics at +10% for the basic package, +20% for plus and +25% for pro analytics. They felt that this might be challenging, given GLT’s fee-per-llama managed pricing model, but decided they could offer enough compelling insights to make the fees palatable.

57©2015 Birst Inc.

2


The GLT team spent significant time listing the various options they could offer to customers in each tier.

Here’s what they decided:

• Basic would include one dashboard focused on the executive shepherd. It would incorporate one year of data, and would not allow any modification of analytics or dashboards.

• Plus would include two personas, the executive shepherd and the director of llama operations, incorporate two years’ worth of data, and what have “internal benchmarking.” That is, customers would be able to perform comparisons on data originating inside their company, such as shepherd versus shepherd, region versus region, herd versus herd.

• Pro would include three personas, five years of data, and would allow the customer to benchmark both internally and externally (compare themselves to other llama ranchers), and to perform ad hoc analysis.

The team reviewed these plans internally to make sure the model could be supported, and secured a few “friendly” customers to make sure the offering would be compelling.

For each of the personas GLT had selected, Jill and the team spent considerable time interviewing both management and shepherds to identify the details of their missions, how accomplish their work, and their pain points. These elements led GLT directly to the analytics to be offered at each of the product’s three tiers.

Relying on instinct

Rachel had an easier time of it. She didn’t have to do all the time-consuming work of interviewing personas or structuring tiers and pricing, since Medi-Stat decided to offer analytics as a single bundle, to all customers, at no additional charge. She

didn’t have to spend much time deciding which analytics to offer, either. After all, the users already had those Microsoft Excel spreadsheets as the foundation for their new dashboards.

Rachel jumped right into the technical augmentation, asking the development team to simply replicate the charts and tables within each Excel spreadsheet. The development team, by the way, didn’t receive any training in the business intelligence platform used to build the new analytics. As experienced engineers, they decided they could figure out on their own as they went along.

Six weeks later, Medi-Stat was ready to launch. And they did.

58©2015 Birst Inc.

2


Executing the plan

Meanwhile, Jill still had a lot more work to do. She gathered leaders from the sales, marketing, operations, finance, legal, and support teams. Together they brainstormed all the processes that would be impacted by the addition of an analytic product. They

identified processes to be developed and key tasks to accomplish.

Once each leader had developed the necessary processes, the team conducted walk-throughs to identify any gaps, built a RACI matrix for each process, and used failure modes and effects analysis to develop mitigation plans for any major failures that might occur with the new analytic product.

In parallel, Jill worked with various organizations to develop logos, sales collateral, demo instances of the product (including analytics), and training materials.

She decided to offer internal training in three parts:

• An initial awareness session to help the team understand the plans

• A detailed session to explain exactly how the analytics would be displayed, and what functionality would be present

• An operational session to teach the internal organizations the processes required to run the analytics lifecycle

Finally, Jill worked with GLT’s stakeholder team to develop a launch plan. They decided not to launch to all customers at once, but rather to roll out the analytic product over a 90-day period, with a two-week gap between each tranche so they could learn from their mistakes.

The team grouped customers for the rollout randomly, making sure that GlobalLlamaTech’s high-value customers did not all go live at the same time. They established the command center, metrics, and tripwires to monitor their progress and easily identify problems as they occurred. When problems did arise, they used the FMEA matrix to decide what to do, quickly.

59©2015 Birst Inc.

2


The sound of silence

Rachel and her team simply launched the product. Once the development team was finished, they flipped the switch and rolled out the analytic product to customers.

The response was tremendous – in terms of its resounding silence. Medi-Stat’s customers noticed the new analytics tab, and appreciated the visuals and the higher level of interactionthey could have with charts that previously had been static and emailed. User engagement increased over the first four weeks, but gradually tapered off over the next six months.

After a slight uptick in interest for the core product, sales and usage slowly fell back to previous levels. Although Rachel and her team were no longer creating and distributing Excel spreadsheets, they hadn’t seen any increase in sales or long-term customer engagement. Rachel wasn’t surprised – after all, customers expect analytics. This is why she didn’t charge.

Managing the rush

Jill had a slightly different experience. After GlobalLlamaTech completed the rollout, they got questions from customers – lots and lots of questions. Customers were intrigued by the analytics and the new insights they gained, but wanted more. About

30% of the customers moved immediately to plus tier, seeing immediate value in added data available and the internal benchmarking. Another 10% of the customers jumped right to pro; they wanted to create their own analytics and see how their llama operations compared to the rest of the industry.

But still, GLT’s customers wanted more. The feedback form Jill had implemented to gather future feature requests did its job. She received numerous ideas that were added to the analytic product roadmap.

As for engagement? It jumped. Not only did GLT boost its revenues with sales of the analytic product; interest in the core products jumped, as well. Customers visited the application more frequently and stayed on far longer than previously. Jill attributed this largely to the team’s well thought-out engagement model. They had built in alerts and notifications, made each analytic easy to use to reduce cognitive friction, created valuable rewards by tying each analytic to a persona’s pain point, and encourage user investment with comment and suggestion sections in the dashboards.

You could make the case that Rachel and Jill both were successful in their projects; it’s just that their expectations were different. Rachel viewed analytics as simply another feature to add to achieve parity with the competition, while Jill viewed her analytic product as a competitive advantage. It’s all in your perspective. Choose your own adventure!

60©2015 Birst Inc.

3

3


Where do you go next?Congratulations, you’ve made it past the finish line ... or have you?

You’ve created a strategy, defined users, build analytics to meet user needs in an engaging analytic product, and successfully launched to your customers, but you’ve got more to do. You need to plan for the future.

An analytic product is like a journey, not the flip of a switch. Launch day is not the end of your project, but rather, the beginning. You need to consider the entire lifecycle of your analytic product, and a major part of that is the future roadmap.

Here are some suggestions for ensuring that the hard-won customer engagement in your analytic application doesn’t stagnate and taper off over time.

First, create a mechanism for gathering feedback. This may be a form on which users can submit suggestions and comments. It may be regular feedback sessions with the sales organization, which is closest to potential customers. It may be feedback sessions with the support team, which hears all the issues the customers are having. Ideally, it is all of these things.

Take the information that you receive and evaluate it in the context of your personas, missions, the boundaries you established, and your strategic objectives. This will help determine which items make it onto the roadmap for future development.

Second, visit your users. Select willing customers and spend some time “shoulder surfing” to watch how they actually use the analytic product. Do they follow the analytic workflow? Do they jump around? Have they created lots of new charts and dashboards that you never considered? These things they may be indications that you need new personas, need to rethink the workflows, or the existing analytics could be enhanced in the future.

However you decide to proceed, the key take-away is that analytics is a journey; implementation day is not an endpoint. You need to constantly monitor user engagement for ideas about how to increase the effectiveness of your analytic product for future releases.

61©2015 Birst Inc.

4


ConclusionYou’ve come a long way! At this point, you understand:

The various types of business intelligence

What makes a great product

How to get your team aligned around your product strategy

How to pick personas, their missions, their workflows

How to understand personas’ pain points to create analytics with value

How to present those analytics so they convey the most meaning for your users.

What’s more, you’ve learned how to create an engaging product by thinking through the triggers, actions, rewards, and investment elements it contains.

You structured your analytics and tiers, defined a pricing model, and built out a support ecosystem that will ensure the success of your product when it launches.

Finally, you learned about getting feedback from users to inform your future roadmap, and how to treat your analytic product like a journey, not an end-state.

We’re happy that you made it this far, and look forward to seeing you take the next step in building your analytic product. The world is filled with too many that are just prettier versions of static spreadsheets. It’s cluttered with analytics scattered on dashboards with no rhyme or reason. We’ve seen too many beautiful dashboards that start off strong but die once the newness wears off. And we’ve had our fill of complicated analytic systems that look great, sound wonderful, but simply don’t add any value.

Now it’s your turn. Be the change. Use what you’ve learned like a toolkit and apply the various techniques where they make sense. We look forward to seeing what you can do, what you can build, and the insights you can generate with your analytic products.

And remember, if you ever need help, give us a call. We look forward to building a product with you, Powered by Birst.


About Birst

Who we are

Now that’s you’ve read our guide, you might be wondering, “Who is Birst, and why are they uniquely qualified to help me build a successful analytic products?”

It all starts with the technology platform. Birst is the global leader in Cloud BI and Analytics. We help organizations make thousands of decisions better, every day, for every person.

Birst’s patented two-tier data architecture and comprehensive BI platform sit on top of all of your data, to unify, refine, and embed data consistently into every individual decision, up and down the org chart. Thousands of demanding businesses trust Birst Cloud BI to make metric-driven business execution a reality.

As far as building analytic products, we’ve done hundreds of them. And not just as technology providers or consultants. Many of our team members were product owners and developers themselves – charged with selecting business intelligence vendors, defining customer needs, integrating the analytic capabilities in the core product, and making sure the whole thing was successfully launched.

We’ve been there and done that. And we’ll help you do it too.

Why we’re differentLet’s face it. Creating an analytic product is fundamentally different from implementing analytics inside your organization. Most of the time these projects are run by product owners who, though experts in their own product, often have never implemented analytics in the past. They have to learn on the job, as they go, and that’s just plain scary.

It can also feel like a high-wire act to the first time implementer. You may have an existing product you are integrating analytics into; you want the project to be successful, but not if it means putting an existing product or its users at risk.

10110100


Luckily, the Powered by Birst program has you covered. We combine the three elements you need to create a successful analytic product:

A great platform that does what you need today and gives you options for the

future

The ability to embed analytic functionality seamlessly within

your application

The know-how and experience to avoid all of the mistakes

the first-time implementer may encounter.

Two-tier architecture

The Birst two-tier architecture is all about options. It makes sure you’ve got the best analytic platform today and will be covered in the future. With our platform, you don’t have to worry about replacing existing data warehouses or sources – we can just connect to them.

We can also connect to cloud data sources and user generated content, combine it, and make it all available to users in a single cohesive dashboard. Only Birst’s two-tier architecture allows you to do this.


Automated Data Refinement

One of the dirty little secrets of the BI industry is that with many platforms, each time customers need new insights or new analytics, you need to spend costly time and resources adjusting the underlying data model. Obviously, you’re not earning any money when your platform is down. In addition, who exactly is performing this modification to the data model? Is it you? A consultant?

With Birst, you don’t need to worry about these issues.

Our Automated Data Refinement system takes your data and models it into the format necessary to present analytics, including all the possible dimensionality. It saves you large amounts of time and energy, not to mention the costly downtime associated with other BI platforms.

“Don’t try this at home. Birst’s Automated Data Refinement handles the heavy lifting for you.”


Flexible deployment options

Product owners know that user needs often change over time. You start by offering an analytic product via the cloud, and a customer asks, “Can you do this on-premise?” or “Where is my data? Can it be located on another continent?” You don’t want to have to answer “no” to any of those questions.

With Birst, you can choose either cloud-based or on-premise deployment and have exactly the same feature functionality. We let you make the decision: Would you like us to manage the business intelligence platform or do you prefer to do it yourself?

With Birst, it’s all about options.

On-Premise BI

• Keep your data and servers on your site and under your control

• Add storage as your product grows• Contains all the features of Cloud

BI - no compromises

Cloud BI

• Leave the management to Birst - focus on your product

• Scales automatically with your data• Includes 200GB of cloud storage• Meets all key security features


Full white labeling

All of this functionality is of no value if you can’t embed it seamlessly within your core application. The last thing you want is for the experience to change abruptly as the user moves from core functionality to the analytics embedded within your product.

Birst allows full white labeling with single sign-on, removal of logos, customized color schemes, and complete localization into the languages of your choice.

Our theming capabilities allow you to change the look and feel of your analytics with the click of a button. Birst localization features show your analytics – including the interactions – in the language of your choice. And, our single sign-on capabilities work in tandem, serving the right themes, languages, and security levels to the right users at the right time.

Birst delivers the ultimate in white-labeled analytics.


Endnotes1

3

4

Adapted from “Magic Quadrant for Business Intelligence and Analytics Platforms,” February 5, 2013, Analyst(s): Kurt Schlegel, Rita L. Sallam, Daniel Yuen, Joao Tapadinhas and from “Disambiguating Analytics,” July 2, 2013, Sanjeev Kumar, International Institute for Analytics

See http://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/

Hooked: How to Build Habit-Forming Products, Nir Eyal, November 2014

Call toll free: (866) 940-1496Email us: [email protected]

About BirstBirst is the global leader in Cloud BI and Analytics. The company helps organizations make thousands of decisions better, every day, for every person. Birst’s patent-pending 2-tier data analytics and BI platform enables enterprises to create a trusted source of data, place it in the context of key business users and then enable business users up and down the organization to report and analyze the information using world-class BI tools. Thousands of the most demanding businesses trust Birst to make metric-driven business execution a reality. Learn more at www.birst.com and join the conversation @birstbi.

AboutBirstBirst is the global leader in Cloud BI and Analytics. The company helps organizations make thousands of decisions better, every day, for every person. Birst’s patent-pending 2-tier data analytics and BI platform enables enterprises to create a trusted source of data, place it in the context of key business users and then enable business users up and down the organization to report and analyze the information using world-class BI tools. Thousands of the most demanding businesses trust Birst to make metric-driven business execution a reality. Learn more at www.birst.com and join the conversation @birstbi.

Beyond the Technical_Interactive

Documents

Transcript of Beyond the Technical_Interactive