Birst Beyond The Technical The Complete Guide To Embedded Analytic Products PDF

BEYOND THE TECHNICAL
The complete guide to designing, pricing,

& launching embedded analytic products

BEYOND THE TECHNICAL & launching embedded analytic products ©2015 Birst, Inc
Contents
WELCOME 3
CHAPTER 1 - Basics 6
CHAPTER 2 - Process 11
Methodology 11
Interviews 13
Setting the course 14
Workshop 15
Elevator pitch 18
Personas 20
Linking personas, missions, workflows 23
Create the offering 30
Product tiers 34
Pricing 41
Lifecycle support 46
Operational readiness 52
The launch plan 53
A tale of two analytic products 55
CHAPTER 3 - Where next? 60
CHAPTER 4 - Conclusion 61
ABOUT BIRST 62
END NOTES 67

BEYOND THE TECHNICAL & launching embedded analytic products ©2015 Birst, Inc 2
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”?

& launching embedded analytic products ©2015 Birst Inc. 3
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
info@birst.com. Thanks!
Our Guide lays out all the steps necessary to build a successful data product, Birst style.

!
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 info@birst.com. At Birst, we love building analytic products and we love sharing our
knowledge.


1 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 Questions Answered
• Optimization • What’s the best that can happen?

Prescriptive What happens if we try this?
• Randomized testing •
• Predictive modeling/forecasting • What will happen next?

Predictive • Statistical modeling • What is making this happen?
Capability
• Data exploration • Why did this happen?

Diagnostic • Intuitive visuals • What insights can I gain?
• Alerts • What actions are needed?

Descriptive • Query/ drill-down • What is the problem?
• Ad hoc reports/ scorecards • How many, often, where?

BEYOND THE TECHNICAL & launching embedded analytic products ©2015 Birst Inc. 6
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.

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.
• Data or analytic product: 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-premise business intelligence: An analytic platform that is served from hardware

located in a facility under your control or your customer’s control.
• Cloud business intelligence: Analytics that customers access via the web, that are
centrally deployed, managed, and maintained by the business intelligence provider, i.e.,
your software company.
• Full stack business intelligence: A business intelligence platform that performs all
essential functions – from data extraction, to data transformation, to visualization – to
deliver insights to your users.
• Point solution: A business intelligence application that delivers one component of

analytics, such as visualization or data extraction.
• White-labeled solution: 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-labeled solution: 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.

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.
A data product that attracts new users and engages your existing users by
providing key business insights
1 2 3
Great technology that won’t Ability to embed the The go-to-market process
limit your opinions down the functionality into your to help you avoid all of the
road product preserving the use traps that can kill a data
experience product
Building a great data product with “legs” has three important requirements.

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.

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 at
the 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.
Initial
Product
interviews Technology Technology
workshop
with kick-off implementation
(kick-off)
leadership
Develop Develop
personas/ metrics &
workflows reports
Support Process Development

Create Legal Sales
product
readiness readiness
functionality
tiers sessions sessions
Develop
launch
strategy
Develop Marketing Support

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

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.

2 Interview stakeholders
A 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.
CEO/ Product What is your vision? What are your goals? What’s
1
Sponsor the timeline? Why are you doing this?
Agree?
Key internal What are your goals? What’s the timeline? Why
2 are you doing this?
Stakeholders
How do you work today? What are your pain points?

3 Key customers What would help you? Would you use this?
Here are the three stakeholder groups to be interviewed and the questions you might ask.

2 Setting the course
It’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.
Differentiate
(we’re the leaders!) Separation Unmatchable How far?
Neutralize
Comparability Good enough How fast?
(we’ve got BI too!)
Two product strategies that you may choose to pursue (adapted from Escape Velocity, Geoffrey Moore, 2011.)
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.

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.
In this mode If you choose Instead of You get
Squandered
Differentiate As good as the Unmatchable resources as
competition VS functionality competitors
quickly catch up
Neutralize Best-in-class VS Good enough Wasted

budget
Two product strategies that you may choose to pursue (adapted from Escape Velocity, Geoffrey Moore, 2011.)
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 workshop

