The Ultimate Guide to Embedded Analytics: A Starter Kit for Embedded BI

Section 1: Preparing for success

1.1: Setting the vision, goals and objectives

Getting the vision right is the foundation of a successful embedded analytics software project

Once you define the vision, you can identify the best approach to use to create your module.

The most first question to answer is the build vs buy dilemma: Will you be building it yourself, or will you partner with a BI vendor that can meet the technology and commercial needs of your project?

Your goals and impact

The direction you choose has substantial consequences for your strategy and objectives.

Let’s consider an example where your competitor has launched a product that has amazing analytical capabilities their customers are loving and you’re now playing catch up in the market. You don’t want to be spending more resources than required on additional features that you don’t know if your customers are going to love - you know what works in the market and you just want to gain parity. This shapes your go-to-market trategy and determines what objectives you are trying to achieve by adopting and implementing embedded analytics into your software suite.

However, maybe you’ve spotted an opening in the market and believe you can add incredible value to your product by adding in analytical capabilities - this is where you can really choose what direction you want to go in and the amount of resources you want to spend investing in this exciting new set of capabilities.

Do you want better data visualization?

Do you want to leverage artificial ntelligence and automated analysis and monitoring?

Do you want to provide contextualized insights to users?

Or maybe all of the above?

Your strategy needs these considerations nswered prior

Making the case for embedded analytics

While BI professionals and product managers may identify that there is a need for embedded analytics, the identification of specific benefits and outcomes can be difficult to pinpoint.

As a product manager or enterprise leader, you need to be able to clearly articulate the rationale for investing in analytics solutions to gain executive buy-in. To sell the solution to the executive team, emphasis must be placed on the desired business outcomes (“why”) and the stakeholders being targeted (“for whom”). People in any business need a strong vision that clearly articulates the benefits and connects both emotionally and rationally to the stakeholders’ aspirations, ideally developed collaboratively with your product and sales stakeholders.

Product managers and enterprise leaders must also be able to articulate the positive outcomes that will come from embedding an analytics solution, and have that understood throughout the business. Embedding an analytics application can lead to several benefits, including:

• Increased market share
• Competitive differentiation
• Improved customer loyalty
• Better response times to customers’ requests for data or reports
• Risk mitigation by helping customers meet regulatory and compliance requirements

 Determine your budget and ROI

In making the business case, the initial nvestment and ongoing support costs (total cost of ownership) must be justifiable in terms of the expected return on investment (ROI).

Having a clear understanding of the budget required and your expected returns means that you can effectively communicate the outcomes expected. When considering your budget, ask the fundamentals:

1. Is your budget realistic in terms of the goals you have?

2. Does the return on your investment justify embarking on this project?

Be aware of all the costs associated with delivering this application. For example, some open source analytics solutions or charting libraries may look appealing on first glance, but once you add up the additional development time, the net gain may be very little, or indeed, negative.

Call out blockers and threats

• The challenges of delivering a BI and analytics solution are not only technical, they can also be organizational, political and social. To make progress with a new solution, any challenges that have
• Unresolved data quality issues may have inhibited uptake of analytics due to poor trust in the data. Data quality problems are also indicative of underlying business process failures that can be addressed to deliver further value.
• Scheduling of development resources may have caused conflict with the development team and/product managers
• There may have been insufficient time and resources allotted for experimentation and learning

Set your timeframe and project roadmap

A critical component of a successful project is having realistic timeframes. These help you stay focused on the end goal of getting your application to market. For the launch of your analytic app, consider dovetailing it with a major product release, or a user conference. These help drive your team to deliver quickly and efficiently. Make sure your team understands what they will get and when, and what impact it will have on them. Be sure to provide:

• Increased market share
• Competitive differentiation
• Improved customer loyalty
• Better response times to customers’ requests for data or reports
• Risk mitigation by helping customers meet regulatory and compliance requirements

Making the decision

It might seem daunting to have to consider which direction you want your product to take so early in the process, but there are a few mechanisms that you can use to determine the criteria when making your decision:

Client feedback: This should probably be the first place you start - are your customers interested in analytics? Will they benefit and get enough value from analytics solutions?

Competitor analysis: What are your competitors doing? There is no point adopting a differentiator strategy when some of your competitors already have a similar capability.

Industry analyst discussions: It’s the analyst’s job to understand the market - why not make use of their industry knowledge and insight to help shape the direction of your analytics?

Internal workshop: Your employees work with your product and customers every day. They will know more about the market and indeed, your product, than a lot of people outside of your organization can tell you. Why not ask the people most knowledgeable to form your plan?

Product positioning

You can offer your customers several options: embed a solution that is completely white-labeled (your customers have no idea that it is a third party product), graylabeled (it’s branded as your own but you do not hide the fact it is a third party tool), or you maintain the branding of the third party tool.

Each of these choices has their pros and cons. If you are looking to deliver best in class, then a white or gray label option is most likely your preferred route, as you want to make it clear that this is your product and create a competitive gap. If you choose to maintain the branding of the third party tool, then you may lose customer “stickiness” or attachment to your product, and customers may wonder, “why can’t we use any analytical tool for access to data?”

Section 1.2: Building a successful delivery team

Now, it’s time to put your team together.

Ensure you cover the full range of cross functional stakeholders with the relevant skills, responsibilities and authority needed to execute the project. If you are building a parity solution, you may need less of a core business team and more external support. If you’re building a competitive solution, you will likely need to build your team internally from the ground up.

Key considerations for building an embedded analytics team

When putting your team together you will need to consider the following areas:

1.  Building a cross functional team to bring in expertise from across the business
2. What level of BI skills you will need based upon the solution you wish to build
3. Understanding the skills gaps you have
4. Planning to fill the gaps and managing the availability of resources

Building a cross functional project team

To be successful with any deployment of analytics into your business, you will need a range of people and skills across the whole analytical application development life cycle. From sponsors who can champion your project to your quality assurance team, all are vital for your success.

Product sponsor or champion

The product sponsor is responsible for the overall direction of the project, ensuring it aligns with the company’s goals. This person should be a senior member of your organization whose day job will be affected by the success of the project. The product sponsor’s job isn’t over once the product is launched - they are responsible for the post launch activities and reviews.

Analytics project manager

Project managers are probably the most important role in the project team. They are responsible for making sure the project is delivered on time and on budget. They manage the relationships with a wide range of stakeholders, manage the resources and motivate the team.

Head of product development

The Head of Product Development will be heavily involved in this project, and as the development lead will understand what data is required for the analytical capabilities you desire and how it will integrate with the  overall product and help drive the development timeline.

Head of sales

The Head of Sales will be responsible for  selling the analytics to the intended target (customers, end-users, executives within the business), so they should be involved from the start. Ultimately the success of the project is  going to be determined by how much you can sell, either to existing customers or new, so it is key this person gets involved from the start and buys into the project.

Head of marketing

The Head of Marketing will be responsible for positioning the product and helping define the target audience (same as for sales). Clearly defined target audience/sand product positioning is critical to ensure product launch success. Your marketing team will be responsible for getting those ‘first eyes’ on your product and should be working hand in hand with your sales teams.

Analytic developers

The analytic developers are those people that are responsible for content creation. They will ensure your data is in a format for analytical use, as well as create the out of the box content for your users, such as reports and  dashboards, that they can use and build upon as they engage with their datasets.

Software developers