Although 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.

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.
The product workshop is where your strategy, product structure, and pricing model are crafted
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.

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.
CEO
Chief Product Officer Product Owner or Champion
Chief Technology Officer
CFO or senior Finance representative
Head of Marketing User experience representative

Product Workshop attendees
Head of Sales Senior Legal respresentative
Head of Operations
Head of Customer Support
Head of Development/Engineering
Project manager or project lead
A summary of the key stakeholders who need to participate in your product workshop.
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.

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.
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
A sample agenda for your product workshop.
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 pitch

Imagine 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

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?
A great 30-60 second elevator pitch is crucial to the success of your analytic product.
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.

2 Select personas
A 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:
Executive or Tactical end Internal

managerial end users users
users
Here’s what each of these categories means:
Executive end users 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.”
Tactical end users 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.
Internal users 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.

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.
Marketing
team
Sale Reps
Customer
Service
reps
Tactical
End Users Installation
CTO team
CMO
CPO
Executive Your
Your
End Users Marketing
Finance/
team
Billing team
Head of
Sales
Potential
Internal Your Head
Head of Data Product Users of Sales
Operations
Users
Your Head
of
Your CPO
Operations
Use a mind map to divide your users into three groups when determining which needs to address first.
Create persona cards
Role or Title VP of Marketing
The focus of all demand gen programs

Key Characteristics A trusted advisor to the executive and sales teams
Pulled in many different directions
Needs to develop marketing campaigns that attract new customers and

Mission
encourage existing customers to try new products and features
“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”
Frustrations or Pain Points Tools Used Today Key Wishes or Needs
Can’t see performance by region, team, Salesforce.com 360 view of customers

or campaign Marketo 360 view of campaigns
Can’t perform “what if” analysis Excel spreadsheets See gaps and coverage
Guesses at best course of action Funnel tool See geographic overview of campaign
Can’t see if campaigns touch customers NetSuite reach
multiple times or if gaps exist
Persona cards keep a wealth of customer insights in a simple, at-a-glance format.

2 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:
1. Identify the key characteristics of the persona. What makes this user unique? Are there
1 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
2 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
3 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
4 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
5 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
6 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.

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

Select Persona Determine Mission
Mission
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:
11. Identify target markets
22. Build a target list
33. Select collateral to serve to the customer
44. View what might result from the campaign
55. Finally, launch the campaign.
Mission: Create high performing marketing campaigns
Workflow: create campaign
View potential
Identify target Select collateral
Build target list results from Launch campaign
markets to serve
campaign
A typical workflow for a Marketing executive persona.
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.

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.
Workflow: review and adjust performance
ID Determine regions Adjust campaign

Review status of Project revised
underperforming or segments target list or
campaigns results
campaigns underperforming collateral
Pain point: Pain point: Pain point: Pain point: Pain point:
I can't easily filter I can't compare campaigns I can't see performance vs I have to wait 24 hours to I can't predict what may
campaigns by dimensions to past performance target see my changes reflected result from my changes
Pain point: Pain point:

I can't see benchmarks for I have to guess at the best
performance changes to make
Workflow for a Marketing executive persona with pain points added.
Follow this process for each pain point in the workflow.

underperforming or segments target list or
campaigns results
Pain point: Pain point: Pain point: Pain point: Pain point:
I can't easily filter I can't compare campaigns I can't see performance vs I have to wait 24 hours to I can't predict what may
campaigns by dimensions to past performance target see my changes reflected result from my changes
Pain point: Pain point:

I can't see benchmarks for I have to guess at the best
performance changes to make
Table with filters Clustered bar chart Bar/line chart Predictive analytics
Possible analytics that you could display to address the pain points for this persona
Identify the analytics which will address each pain point and help the user accomplish their mission.

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!
Workflow: create campaign
View potential
1 Identify target Select collateral
Build target list results from Launch campaign
markets to serve
campaign

2 underperforming or segments target list or
campaigns results
Workflow: identify new audiences
ID underserved
Review audience Adjust list to Project revised
3 audience
list coverage increase coverage results
segments
Multiple workflows comprise the Marketing executive’s mission to create high performing marketing campaigns.
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

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:
Done in previous steps
Create Identify
Select Determine Select Select step in
workflow for analytics that
persona mission workflow workflow
mission assist in step
The steps to developing the analytic workflow.
1
1. Start by picking a persona and a primary mission for it.
22. 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
3 mission. For example, given the mission “Understand campaign performance,” a Marketing
executive persona might follow these steps:
Gather campaign Determine

Identify Repeat steps
data including campaigns that Try to identify
campaigns that 3 & 4 for high-
performance underperformed commonalities
have completed performing
and budgetary for the budget
campaigns
information spent

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.
Persona: VP of Marketing
Mission: Understand campaign performance
Step Workflow Step Possible Analytics
Identify campaigns Infographic showing total campaigns in-flight
1 that have completed Infographic showing total campaigns completed

Filter to select timeframes, regions, campaign types
Gather campaign data Table showing campaign title, budget, and performance data
2 including performance Filter to select timeframes, regions, campaign types

and budgetary
information
Determine campaigns Ordered/ranked bar chart showing top performers by leads produced
3
that underperformed for Line on bar chart showing average performance
the budget spent Ordered/ranked bar chart showing top performers by leads per dollar
spent on the campaign
Detailed breakdown of an analytic workflow.
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.

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.
Repeat for each persona & mission
Write the title of Group the index For each stack, Take a photo Test the order with
layout the cards in
each chart on a cards into stacks of the users - let them re-
the order you want
3”x5” index card by persona the user to view them arrangement arrange the cards
Here’s how a card sort works:
11. 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
2 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.
33. 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.

2
KPI showing Bar chart showing
Campaign performance over time
Conversion Rate with trend line
KPI showing
Total Campaign
Budget
Table showing
top deals
KPI showing
Budget
Remaining
Old-fashioned index cards provide an indispensable tool for testing analytic workflows.
11. 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
2 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:
• 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.
3. See if you can get to consensus, a flow that your testers is logical and still conveys your
3 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.

2 Create the offering
Let’s check in and see where we’re at. At this point, you’ve:
Aligned your team on the Selected key user personas Built the persona cards
goal for the first phase of your detailing the needs and pain
project points for each persona
Established the workflow and Tested the workflows using

analytics required to resolve the the card sort technique
issues with each persona
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
1. What will you do as part of the core product?
2
2. What will you do for an extra fee?
3
3. What will you not do under any circumstances?

2
Stuff We Won’t Do
Stuff We’ll Do
Stuff We’ll Do
as Part of the
for an Extra Fee
Core Product
The Product
Stuff We Won’t Do
In product development, as in life, it’s essential to set boundaries.
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:
• Part of the core product: 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.
• Extra fee items: 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.
• Things we won’t do under any circumstances: 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?”

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
Amount of How much data will you allow users 12 months; 36 months; 60 months
data to see?
Benchmarking Can users compare their performance to None; internal (compare teams, regions,
other teams, regions, or companies? product lines); external (compare yourself to
the industry)
Predictive analytics What will happen if we change things? No predictive; trend lines for specific
Will we hit our goals? analytics; what-if type analysis
Are changes cost effective?

2 Category Details Typical Options
Ad hoc Can users create their own charts and No - pre-built dashboards only; Yes - users
analytics other analytics or are they locked into are free to perform ad hoc analysis
the pre-defined dashboards you’ve
established?
Custom Can the user build new metrics in No - use only the pre-defined metrics; Yes -
metrics addition to what you’ve provided? create, use, and save your own metrics
Custom model Can the user create entirely new No - pre-built model only; Yes - user can
data models (mash-ups of data from modify the model
various sources)
Drill levels Can the user drill down? No drill down; drill down a few levels; drill
How far? all the way to the source data
Data layers Can the user bring in new data No layers; pre-built options; customizable
sources to augment their picture of by the user
performance? Will you provide these
as options or will it be done on a
case-by-case basis?
Data velocity Will the data be refreshed daily or in Daily; hourly; real-time for select analytics
real-time?

2 Creating product tiers
One 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.
1
• 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
2 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. The big question is, “What do we put in each of our tiers to compel customers to move
from the basic tier, to the plus or pro tier over time?”
Basic Plus Pro