To successfully embed your analytical application, you will need your application developers to be significantly involved. They will be responsible for the integration development (whether through APIs, Javascript and other connectors_ to ensure that there is a seamless flow for your users from your core application into the BI module, whilst ensuring application and data security, as well as data compliance is maintained.

QA / testing

Your quality assurance and testing teams are a vital component of a successful go to market. They need to ensure that the integration you have developed is working seamlessly and also test the veracity of the content. They need to make sure that the numbers add up - that your reports and dashboards accurately reflect your
customers’ data.

Skills assessment

If you are a typical software developer, you may have an exceptional engineering team - but that does not necessarily mean you have the right mix of skills for embedding a world-class analytics solution into your software.

The essential BI skills needed

To deliver a successful BI project and embed analytics into your software, your team needs creativity, common sense and the resolve to simplify the process wherever possible, particularly in the brainstorming and initial data analysis phases. Projects can be ongoing (optimizing application performance) or short term (creating a specific set of reports for a user request). But surrounding it all is the problem of being effective. Where complex business decisions need to be made and plans put in place to carry the business forward, business acumen is crucial. Your BI team fulfills dual functions: one, as technology experts who can dive deep into data to produce the content required for your customers; and two, as communicators who understand the nature of the application you’re developing and can transform requirements to both a technical and non-technical audience. So, what are the key skills needed?

Integration and software development expertise

Embedding an application requires significant development effort. Your development team will need resources and time allocated to embedding your chosen solution,development expertise, QA and testing, and so on.. If you have a small development team and personnel who wear many hats, consider bringing in your analytics vendor or another third-party provider’s help to get up and running faster. You may even want to consider third-party services to implement and manage BI and analytic solutions on a full-time basis.

Business requirements and analytical insight

BI is also about soft skills. It’s no good being able to write a script to load millions of rows of data into a table if you don’t know what it will be used for. The BI expert will need to understand the purpose of the application in order to deliver that value through analytics. BI is about being able to talk to the technical as well as business
audiences in order to deliver value. Be sure to gain:

• A clear understanding of your customer’s business
• Where analytics in their application will add value
• The ability to synthesize the disparate needs across your user types
• The ability to prioritize the development of user specific content

Data preparation

Most BI tools connect to databases. Your BI developer needs to understand how this information is built, where the gaps in the data are, and how that information can be constructed in order to produce the content required for your customers. 

• Understand the available data within your application and whether it supports intended use.
• Understand the integrity of the data — is it complete, correct and timely?
• Build an online analytical processing, or multidimensional analysis capability

Understanding of best practice concepts

Gain knowledge of items like unique naming conventions on fields, putting limits on prompts and the use of metadata layers. Getting these right will have a significant impact on user adoption through correct design and future-proofing maintenance of the BI component of your application.

Familiarity with BI tools

If your BI team knows the application vendor you’ve partnered with or has experience with BI tools, it will put you on a far quicker path to success, as a partner can provide active guidance on a technical level to ensure each stage of the analytics adoption process goes according to plan.

Data analysis

You’ll need to have the skills in-house to combine an understanding of your customers’ needs and questions with an ability to interpret the data into intelligent insights that will benefit your customers. Great analysts can see the answers that nobody was expecting, or perhaps ask questions nobody was asking. This attention
to detail will reveal new ways to offer benefits to your customers as you expose new uses for the data.

Section 1.3: Filling the skill gaps

There are three ways that you can develop the skill sets you need quickly to be ready for analytics adoption. You can train your current developers in BI, hire in new permanent employees or bring in short term contractors. With each of these, there are pros and cons, as listed below.

Contracting in specialists

To build out your skills quickly, you can choose to bring in an external specialist/s.

The most important skill would be in core BI as indicated above, ensuring they have the analytical, database and BI product skills that your application requires.

Depending on the nature of your application and level of integration, you may require specialists in SSO (Single Sign-On), Web Services and API knowledge.

The key questions you need to ask:

1.  Do they know the product and technology components you are using?
2.  Do they have experience in embedded delivery?
3.  Do they understand the unique needs of software vendors versus enterprise?
4.  Do they understand the purpose of your application and the value it brings to
   your customer?

The benefits of bringing in external experts is the ability to short cut lengthy development cycles and build, technically the ‘best’ possible application. Specialists that are proficient in the products you are using will know the best methods to build and integrate those technical components. The time and associated cost it takes for
self help and potential re-work can quickly justify the use of external consultants to accelerate your go-to-market.

Your vendor can provide you with access to the skills you need directly or through their partner network.

Training the project team

Now is the important step of getting the project team trained on the analytics product, ensuring they are comfortable with the capabilities and it meets their requirements. The team should look at all aspects of the product from front-end, to technical and integration needs, pushing it to its limits.

It’s worth considering how you are going to train your project team in not only the product, but best practices in business intelligence including data visualization and dashboarding. Some more traditional developers can write great code, but may lack the expertise needed to build the business intelligence content to best practice
standards.

Hire the expertise

Sometimes the best option is to hire a seasoned BI professional to lead the development team. This person will be able to train existing staff, help recruit contractors to fill gaps and generally ensure that appropriate choices are made in every development phase of the project. Ultimately, you may choose a mix of the above.

Section 1.4: Design for your product/business audience

How much effort should you spend on design? This is largely driven by the purpose of your project - is it to achieve competitive differentiation versus competitive parity? Keep in mind that when aiming for parity you want to keep your costs down and get to market quickly.

Typography is the art and technique

Typography is the art and technique of arranging type to make written language legible, readable and appealing when displayed. The arrangement of type involves selecting typefaces, point size, line length, line-spacing (leading), letter-spacing (tracking), and adjusting the space within letters pairs (kerning).

A core consideration is that CURATED content is different for different personas. Not all your users will have the same needs.

A key question to ask yourself is who are you building this analytical application for? Who is the consumer of the dashboard? What are their information needs? What do they already know? What are their experiences and prejudices? You need to make sure you understand your audience thoroughly before you start using precious resources to develop your analytics application. That necessitates the building of audience personas.

Remember that every end user type is different and will have different needs and requirements. Your users could cover a wide range from senior executives to front line employees, customers to suppliers, and engineers to sales representatives—all will have different needs and requirements. They could be existing customers or
brand new users to your product. Each of these types of users will have unique needs that need to be addressed.

Creating personas for your embedded analytics project

The first step in understanding your audience is to create personas for each user type that will be using your analytical application. Think of all the different types of end-users that will be using the product - from senior executives to suppliers - and cover them all, then prioritize in order of who will get the most value from the product and how complex their requirements are.

To truly understand your users you need to build out your persona and detail their needs. Things to consider here include:

1. High level details, such as role and job title
2. Key characteristics, such as are they operational or strategic
3. Objectives, such as what are they trying to achieve that analytics will be able to help them
4.  Frustrations, such as what are the pain points the person encounters in their daily tasks that analytics is going to solve
5. Needs, such as reporting requirements- do they attend regular board meetings they could use analytics to help make decisions?

Top considerations and impact for your analytics audience

There are several areas of importance your team needs to identify and cater for to ensure your analytics implementation is effective, end-to-end. Here are a few of the factors to consider about your audience, and the implications for a dashboard design:

Determining your audience: 3 embedded analytics persona examples

Examples of how your personas might look like are shown below:

Executive users

Most executives are so busy that they just need answers at a glance to define

business strategy. Executives have little desire to learn how to build analytical results, but need information to define business strategy. They prefer the use of dashboards, models and simulations. Dashboards provide monitoring and early warnings of impending issues and may contain collaborative capabilities to enable users to share commentary about the data. From a high-level perspective, these users explore, in context, subsequent levels of detail. Data to support this use case typically is stored in a data warehouse or data mart. The types of measures usually are financial and aggregated performance indicators, and the data typically is updated less frequently (monthly) than for other dashboard types.

Line-of-business users

Line of business users need dashboards that give them what they need to perform their daily activities. These information consumers need reports with data from a variety of sources. They use self-service capabilities (e.g., reports, dashboards and scorecard visualizations) to track sales statistics and customer information. These are more interactive users for whom dashboards and scorecards often provide key insights into the fundamental issues that are needed to meet daily activities. The dashboards they use tend to be more departmentally focused and rely on more-detailed operational metrics that are updated more frequently (daily). They commonly use solutions that enable drilling through to transactional level details. One example is a sales dashboard that provides sales managers with real-time forecasts, sales representative activity and pipeline analyses, and the ability to drill down to individual CRM records.

Power users

These information producers have a good understanding of the technology and the business issues being analyzed. They actively and competently pursue analytic challenges and use more advanced analytical tools (e.g., online analytical processing [OLAP], ad hoc query and modeling) to better understand the causes for sales changes and customer experiences. Additionally, they use dashboards and scorecards as a publishing platform for their insights and analyzes to be consumed by others.

The data needs design, too

Make sure your dashboard design meshes completely with each person’s needs, and gets to the essence of the problem. Isolate the main issue: A sales dashboard may need to be about “How can we more effectively move leads through our pipeline?” A marketing dashboard may strive to answer: “How can we optimize our marketing investments?” Finding this core will give you the logic and argument for discarding extraneous information. Keep truly crucial information on the front page and suppress ancillary information.

The single most common mistake we see in dashboard design is treating all information as if it is equally important. Too often the criteria for including information in a dashboard is whether someone influential thought it might be interesting. We propose a more stringent yet simple requirement: Will the information drive productive action?

Below is a simple framework to help home in on the right performance metrics.

Data focus

You need to determine the scope of data you want to make available to each persona. The data scope encompasses four main areas, these are:

1. History: How far back do you go?
2. Granularity: How detailed do you get?
3. Immediacy: How close to real-time reporting is required?
4. Security: What access limits do you need to apply?

History

When planning your software application, it is critical to know how far back in time each end-user will need access to their data. For example, if your users want to be able to compare this year’s year-to-date numbers with last year’s year-to-date, then you will need to provide them with at least 24 month’s worth of history. Keep in mind storing larger sets of historical data can be costly, so be pragmatic when thinking about the needs of your end-user and/or customer personas.

Immediacy

Think about how close to real time your reporting has to be for a particular persona. Typically, executive end-users do not need access to real time information, however operational workers do. Finance people, for example, may need to send out reports that are up to the minute. Operationally focused users typically react
to the data presented to them in an analytical application. They use the data to do their jobs on a day-to-day basis. Operations need to react to a number, and once the associated task is completed see that number change. For example, if you view a day’s outstanding report, a finance person will want to send out reminder letters. Once done and captured in the core system, these changes should be reflected immediately in the reporting. For an executive on the other hand, because they are generally more interested in trends, real time data and the rapid fluctuations that they generally display is of far less value. Having said that, we all have a story of the executive that wants to drill to the detail of a single transaction on a whim.

Granularity

The level of granularity refers to how fine-grained your data needs to be. For example, in storing historical data do you need transaction level details, or can you roll up all the transactions for a daily total? If you can pre- aggregate data, you can reduce the total number of records and increase performance, thereby boosting user adoption. But other types of users may need specific product depth categories versus SKUs, or zip codes versus latitudinal and longitudinal coordinates. The downside of reducing the granularity is that you do lose flexibility in the analysis that you can do. If you have aggregated data, then that fine grained data is no longer available for reporting. If your users then ask for that level of detail it will be significantly harder to retrofit it back in. You can use a fast, analytical database such as Amazon Redshift to keep huge amounts of analytical data, but be aware of the additional expenses you may incur.

Security

Data security is a critical component of your analytical application. First, any data security that exists in your software needs to be seamlessly and automatically replicated in your analytics application. One of the big areas of value creation is the ability to benchmark one user against another. This could be at a customer level, at a
departmental level or a regional store to store comparison. In this instance, it would be necessary to have access to others’ data to show how your data compares to that of others. In this instance, you will want to provide standard security for granular data but open access for aggregated entities.

Yellowfin’s suggestion: Keep in mind that most dashboards must be refreshed all the time. Dashboards should be visible— complete with the latest data—to users every day. Less frequently updated dashboards can also be useful (say, if there are only weekly updates), as long as there is some means of interaction, perhaps a time slider, so users can see how the measures changed with time. Users need to understand that different metrics have different frequencies. For example, customer satisfaction data only refreshes every month, while other metrics like sales pipeline index may be updated each day

Section 1.5: Functionality

Once you have your personas defined and dashboard designed sketched, you can begin to consider features and functionality that are needed to meet the specific persona requirements.

It is easy to believe that all your end users want as much functionality as possible; however, this is not the case. Overwhelming certain business users with features that confuse them only leads to frustration and lower user adoption. Alternatively, providing too few features has a similar effect, in that it creates frustration with the
end users who wish to do more within the application.

The following diagram describes core BI functionality and the type of end users to whom it is most suited. Many users just want to scratch the surface, while others want to take advantage of advanced analytical functions.

Analytic interactivity

Be sure that your users can use data to make their own discoveries to improve the business. Let them filter views, drill down, and examine underlying data. Do they want to drill down by region or product? Let them, because they know what they need and want better than anyone. Put the data where users need it most so they can do their jobs better. Make it fun, engaging, and interactive. Let them compare data, export it,
set alerts, filter and drill down into it. It can become a rewarding experience playing, exploring, and gaining insights through data.

Consider the following types of interaction when planning the dashboards that your personas require:

Drill down / drill through: Ability to go from a summary metric or view to additional detail that provides more context and/or breakout of the information.

Filters: Allow users to define the scope of the data in the dashboard to reflect their needs. Filters can either be global (refining scope for the entire dashboard) or local (refining scope for a specific chart or metric or view).

Comparison: Ability to see two or more subsets of the data side-by-side. A line chart, for example, may let the user view two geographic regions as separate lines.

Alerts: Highlight information based on predefined criteria. The alert may be activated when a metric goes outside of a particular threshold. Export / print: Give users the ability to pull information out of a dashboard. Export to formats that let users do more with the data like Excel and CSV rather than PDF.

Section 2: Technical Execution

2.1: Selecting the right analytics platform

Once you have your project team together, the next step is to ensure you select the right analytical application to embed into your platform. This journey should be driven by your vision for your end solution. Should it be a basic chart library, or a fully embedded and seamless part of your application? Only you can answer those
questions, which necessitates the creation of criteria that can help you assess and determine the best solutions that fit your goals.

So, where do you start? Of course, features, functionality, and cost-benefits are universal factors to consider. Think about maturity and ability to deal with the big data deluge and scaling out as your customers demand more. Consider all of these in light of your unique business requirements. Well help you get started in the section below.

Identify and rank your selection criteria

Typically there are some challenges associated with selecting the right  analytical application to embed. These include:

The selection criteria: Traditional tool selection criteria include features, functionality and cost-benefit analysis, but leave out evaluation criteria such as analytic maturity, adoption and use of big data that can help a software vendor choose analytic solutions to reach its business goals.

Understanding the impact on your business goals: Most software vendors don’t understand where and when advanced analytics can impact their business goals, which makes it difficult to know when to introduce new solutions and easy to default to basic low-value query and reporting solutions.

Future proofing: Making sure it is going to match your requirements not just now but in the future. Flexibility in analytics platforms is key, you want to make sure your product roadmap is achievable with your new analytical capabilities.

Functional choices: It is fundamental that you can offer your customers the full functionality available in analytical products that suit their requirements. Collaborative BI, Location Intelligence, mobile BI, and dashboards are all functionalities that should be considered to ensure your customers are getting the best possible user experience. You want your focus to be on developing new features for your own product, it shouldn’t be on developing the analytical application to keep up with customer requirements.

Embedding: It’s vital that you know how your BI vendors will deliver embedded capabilities. You also need to know how you wish to embed analytics into your application to meet your product vision. Work with your stakeholders to understand the business value, costs and maintenance implications of available embedded
capabilities.

Ongoing relationships: Embedding an analytic product is not a simple throw away decision, it’s more of a marriage. Take your time to get to know the vendors you are working with. Determine if they have the right cultural fit with your organization for a long term partnership. Although it’s not easy to define, really evaluate the sales process, interact with the technical team and see just how responsive they are. If the sales cycle is slow and painful, then you can bet that is not going to improve when you need critical support.

Creating a vendor short list: The data analytics space is crowded and growing. Quickly determine if vendors meet your criteria based on their website, online videos, and support sites. Do introductory calls with the vendor and, if possible, with their customers. Conduct demonstrations with the vendors to find a handful that best meet your requirements.

Conducting a POC to select your product: The POC is a chance for you to really test the application you wish to use. A POC is not a full testing of a live deployment. Limit your POC to 1 or 2 products - and be prepared to quickly move on to another product if your first fails to meet your criteria

Cost is almost always one of the first big considerations. In your total cost of ownership analysis, look at:Licensing

• Initial and ongoing implementation
• Administration requirements (including time and resources)
• Development and maintenance
• Integration requirements and expenses

Work with your stakeholders to understand the business value, costs andmaintenance implications of available embedded capabilities.

2.2: Develop amazing content

Now’s the time to start thinking about how your dashboard looks and works. How will it be formatted and structured, how will it be designed, and how will it function to help users interact with information?

Having been through the previous step of understanding your audience and  developing personas to understand their needs, you will be able to create content that is relevant to them. Your goal here is to make sure the content you create (dashboard and reports) is sticky, so when users are in the application they want to
spend more time using it, which will increase adoption rates, and therefore drive their business forward based on information versus guesswork.

This data-driven transformation can help your customers achieve value from the BI product immediately, justifying the investment they made to acquire the solution. 

Great information design

Your content will provide the first and lasting impression of your analytic app for your end-users, so focus on great information design to ensure success. A few key elements to designing a great analytics application include:

1.  Data presented needs to be relevant (meaningful) and accurate (trustworthy), so end users trust the application.
2. The app design needs to be usable, intuitive and beautiful, so users are compelled to use and interact with it.
3. The app needs to be relevant and effective to the end user’s specific role.
4. The app design needs to encourage data exploration and discovery, so that mere workers become “heroes” in their own domains

If your application fails to address all of these needs your project will fail. Your users will not adopt your application, so the return on your investment will be significantly reduced.

The good news is that you should already be pretty well prepared for this step based on the persona work you have done above. You should have a good understanding of the features needed, the analytic interactivity required and the data that needs to be presented to your users. So now all you have to do is focus on the design and making it look awesome. How do you do that? Glad you asked!

Design guidelines

When it comes to dashboard design, simplicity is the key to success. Complicated interfaces do not belong in apps and software aimed at a general, non-technical audience. Try and reduce your design down to its core features. Design for the users you have, not the ones you want. This means building a UI that’s intuitive and easy to understand, even if it means sacrificing features. Put yourself in the shoes of an ordinary user and ask yourself what you want to see in an analytics interface

Preparing your data

First, get your data in a state that is appropriate for analytics. Transactional applications are not often optimized for reporting and analytic loads. Your users are going to want to have access to a much larger data set, and aggregated data over time. This may require you to build specific reporting tables or even develop a data warehouse to support this analytical load without having a negative impact on your core applications performance

Ensuring data quality

If you are transforming your data for an analytic workload then you want to ensure that you maintain a high degree of data quality. Dashboards and the charts they contain are only as good as the data they draw on. A lack of data quality is one of the key reasons that analytical projects fail. Do not fall into this trap. Test and retest your data source and the dashboards you build to ensure that the quality is accurate.

Next you will find some guidelines to getting started with great dashboard design. This is just a starting point, there are a ton of resources available to help you to build the very best analytic content for your users.

Layout and design suggestions

Next you will find some guidelines to getting started with great dashboard design. This is just a starting point, there are a ton of resources available from Yellowfin, such as our Dashboard Gallery, to help you to build the very best designed analytic content for your users.

Keep dashboard design simple. Lay out your dashboard so the most important information is on the left-hand side because that’s how most readers process information. Make sure related visualizations and comparisons are placed next to each other.

• Don’t go into dashboard overload, because it’s hard for humans to process lots  of information feeds at once. Users don’t need Boeing 747 cockpits; they just  need the four key flight instruments they need to fly the plane.
• Think of user interfaces as a way to travel from point A to B in the smoothest, shortest journey.
•  Use familiar chart formats so managers and executives can easily assimilate the data. • Keep charts simple. When it comes to charts, less is more. The aim should be to communicate the data with as little visual noise as possible.
• Don’t be afraid to go beyond this by using mashup capabilities to overlay measures, variance or status flags onto process models, building layouts, seating plans and so on. In fact, any representation that carries meaning in itself is a very powerful aid in making the data the dashboard delivers real to end users by transmitting context effectively.
• Although 3D chart effects may look “cool” they’re just unnecessary chart junk. Try not to put 3D effects on 2D charts (like bar charts) as it just makes it more difficult to compare the data pictured effectively.
• Dashboard designers have been falling over themselves to produce animated bubble charts. They add aesthetic gloss, but no value in the process of understanding the KPIs presented. You should only make extensive use of animation if it helps the user see trends or notice changes in data.
• Use different colors in the dashboard to draw attention to unique parts and use similar colors to tie two parts of a dashboard together. Generally, a complementary color scheme can drastically improve the appeal of your dashboard. A coherent color scheme draws the whole dashboard together and makes it look more professional. Effective use of color separates great user interfaces from good ones. From lists and forms to tabs on your interface, use color to convey status, importance, type, region, value, and other important characteristics about aspects of your application. Keep in mind that 6% of the population is color blind and cannot distinguish between red and green, so keep this in mind when designing your dashboards.
• Instead of relying solely on color when designing your dashboard, embrace the use of colors, shapes, lines, thicknesses, degrees of shading, and other treatments that leverage visual perception. The size of a circle can signify relative amount in sales or number of units sold,and the shading of that shape can inform another measure such as profit. 

2.3: Integration into your application

It’s important that your analytical components look like the rest of your application for that consistent experience across your platform. This process is referred to as white-label analytics.

As mentioned previously, you can embed a solution that is completely white labeled (your customers have no idea that it is a 3rd party product), gray labeled (it’s branded as your own but you do not really hide the fact that it is a 3rd party tool), or you maintain the branding of the 3rd party tool. With a consistent design across your platform, you will limit your users’ potential concerns around security, performance or support with using another product.

In a white labeled scenario, the underlying analytics platform provider is never revealed to the end user. All labeling, user messaging and error messaging is either suppressed or stripped of text mentioning the 3rd party providing analytics. The other option you have is to black-label, where the analytics platform is clearly disclosed to the end user (e.g. powered by Yellowfin).

You have a few options when considering how to integrate your analytics application into your platform - these include:

1. Tight integration: The most commonly used method, tight integration, allows you to embed the analytical application into your platform and achieve single sign on (SSO), giving you more consistency and security across your platform. This method would be most suitable when looking for a full suite of BI tools to integrate into your application.

2. Loose integration: You have an option to embed reports using JavaScript integration to display the analytics in your application. However, this often eans you won’t have access to other features in an analytic application such as collaborative features. This method would be most suitable for when you are looking to just display reports in your application.

3. No integration: Of course there is always the option of not integrating the analytic application into your platform. This means the analytic application and your platform will sit side by side and work independently. This might be suitable for platforms where it is simply not possible to integrate other applications, or if the value users will get from the analytics application will be higher if BI is a standalone product.

Integration considerations

When integrating your product with your analytical application, you may want to consider building integration across the platforms in the following areas:

Application and user interface integration: If you have chosen a tight integration, then ensuring your users can navigate to the analytic modules and back again is paramount. Your users will want a seamless experience from the look and feel of both applications. They should follow the same style guidelines and navigation structures. You could even embed analytics directly into your application via a web service integration that allows reports to be delivered into your application with maximum control of look and feel.

Single sign-on: No one wants to sign on to multiple applications, so you are going to have to develop a single sign on method into your analytic application.

User and security synchronization: Maintaining security across your applications is critical. A key component of this is user synchronization between your application and the BI platform.

You will want to ensure that the analytic application does not break your app’s data security, and allow users of the analytics module to gain access to data that they should not be able to see. This will also need to replicate any row level security you have in your app by linking users within the BI module to the data permissions they
have in your application.

Functional access: Not everyone is a power user, so functional access is a great way to ensure that users only have access to the right level of functionality that makes sense for their level of competence and responsibilities. Most BI applications have function based roles. While there may be a lot of options, you can simplify these and add the function choices into your own application. This simplifies the user management process and means that there is only a single area where user access is defined across both applications.

Multitenancy: If your application is a multi-tenant application, then you will need to consider how you will replicate your client base into your analytic application. Make sure that your platform supports the kind of multi-tenant set up that you have deployed for your own app. On-premise deployment: If you are deploying on-premise, you will want to consider bundling the analytical application as a silent installer into your own installation process. This way you can upgrade your users seamlessly and deliver packaged reports as part of the install.

Content lock down: You have developed this awesome content and do not want your users to edit it and break it. Have strategies for locking it down - so users can copy and change but not delete all your shipped content.

2.4: Prototype and beta testing

As you can tell from the previous steps, there is quite a lot involved in designing a great analytical application.

It’s unlikely you will get it right the first time - although that’s an awesome and achievable goal. The issue is that everyone has an opinion about design, so the best thing you can do is iterate through a cycle of prototypes, getting feedback from your customers (first) and stakeholders (second) every step of the way.

Use prototyping and beta testing to assess what went well and what didn’t, noting that you need to take into account all stakeholders objectives and success criteria, not just a single set of opinions such as engineering.ious steps - there is quite a lot involved in designing a great analytical application.

Beta testing for marketing

Beta testing is not just for technical validation. An assessment by marketing, including interviews with beta test customers, is valuable. Revisit the needs that your analytical content intended to meet. Engineering can learn a lot from customers. Do the dashboards still meet their needs? What were the surprising insights that customers learned from integrating analytics into their product? Once you’ve identified your most loyal customers for the beta test, don’t forget to capitalize on their positive experiences in your launch. They can fuel your success, with marketing, PR, analyst, social and other efforts.

Think of the beta testing for marketing in 3 parts:

Part 1 - Validation: This involves marketing validating the positioning and value proposition, as well as technical validation of your new product – does it deliver what its says in the tin? Use this part of the Beta phase to further refine your message, ensure you have your target audience right and validate from those you will ultimately use your product day in, day out – that is it living up the hype that your marketing team is creating.

Part 2 - Feedback: Revisit the needs that your analytical content intended to meet. Engineering can learn a lot from customers. Do the dashboards still meet their needs? What were the surprising insights that customers learned from integrated analytics in their product? Feed this vital information back into the productdevelopment team as well as your marketing effort.

Part 3 - Referenceability: Once you’ve identified your most loyal customers for the beta test, don’t forget to capitalize on their positive experiences. Capture all that feedback and look to use that as part of your launch materials. You can spend a truckload on varied marketing campaigns but the value of great customer references can prove priceless as you grow. They fuel your marketing, PR, social media and other efforts.

Section 3: Business activities

3.1: Getting the pricing right

Pricing is the key element to making any product launch successful, so it’s fundamental to spend some time on getting this step right before launching your product.

The main point for consideration here is to make it easy to buy. There is nothing worse than a confusing pricing model that takes hours for the customer to digest. Often, the buyer has to then present it internally when they don’t really understand the model in the first place.

Making analytics an option

You want as many of your customers to see this great new analytical application as possible, but what if you’ve priced it a little too high or positioned it slightly wrong and that is deterring your customers from choosing to add on the analytical application? Without seeing the analytics, they won’t see the value you can get and therefore are highly unlikely to choose it as an add-on.

There are many ways to introduce customers to the value of analytics. They could try them as an option for a fee, or get just a preview of analytics with more limited functionality. Analytics could be offered to one or a limited group of users as part of a selling package, with analytics spreading across the organization as people start to see the value.

Keep your pricing simple and your sales team will be more confident selling the product and your customers will be happy. The fundamental options you have include:

1. Modular pricing - extra surcharge for the analytics app
2. Base pricing - increase the base fee for your application and include analytics as part of the bundle - pro - it’s built in; con - price goes up
3. Free - do not charge for this and absorb the associated costs 
4. Functional split - charge multiple fees for each component of the analytics app: con - harder to sell
5. Data split - charge for data accessed - lower for operational, higher for strategic 
6. Content split - charge for content (e.g. executive dashboard versus ops dashboard)

Always consider the ongoing investment into building, maintaining and further developing your embedded analytics solution. And ensure you have a clear return on your investment mapped out, particularly if you’re planning to absorb the cost as part of your overall application. Do the potential sales of your core product offset the analytics investment? Be careful, by giving it away your organization may view analytics as a cost center and not a revenue line item and your CFO would be highly unlikely to commit funding for future development.

Existing pricing model

Consider what your existing pricing model is and use this for your new analytical application as well. Stick to your strengths and what your customers know and understand. For example, if your current pricing model is based on FTE, then you go and throw in a pricing model around server cores or data, you are only going to
confuse your sales team and more importantly your customers.

The key to the pricing model is that you don’t want to confuse your customers. Pricing differences can quickly become negotiating points that customers may try to exclude from the deal. You don’t want to give your customers an opportunity to opt out of the awesome analytical value your customers can achieve. Existing customers can achieve the same or even more value by integrating analytics into their applications as new customers. Harnessing big data to make informed decisions today is the advantage of winners over losers.

Monitoring usage

If you consider the tiers of product adoption, it is essential you can track usage and identify when a user has moved to the next level. With a user-based pricing model, this is a very simple process. When a user wants the functionality from the next level up, you  activate their permissions and adjust their billing accordingly.

Monitoring utilization also allows you to see how much the customer is using your  analytic application and gives you the ability to act on that information: Do they need more training to understand the power of the analytical application? Are they a power user that could be a good reference customer for others? Which dashboards are being used and which aren’t? Are similar customers getting value from features  they are not utilizing that would bring them more business value? This information would give you significant knowledge on how to help your customers make the most of your product.

Support services

Inevitably, no matter how much research you have done into understanding your audience and building the right content, there will be customers that need some level of customization and extra support. When it comes to lending support, you first need to understand who will be carrying out the work. If you don’t have the ability to do this yourselves, you want to make sure you have a business partner you can trust to execute these support services to your customers to keep them satisfied with your embedded solution.

Analytics product tiers

You may want to consider offering product tiers so users are not confused or overwhelmed with functionality they may never need or use. Plus, it creates the mindset that the user has bought the analytics package and they get everything that comes with it - upgrades, new features, etc.

Only consider this step if it is required for your business - there may be some instances where a product tier is not suitable, such as when your product direction is to make sure your customers can access all the functionality required, and that it compares favorably to competitor offerings.

If it is a requirement for your business, we recommend tiering would be based on users. Rather than pigeonholing users into tiers based on a company level, you could offer something like:

Beginner

Perhaps you have users that are just getting started with business analytics or just need to see daily sales numbers or reports. Their job roles do not require them to actively pursue analytic challenges and use advanced analytical tools. They are not interested in delving into the data and experimenting. In this case, you might offer them basic read-only dashboards and limited functionality. For instance, sales representatives may only want to see if they met their monthly sales quotas, or marketing may only want to see how many people clicked on a particular social media campaign.

Intermediate

Intermediate users may want read-only dashboards, but as they gain more confidence, they may want more functionality and the ability to begin experimenting with data on a limited basis, based on a predefined set of data governance rules and guidelines. They may want to see, for example, how satisfied customers are based
on a number of variables such as usage, support calls, repeat purchases, returns, and more.

Advanced

This tier would be for power users who have a good understanding of the technology and the business issues being analyzed. They actively pursue analytics challenges, execute ad hoc queries, and work to understand the underlying causes for sales changes, website trends, and the overall customer experience. Additionally, they use dashboards and scorecards as a publishing platform for their insights and analyzes to be consumed by others. People often move among these tiers based on their roles and their confidence levels. To keep them engaged, you need a means of gauging their usage patterns and tailoring their experience so that they can excel at their jobs.

3.2: Operational readiness

You’ll need to get your salesforce excited about this new product!

They will need full-on support from marketing communications, product marketing, sales management and any sales training staff, as well as representatives from sales management. Start this process early, and do it concurrently with the previous steps. Ask tough questions such as: Do you have the appropriate sales channels (direct  sales force and/or through a partner channel) for this new offering? Do your existing
channel partners and/or direct sales force have the necessary knowledge to sell the new product? If not, prepare to train them on an ongoing basis. A long series of  feature enhancements can lead to major product changes over time, so be sure your channel is ready.

Assess the current sales channels

As the functionality of your product changes or your product lines mature and expand, you need to reassess the capabilities of your sales channel to make sure that they have the appropriate skill set for the sale. This should be reviewed on a regular basis, but it is particularly important when a new product is launching. Most
launches, unless they are only bug fixes or very minor iterations, warrant at least some level of training — with more being required for more significant iterations or next-generation offerings. A complete re-evaluation of the channel is appropriate, if you are diversifying to a new product type or the product being launched is targeted at a completely new market. This frank assessment of channels is one of the most commonly  overlooked elements of product launch planning, which can lead to disappointment when the current sales channels “can’t (or won’t) sell” the new product.

Accessing sales capability

As your product changes, matures, and expands, you need to keep assessing your sales channel to make sure they have the knowledge and tools they need for the sale. This frank assessment of channels is one of the most commonly overlooked elements of product launch planning, which can lead to disappointment when the
current sales channels “can’t sell” the new product. Most launches, unless they are just bug fixes or very minor iterations, warrant some sales training. And you may need to completely reevaluate your channel if you are diversifying to a new product type or targeting a new market.

Prepare for sales training

In the current economic climate, organizations are focused on cost containment and buyers are frequently required to get CFO approval before making large expenditures. In these situations, the traditional feature/function review and competitive analysis of one technology over another may be lost on executives at
that level.

Today, providers must demonstrate how their products will solve a customer problem or help them increase business agility. Solution selling, the use of personas (a deeper form of customer segmentation that involves creating buyer profiles), and a solid grasp of the full portfolio’s value proposition are needed in addition to
the feature/function knowledge. This challenge becomes more complex when indirect channels are involved, because sales training for the channel is often done secondhand. Therefore, the materials must be self-contained and self-explanatory.

Whether you have a direct sales force, sell through the channel, or go to market with some combination of the two, you have to train those people selling your product to compete in this new market reality

Ensure sales support/technical (presales) and professional services readiness

Verify that the sales support, presales technical support teams, and professional services teams are thoroughly trained and ready for launch. If you run a beta program, this can provide valuable insight into the actual customer experience and the resolution of any issues. Also, confirm that evaluation/demo units are available (production units, not prototypes) and easily accessible for your pre-sales team (inc. channel) and prospects. This includes all demo programs, scripts and collateral to support their efforts.

Ensure operational readiness

Confirm that the infrastructure is in place to support your best-case scenarios for product uptake. Do you have a plan for responding to unexpectedly high demand? Are your systems (website, ordering, support, etc) robust enough to handle all possible scenarios? If you provide a SAAS product, do you have adequate staffing in both cloud services and support to handle any disruptions caused by bugs? Or do you have adequate backup and redundancy systems with your infrastructure provider? Are your service and support teams prepared with professional services offerings such as consulting, assessments or workshops, installation and maintenance? Make sure you deliver a successful product and an excellent customer experience.

Confirm that legal has signed off on all required elements

Confirm that the legal department has reviewed and signed off on all the necessary legal documents, such as warranty statements, contract templates, and licensing agreements, in preparation for launch. Verify that full reviews of all collateral materials and user documentation have been conducted in compliance with the legal
standards. Now, secure the go-ahead for launch.

3.3: Support readiness

Being able to support your combined product—your product and your newly embedded analytics capabilities—post-launch will be critical to the future success of the project.

Be prepared to offer a number of support options: assisted support, which typically includes speaking to an expert, and unassisted support where customers find the answer on their own through resources such as wikis and documentation.

Whether assisted or unassisted, have the content such as FAQs in place to explain the benefits and answer the questions customers may have about the combined solution. For example, support staff will need to know the BI vendor development cycles, inform the customer when patches will be available, and when to roll patches
into the existing application.

Types of support

The types of support you could offer your users, includes:

Assisted support: Where users talk to experts, either on the phone or through live chat. Be prepared that support queries are likely to be highest when the product is first launched.

Unassisted support: Through things such as Help sections on the website, how-to videos, product documentation or FAQs. The beauty of these resources is that they are available 24/7. Be sure that you have a seamless way to escalate support queries either to a higher level within the business, or even to the BI vendor themselves.

Be sure that you have a seamless way to escalate support queries either to a higher level within the business, or even to the BI vendor themselves.

Service Level Agreements (SLAs)

Any support queries have to be backed by a Service Level Agreement (SLA). Most customers will expect to have an SLA in place to ensure if things go wrong they have a commitment from the company to solve them within an acceptable time period.

Clear communication

Clearly define a process for how and how often you plan to communicate with your BI vendor. Invariably there will be reason to contact them about support issues that you will need to escalate and it’s important both parties understand the process for this.

Develop your training collateral

When training your new users on your analytical application, you should consider how to make it as easy as possible to generate widespread adoption of your analytical application. To do this, you need to make training on the product as easy as possible. What self training options are you able to provide your customers? Some of
the options you could consider include:

• Videos
• Product documentation
• Product wiki
• Training webinars
• Online training sessions
• FAQs
• Community forums

When training your customers, consider that 50% should be using the content you have built using your own data, and 50% should be on training the user how to build more content. By sticking to this ratio, you have a balance of training the user on content they can use immediately to provide quick value to the business, but also the ability to create valuable insights in the future.

It’s important to understand that some users will require more detailed training than others, and this will ensure the best possible use of resources.

3.4: Marketing readiness

Keep in mind that you are not selling just a BI tool. There are many to be had on the market. Instead, you are selling the synergy between your existing application and your newly implemented and natively embedded analytics capabilities. Without mindfulness of the importance of educating your users on the value of your new
tools, you cannot guarantee they will engage with or use the tool altogether, leading to loss of value and confidence in the product.

So sell based on the additional value you can provide on top of your existing platform. Highlight the tangible business benefits that come from infusing data analysis and data-driven insights into what you already deliver.

Value proposition

Detailing the value proposition for your platform that now includes an analytical application is an important, essential step to defining your marketing messaging. Getting the value proposition right at this stage ensures that sales activity, marketing content and demand generation will be more productive. Ensuring your messaging is aligned to your customer needs is vital, so your research on your personas is going to be crucial here.

Your biggest differentiator when defining your value proposition with embedded analytics, will be:

1. Integration of your product and the analytics solution.
2. Pre-built content that you provide ‘out of the box’.
3. Having a single vendor relationship with your analytics software provider

Marketing content

Have you created all the marketing material for your new product to be sufficiently branded? Do the sales team have all the material they need in their sales engagements? There is a wealth of marketing material to be considered:

• Product collateral: Data sheets detailing the new analytics capability and the benefits from using your new platform.
• Product logos: Branding your new analytical application can be beneficial to help market your new capabilities, but it can be seen as an add on to your existing platform. Consider the product integration points we discussed in step 5.
• Press releases: Get the message out about your new analytical application. This will be great for general brand awareness and detailing your value proposition.
• Whitepapers: A great way to educate your audience on the benefits of having analytical capabilities and also that you offer this new capability.
• Blogs/Videos/Infographics: Easily consumable content on your new analytical application, with relevant information for all stages of the buying cycle.
• Presentation materials: Templates for your sales team to use and position to your new customers in the sales cycle.

Campaigns

In order to build awareness and interest in your product, you will need to execute marketing activity across multiple channels to your target audience. Some of the campaigns you could consider are:

Event hosting: Hosting a launch event is a great way to let your customers or prospects know about your new product. This gives you invaluable face time with your customers and provides you with an engaged audience looking at your new analytical capabilities.

• If hosting an event is too expensive or not the right fit for your audience, you could host a webinar. Although you lose out on the face time, you still achieve the engaged audience looking at your new product.
• Always aim to Involve an existing customer - no one tells the story better than a peer.

Event sponsorship: This is a great way to reach your target audience that is outside your known universe. Sponsoring an industry related event will get great brand exposure to an audience that wants to be educated in your area.

• Choose your events wisely. There are many options and they are often a great expense.
• Website optimisation: Most buyers’ journeys begin with a Google search, so making sure you are “findable” will really help your lead generation and brand awareness efforts.
• Producing great content online that your target audience will love is the most important element to your SEO strategy.
• A blog can be a great place to start your online presence. It will help your SEO efforts and bring interesting content to your audience.

Social media: A great tool for helping to increase the awareness of your product, social media channels are becoming increasingly utilized by businesses to reach their target audience.

• Find the right channel for your audience - research which channels they use and
  focus on those channels.

PR campaign: Launching a PR campaign can create a wide reach of awareness of your product to an audience that is new to your business. Creating engaging content and customer stories will resonate with your audience the best.

• Engaging a PR agency will help your content reach the right places

Email marketing: Targeting your known universe with email marketing will help nurture them and keep your product front of mind until they are ready to engage with you.

• Creative, educational and personalized material for your marketing emails will result in better responses and more engagement. As with any marketing activity, it’s fundamental that you track and measure the performance of the campaigns so you can see which tactic is working. Measuring campaign effectiveness can be difficult because a prospect will often get multiple touches from different marketing activities before they proceed to a sale. Your marketing efforts are also likely to reach multiple influencers across a business. With the average buying committee at a mid-sized company at six, your marketing activity could have  nfluenced any of those key stakeholders. Managing this reporting is key to understanding the effectiveness of your campaigns and where you should be spending your marketing dollars.

The countdown: Having a countdown to the launch of your new product can build excitement and anticipation around the launch. You could introduce pre-launch webinars, and market the launch countdown. Involve your employees in all of these activities to build buzz and awareness that your product is going to fundamentally
change and improve to include data analysis capabilities that will genuinely benefit customers.

3.5: Sales Readiness

Your sales team is going to be fundamental to the success of this project. Making sure they are trained and have all the right material to sell the embedded analytical application is going to be crucial.

There is, of course, a bit of science to getting your sales pitch right. For example, did you  know that 40% of people respond better to information in visual format than when it’s written? 

The sales pitch

Delivering your value proposition in a format that is going to be compelling to your prospects is frequently the most challenging part. Often a sales presentation is the best chance you have to put across your value proposition and demonstrate why your analytical application is perfect for the prospect.

There are six essential elements to a successful sales pitch, which can be repurposed into various forms and can provide the basis for briefings to the media to help generate awareness of your new product.

1.  A stellar cover slide: Include some facts and beautiful images.
2. Your value proposition: Summarize the value you promise to deliver to prospects and why they should buy from you.
3. A powerful story: The most successful presentations are 65% stories - present your story and your team to humanize your company and increase likeability.
4. Detail your solution: Include benefits and examples making it quick and easy to understand.
5. Provide proofs: This is to answer the question - why should I believe you? Add testimonials, research data, compare products and provide extra benefits such as financial gains, increased marketing effectiveness, or demonstrated efficiencies.
6. A clear call-to-action (CTA): You need to compel the audience to take action. Tell them what to do next. Should they sign up for a free trial? Call your sales team

The demonstration

You will want to consider the process for new customers trying out the software. This is particularly relevant for analytical applications. Because of the pre-built content you have prepared, you can quickly demonstrate the value customers can achieve with your software.

The sales cycle

Defining a sales cycle will help your sales team understand when to introduce the new analytical application to your customers. This is linked back to your product direction and whether you will be targeting a new audience or existing user base.

If you are considering an indirect model and selling through a network of partners, you should consider how you are going to train your partners in the sales and marketing messaging that you have defined. They will be representing your company and their success will determine your success, so the more time you invest in your partners the more likely you are to accomplish your aim. Keep in mind that embedding analytics into your application, as with any new product, will fundamentally change your sales cycle and processes. Make sure your sales team is ready to accept the change and has the information they need. Get everything you need from your BI vendor, such as licensing requirements.

Ordering

When your team makes that sale, make sure they (that includes any channel partners) understand what happens next with the order and distribution process for your product. Does the order go to a central accounts team or are the sales teams also taking purchase orders and invoicing? If it’s the latter, make sure they understand the process, terms and conditions, and their options if issues arise. They have to be able to communicate all those things to your new customer.

Section 4: Launching your application

4.1: Launch strategy

The purpose of your product launch is to introduce your analytical offering to the market, and in most cases, “launch” is an apt term.

Products don’t exist in a vacuum, and neither do product launches. Before you can plan your product launch, you need to understand how this launch plan fits into the grand scheme of things. What will the timing be? What will the scale and style of the launch be? And how do these factors fit into the bigger picture?

With a project of this size and importance, organization and commitment are imperative. In this step, you will gather all the preliminary inputs you’ll need, clarify the broad-based goals for the launch, assess your sales channel in light of theseinputs and goals, and secure company wide commitment to the launch. This step
is the primary responsibility of the launch lead with input from management and various other departments. The end result will be a readiness matrix where you’ve cataloged all of your preliminary inputs and their current status, a clearly articulated statement regarding the timing and scale of the launch, and team-level and managerial-level sign-off affirming the company-wide commitment to the project.

It’s time to begin the planning process.

Define measurable launch goals and success metrics

from a marketing perspective, you should begin your launch planning by defining measurable launch goals and success metrics. These are important not only as tools to monitor and manage the launch process, but also as wider, post-launch feedback to help improve the “whole company” alignment to future launches. For example, a
late product launch resulting in a missed market opportunity is a commonly cited reason for launch failure, but if this is due to design changes or manufacturing delays, it might mask a very successful marketing launch.

Create launch plan

So far, you’ve done all your preplanning and preparation with the launch lead taking the most active role in the process. Now, however, we get to the heart of the matter — creating the actual launch plan. This step is the most involved and will actively involve all the launch team members as well as occasionally touching on peripheral departments. To avoid common product launch mistakes and ensure that you don’t perpetuate a history of mediocre product launches, aim to take a holistic approach to the process. Carefully explore what elements best suit the product and what each launch constituent truly needs, rather than simply crossing tasks off a traditional marketing checklist. You can expect this step to take three to six months, depending on the scale of the launch.

Planning the external launch

Now that we’ve established that the product is ready for launch, it’s time to do the detailed external launch planning. Often, this will run in parallel with building sales readiness. Make sure that you base the launch messaging on the final positioning, benefits and value proposition that were refined as a result of the final product specifications and beta trial feedback.

4.2: Launch timing

There are several possible strategic options available to you as a software vendor for the timing of your product launch. There will be multiple external and internal factors that will impact your final launch plan.

Start your launch process by setting launch goals. Some goals will be internally focused, such as launching on time, keeping to budget, and sales readiness, and others will be externally focused, such as customer awareness, media pickup and major conferences. But there are three main considerations that determine when you launch: the launch category, external considerations like the competitive market and climate, and internal considerations, which are any special circumstances surrounding your launch.

Market challenges

While it can be a difficult process to prioritize launch goals and identify the potential  impact of external market conditions, you have to understand your competitive environment so you can create the appropriate response from a timing perspective. Timing is more complex than simply having logistics ready when the product is ‘live’.
How will your new product impact the existing product you offer? Cash flow is king and you don’t want to have an adverse effect on your core revenue by getting the timing wrong or mismanaging your communication.

Strategic importance

All launches are not created equal. Some are more strategically important than others and therefore warrant more attention and activity. The strategic importance, complexity, and potential differentiation of the product being launched will dictate much of the style and tone. While it may make sense for some products to simply be launched whenever they’re ready (for example, a minor feature enhancement, that should not be the assumed position.

External considerations

There are external factors that come into play when launching. How does your release sit alongside the competition? Is this enhancement moving you ahead of the competition or just bringing you up to par? Or is this an architectural advancement that will leapfrog the competition? Perhaps it’s the result of a widely publicized acquisition. The size and scope of your launch will be affected by these considerations. 

Special circumstances

In addition to weighing up the external factors, you will need to consider, and adjust for, special circumstances. These include your competition preempting your launch (or just about to) with a similar product or feature of their own, your feature enhancement coming late to the market, or competition making a significant announcement that attracts media attention just as you launch. Timing your launch away from large market and competition announcements can make the difference between it being a success or failure.

So, what should you do?

Taking all of the above into consideration, and with the understanding that a few paragraphs from an embedded analytics guide cannot cover the permutations and combinations for your product circumstance, these are your strategic options:

• Launch when your product is ready
• Launch early to beat your competition
• Delay launch until the market is quiet
• Time your launch around a specific market event
• Launch in stages to gauge the market
• Soft launch with no fanfare

You may want to consider variations or combinations of these options to suit your particular circumstances. You could roll your launch out one geographical region at a time, or use different strategies in each region. Alternatively, try launching your product to a select market or audience initially, then expand its availability from
there.

4.3: Roll out strategy

The first step is to build a roll out timeline that details when key events, such as beta customer rollouts, wider customer rollouts and feedback zones will be taking place.

The best way to plan this timeline is to stage the roll out to give you time between stages to get feedback from your users and make any necessary changes to the product or process.

The beta rollout

During this rollout you are testing every aspect of the product launch you have considered so far. This includes feedback on the embedded analytical application such as:

• Does the pre-built content answer the right questions for the personas you researched? Is it all relevant? Do they need more?
• Does the user have a good experience between the core platform and analytical application?
• Did the user have sufficient training to use the platform?

The feedback should not just be on the analytical application, but also on the processes around it, such as the onboarding process, the training process or even the contract negotiation.

It’s important in your launch plan to schedule enough time to be able to make the changes required after feedback has been received from the users. Hopefully there won’t be many changes, but it’s better to plan for the worst.

Which customers should you pick for the beta release? You want to cover all bases here as you are testing for the full launch to all your customers. Therefore you should consider including both customers who are super users and will really push the technology to its limits, but also lighter users who do not have heavy analytical
needs. Getting both perspectives allows you to have a complete view and cover both bases when you launch to your whole customer base.

The number of customers in your beta launch should be kept low to give you more time to work with each customer, receive their feedback and work on correcting any changes required.

The phased general rollout

Having deployed to your beta customers and ensured that any challenges with either the product or process have been ironed out, the next step is to launch at scale to the rest of your customers with a phased approach. A recommended plan is to split the remaining customers into groups by region, product line or even randomly.

However, you will want to avoid grouping customers by size or revenue as the potential risk to your business of rolling out to these customers would be higher should anything go wrong. Another thing to consider is to avoid rolling out to an entire group of new customers who are unfamiliar with your product. This can be a challenge for the support team.

When you launch the product to these phased groups of customers, you’ll need to consider how you plan to contact them and let them know what to expect with the new analytical application. You should consider letting them know about the new functionality, how they will access this, what to do if there are problems, any expected downtime and the contract implications. This is an important process, so you will want to make sure the right person is nurturing the customer through this.

Launch metrics

Determining how you will know if your product launch was successful is crucial to understanding if the project was worthwhile. Setting up launch metrics prior to launching your product is an important step to ensure you can track progress and report back success. Tracking them daily and sharing this information with your internal stakeholders will help with business buying of the project.

Some launch metrics could include:

• Time to deploy to a new customer
• Number of customers using the new product
• Number of customer issues
• Customer usage, including whether they are using pre-existing content versus new content

Another option for your launch metrics is to set up alerts that pick up when one of these key performance indicators is not met to a suitable level. You can then determine a course of action should these metrics not be achieved. The benefit to setting up these alerts is that you can take action immediately when something has
gone badly wrong, rather than waiting for the post phased launch review. 

It is worth selecting a launch leader, who could be your project manager, who has control over the launch process and is in constant communication with all the teams involved. If there is one team that is not ready to launch, it is the launch leader’s job to communicate this with all the departments. Once all teams are happy to launch and the launch leader is comfortable, then it’s time.

Refine theme

In this stage you want to clarify and revise the business requirements and confirm the format type and distribution method of any analytic outputs. Resolve any issues with underlying data and prepare the solution environment for deployment.

• Assess business process impacts
• Gauge user participation
• Prepare prototypes - develop a working solution
• Refine information and presentation models
• Smoke-test developed models
• Remediate data quality

Deploy phase

The deployment phase is about implementing a working solution within the business process and preparing the environment for ongoing operations, management and governance.

• Apply business process updates
• Refine final data outputs
• Prepare operational documentation
• Release to production

4.4: Post-launch activities

You can all relax now the product has been launched right? Wrong! Now is the time to think about how you can continue improving your product and the processes you have put in place. Has the project achieved its targets? How can you carry on growing the offering? You can guarantee your competitors are not resting on their laurels and will always be looking to improve their analytical offering.

Gather and measure

Your launch plan is not complete without a comprehensive, post-launch evaluation of its processes and impact. After the launch, your team should be gathering all the results from your key performance indicators. These results may come from a variety of sources such as your marketing automation platform, website statistics, 
your sales CRM etc.

Review

You set a series of measurable How have you tracked against the goals you set out when you started this journey? Look at each result by function with key stakeholders. Your stakeholders may be from a combination of marketing, sales, operations, and development to ensure everyone is aware of what went right and not so right. Then, everyone can use that knowledge into version .01 of your next release.

Document and share

An important step that is often left to the last minute or not done at all is to wrap up the launch by documenting the lessons learned for future reference. Marketing team members change jobs periodically, and project managers rotate, so the next time your organization launches a product, there may be an entirely new team involved. Also, make sure those lessons learnt are available in a shared location (not locked in someone’s ‘sent’ folder).

The feedback loop

Feedback needs to be an ongoing theme before, during, and after any product launch. Not only does this deliver a better product, but it can also fuel your marketing and development activities.

Customer feedback for support

Continual customer feedback post launch is important to keep improving and making sure your users are happy. You want to ensure you’re setting up your processes and systems to capture as much feedback as possible and for your team to be as responsive as possible. Bugs happen - it’s software - but getting in front of
an issue, over-communicating, and inviting feedback is going to go a long way to customer advocacy in the long term.

Customer feedback for marketing

With your customers happy and using your product, there is a great opportunity to write customer stories detailing the value they have gained from using your analytical application. This is worth its weight in gold, not only for your marketing team to build solid collateral to form the basis of campaigns, but also for your sales
team when talking to prospects. They are then able to show other businesses the value they can achieve with your analytical application.

Feedback from your BI vendor

Having your product ‘live’ in the market enables you to report back to your BI vendor with customer feedback. You should have a strong relationship with your vendor and high levels of communication that allows you to have open discussions on how to progress your offering going forward. This may involve quick resolutions to bug fixes or even product enhancements that are rolled in off the back of your feedback.  

Case studies

Plexure

Several companies are benefiting from embedding Yellowfin BI and analytics into their applications. Yellowfin teamed up with implementation partner and delivery and hosting specialist, Touchstone to deliver a fully-managed cloud BI platform on Amazon Web Services (AWS) that could deliver better analytical performance for its customers.

Plexure’s customers needed the right analytical solution that could help them measure, iterate and refine their marketing activities, in order to keep their consumers highly engaged and continue to drive positive business results. They do this via Plexure Analytics, Plexure’s customer-built reporting solution which provides consumer behavior data presented as raw data feeds and curated insights. However, it found the limits of Plexure Analytics had been reached.

Yellowfin was easily embedded into the Plexure application, shared and exported outside the platform, and fully white-labeled within Plexure’s product suite to ensure a seamless customer experience that aligned with Plexure’s existing brand and user experience. Toustone was then engaged to host the Yellowfin solution
via Amazon Web Services (AWS), ensuring the delivery of flexibility, scalability and security Plexure required. Because it is browser-based, Yellowfin enables Plexure’s customers to access all the analysis and visualizations they need from any location they choose to work from.

“The partnership between Yellowfin and Toustone has allowed Plexure to accelerate the delivery of our new analytics capability,” said Mark Bailey, Head of Partnerships at Plexure. “As an organization whose success is based on data-driven decision making, the visualization capabilities Yellowfin provides are critical in assisting our customers to maximize the capability of our platform.

Learn more: Plexure unlocks class-leading analytics platform with Yellowfin and Toustone partnership

North Tees and Hartlepool NHS Foundation Trust

Yellowfin partnered with North Tees and Hartlepool NHS Foundation Trust to deliver a fully embedded, white-labeled analytics solution for hospital staff. The  Trust previously used spreadsheets and another competing analytics platform for dashboards and reporting, and wanted to alleviate many of the pain-points it previously experienced, such as time-consuming manual dashboards prone to user error, and a complex BI toolset only few staff knew how to use.

With a 3-year license, NHS North Tees and Hartlepool replicated spreadsheet dashboard data into Yellowfin and automated all their data flows, which they found seamless and helpful in creating smoother reporting for their departments. “Within the last year, we’ve started to push the boundaries of what we want to do with the
platform, and where we’ve come from is phenomenal. We communicate constantly with Yellowfin on what we need, and learn from each other,” said Keith Wheldon, Business Intelligence Manager at NHS North Tees and Hartlepool.

North Tees and Hartlepool NHS Foundation Trust has since significantly improved the flow of data throughout its hospitals for staff and visitors, and the availability of BI tools throughout the organization by leveraging Yellowfin’s automated, embedded and data storytelling capabilities.

“Before, BI was an absolute manual task, open to issues and errors; it wasn’t just time, either, but stress and frustration with the previous processes,” said Keith. “We’ve now reduced that and have a smooth system with Yellowfin, which does 90% of what we need to do for our reporting; our analysts just have to do the next 10%.
Everything is slicker, easier and less stressful.”

Learn more: North Tees and Hartlepool NHS Foundation Trust delivers real-time patient reporting with Yellowfin

Conclusion

So there you have it! All the steps you need to go from setting your objectives to launching your own analytical application. This is a huge opportunity for you. Not only can you add value to your product, you can deliver enormous value to your customers too. We hope you can learn from all the knowledge we’ve gained, as we have walked many other embedded partners through this process.

Adding analytics to your product that yields new performance insights, drives customer satisfaction, and increases your revenue is one of the most beneficial improvements you can make to your business. So, we want to help you do it right.

About Yellowfin

In today’s environment, your customers are demanding more. They want easy access to their data, dashboards and sophisticated analysis and reporting. Stay ahead of your competition by partnering with Yellowfin. Through our unique partner pricing model, no name branding strategy, and our simple integration process, Yellowfin allows you to meet your clients’ needs. Yellowfin makes it easy for you to create new revenue streams by seamlessly integrating Business Intelligence into your applications. With Yellowfin, you can painlessly extend the capabilities of your application and rapidly sell to your customers. Business Intelligence does not have to be complicated. Yellowfin is making it easy.

By embedding Yellowfin you can:

• Increase your revenue. Yellowfin is easy to sell to your customers and they will love you for it. We will tailor a licensing and pricing model to fit with your business model, reducing your risk and simplifying your sales proposition.
• Build your brand. Yellowfin integrates seamlessly into your application by adopting your look and feel. With Yellowfin you build customer loyalty to your product, not ours.
• Increase your speed to market. Our core competency is analytics. We will help you integrate Yellowfin into your application quickly and easily so you can start selling immediately.

Yellowfin’s partner engagement model is to work with you as a trusted partner to quickly bring your analytics solution to market and to continue to support you into the future. This means that we get actively involved in your go-to market strategy. Every partner is unique; however, the general approach and specific steps are similar for all embedded partners.

With hundreds of successful embedded partnerships, across all major regions and industries throughout the world, you can be assured Yellowfin has the knowledge and experience to get your integrated analytics solution market-ready.