• Included for all customers • Uses standard template • Uses standard template
• Uses standard template • Cutomization for an additional • Cutomization per customer
• Read-only dashboards fee needs
• No benchmarking • Read-only dashboards • Users can modify dashboards
• 1 year historical data • Internal benchmarking included (ad hoc analytics)
2 years historical data • Included external benchmarking
3 years historical data

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 Plus Pro
Customization, I’m set - ad hoc

Ok, I’m hooked but
comparisons, and analysis, more
am I missing out on
more data but I want data, and detailed
other insights?
more... benchmarking
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!

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.
Deep drill-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.”
Data layers: 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.

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:
1 2
Trigger Action
A sticky,
engaging
product
4 3
Investment Reward
The components of an engaging analytic product.

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:
1 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.
• External triggers 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.
• Internal triggers 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.
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.

2
3 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.
4 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.

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.

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.
Trying to catch the Question:

Can we charge for closing
competition the gap?
Making the Question:

Is the increased value of the
core engaging core product enough?
Competing on Can we create enough value to

Question:
analytics charge a premium?
Three pricing scenarios for analytic products.

2 Trying to catch the competition: 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.
Making the core more engaging: 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.
Competing on analytics: 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 analytics
3. The price you currently charge for your product
4. 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.

2
1 The cost to build your product without analytics
2 The cost of the analytics (platform, services, etc.)
3 The current price you charge for your product (without analytics)
4 The price your best competitor with analytics charges their users
Four key numbers will influence the price of your product with analytics.
Once you have these four numbers, arrange a pricing spectrum similar to this:
Price your data product along this range

Current Price of Best
Product Price Competitor
Danger Caution Caution Danger

Potential Pricing Zone
Zone Zone Zone Zone
Basic Plus Pro

Tier Tier Tier
Cost of Goods Cost of Goods Price Price Price
Sold — Sold —
WITHOUT WITH analytics
analytics
Plotting a pricing strategy is easier when you approach it visually.
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.

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.
Price your data product along this range
$150/user $200/user
Current Competitor’s
product price product price
$20/user
cost of analytics
Danger Caution Caution Danger

Potential Pricing Zone
Zone Zone Zone Zone
$165/user for $180/user for $200/user for

Basic Plus Pro
$100/user $120/user
Cost of Cost of
Product w/o Product w/
analytics analytics
The analytics pricing model in action.
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’t make analytics an option
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.
Fit analytics into the existing pricing model
If your analytics are part of a core product, offer them that way. Here are four common pricing models:

2 11. Price is a flat, recurring fee
22. Price is based on the amount of transactions performed
33. Price is per user
44. 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.

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.
BI Functionality
What companies spend
their time on...
Core Product
Manamgement
Provisioning
Operations
Marketing
Support
Change
What they forget...

Training
Billing
(until it’s too late)
Avoiding post-launch disaster is easy. All you have to do is plan.

2 Here’s the way we approach building the analytic product support system:
Gather Assign tasks Build Conduct Develop

your team & timeline processes walk-throughs control systems
Gather your team: 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.
Assign tasks & 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.

2
Build the processes: 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.
Conduct walk-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.

2
Develop control systems: 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.

2
Roles
• Receive request Account Executive
Step Sales Rep Order Entry
Manager
Help Desk
Management
Receive
Responsible Informed Informed Informed Accountable
request
Implement
Accountable Responsible Consulted Informed Informed
request
Perform Consulted Responsible Informed Informed

Accountable
training
Handle level Consulted Accountable Responsible Informed

Informed
1 issues
The R-A-C-I matrix makes it easy to fully think through business processes, reducing the number of surprises that occur.
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.

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:
11. 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”)?
22. Likeliness to occur: What’s the probability of this issue happening? Is it almost certain to occur
(10) or exceedingly unlikely (1)?
33. 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?
How Severe? How Likely to How Hard to Failure Score

Occur? Detect?
Potential Failure
(10 severe - 1 minor)
• Receive request
(10 High - 1 Low) (10 Hard - 1 Easy)
New customer instance fails

to provision via API call 10 9 6 540
SSO call fails and customer is

8 8 8 512
not properly authenticated
Winged monkeys attack the

data center 10 4 9 360
Support email is missed in

support system and trouble 9 10 3 270
goes unnoticed
A fully populated FMEA matrix.

2 Operational readiness
Don’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?

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.

2 OK! Now let’s talk about best practices for your analytic product launch.
Product
ready
learning from
learning period learning period learning period learning period operations
readiness
prep/drills Beta 1st 2nd 3rd new
customer tranche tranche tranche customers
rollout rollout rollout rollout onboard
A phased rollout is the safest, most effective plan.
Establish a beta period when “friendly” customers can evaluate the analytic application and
1 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.
2 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
3 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.
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.
Your mantra: 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!

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.

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.

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.

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.

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 interaction
they 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!

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
3
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.

4 Conclusion
You’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 different

10110100 Let’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.

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 The ability to embed analytic The know-how and experience
what you need today and functionality seamlessly within to avoid all of the mistakes
gives you options for the your application the first-time implementer may
future 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.

Cloud BI On-Premise BI
• Leave the management to Birst - • Keep your data and servers on

focus on your product your site and under your control
• Scales automatically with your data • Add storage as your product grows
• Includes 200GB of cloud storage • Contains all the features of Cloud
• Meets all key security features BI - no compromises

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.

Endnotes
1
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
3
See http://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/
4
Hooked: How to Build Habit-Forming Products, Nir Eyal, November 2014

About Birst
About Birst
Call toll free: (866) 940-1496 Birst is the global leader in Cloud BI and Analytics. The company helps organizations make thousands of
Birst is the global leader in Cloud BI and Analytics. The company helps organizations make thousands of
Email us: info@birst.com decisions better, every day, for every person. Birst’s patent-pending 2-tier data analytics and BI platform enables
decisions better, every day, for every person. Birst’s patent-pending 2-tier data analytics and BI platform enables
www.birst.com enterprises to create a trusted source of data, place it in the context of key business users and then enable
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.
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.
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.
Learn more at www.birst.com and join the conversation @birstbi.

Birst Beyond The Technical The Complete Guide To Embedded Analytic Products PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Birst Beyond The Technical The Complete Guide To Embedded Analytic Products PDF

Enviado por

Direitos autorais:

Formatos disponíveis

BEYOND THE TECHNICAL

The complete guide to designing, pricing,

The complete guide to designing, pricing,

Setting the course 14

Linking personas, missions, workflows 23

Create the offering 30

The launch plan 53

A tale of two analytic products 55

CHAPTER 3 - Where next? 60

The complete guide to designing, pricing,

How to use this Guide

BEYOND THE TECHNICAL

BEYOND THE TECHNICAL

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

BEYOND THE TECHNICAL

Here are the primary types of business intelligence:1

Types of Analytics Questions Answered

• Optimization • What’s the best that can happen?

• Predictive modeling/forecasting • What will happen next?

• Data exploration • Why did this happen?

• Alerts • What actions are needed?

The complete guide to designing, pricing,

The complete guide to designing, pricing,

• On-premise business intelligence: An analytic platform that is served from hardware

• Point solution: A business intelligence application that delivers one component of

The complete guide to designing, pricing,

The complete guide to designing, pricing,

First, your product’s analytic functionality shouldn’t be limited by the

A great analytic product also should be easy to maintain. You want to

Too often, product roadmaps get derailed as ever-increasing amounts

Great user experience

Today’s business users have high expectations when it comes to analytics.

A great analytic product keeps these requirements in mind. It anticipates

The complete guide to designing, pricing,

Support Process Development

Develop Marketing Support

BEYOND THE TECHNICAL

Align the team

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

BEYOND THE TECHNICAL

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

How do you work today? What are your pain points?

BEYOND THE TECHNICAL

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

BEYOND THE TECHNICAL

In this mode If you choose Instead of You get

Neutralize Best-in-class VS Good enough Wasted

The product workshop

BEYOND THE TECHNICAL

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 operations or customer support

BEYOND THE TECHNICAL

• Those who are not decision-makers

• People without a track record for successful implementation.

Chief Product Ofﬁcer Product Owner or Champion

Chief Technology Ofﬁcer

CFO or senior Finance representative

Head of Marketing User experience representative

Head of Customer Support

Project manager or project lead