3 Phases of Creating an Analytic Application

February 05, 2019
Ramya Babu's picture
Director of Data Product Management
Ramya is Director of Data Product Management at GoodData. Her team is responsible for leading the full end-to-end vision and technical development of analytic applications for GoodData customers. Ramya has 10+ years of experience that includes traditional consulting, product marketing, and product-centric roles in the tech industry. Ramya especially enjoys blending both her consulting and execution-focused experience leading customer requirements and design workshops in preparation for analytic application launches. Ramya is a Silicon Valley native and holds an MBA from Berkeley Haas.

As Director of Data Product Management at GoodData, I often talk to customers who are focused on getting to the all-important launch of a completed analytic application. And while embedding analytics and distributing them to their own customers is definitely important, how do you actually get to that point of launching that first use case? What steps do you have to go through to ensure that the analytic application you ultimately launch is the best, most useful application it can be?

In the GoodData Services team, we follow a three-phase approach to creating a successful analytic application:

  1. Define requirements and design
  2. Build
  3. Launch

Each of these phases is a critical part of getting you from having no analytics to a full-fledged analytic application that provides deep insights to impact business.

Step 1: Defining requirements and design

First things first, make sure that everyone involved in the development of an analytic application has a complete understanding of who the ultimate end user is. For some of our customers, that end user is their customer, while other customers’ end users are their own employees. In either case, everyone involved in the project needs to be on the same page regarding who these end users are and the business problems they are trying to solve or the processes they are trying to impact. What decisions are they trying to make when they interact with the analytic application? What are their pain points? The last thing you want to do is design something and put it out there only to find that no one derives any value from it. After all, our customers aren't getting any value if their end users aren't getting any value.

And while you’re identifying your end users, you should also be thinking about a beta group. A beta group is a group of users who will get early access to your application, be asked for feedback throughout the build phase, and be the first to see the application when it launches. After all, how nice would it be to be able to quickly pivot to a slightly different direction based on feedback during the build? When you’re thinking about your beta group, you should consider that they will be acting as representatives for your entire user base, so they should have similar wants and needs to those end users you identified earlier. In addition, while it’s an excellent opportunity for beta testers, it could also potentially be time-consuming so you’ll want to ask your most engaged users.

Finally, you need to think through whether or not you want to charge for this application. Perhaps the model that would work best for your company is to offer a free version with fewer features and a more robust version at an upcharge. You need to think about this during the requirements phase, because this will dictate how you progress through the build phase. If there are two versions of the application, a “freemium” version and a paid version, then the platform will need to be configured for this setup.

Step 2: Building an analytic application

Once everyone is on the same page regarding the end user and their needs, then it’s time to start designing the data model, data pipeline, out-of-the-box or custom data visualizations, and data transformations.

To build your analytic application, first take a look at your data. Is it really clean—meaning accurate, complete, and already in the correct format—and has no need for structural changes? Is it a bit of a mess, but you have the resources to change the data to a format that's appropriate for the analytics? Or do you know that you lack the resources to handle cleaning up the data—either in terms of employee resources or in terms of the expertise or time required to clean up data? Figuring this out ahead of time establishes the role that the vendor will play in building your data model.

Even if you hand off the build process to a vendor like GoodData, you still need to be heavily engaged in this phase. And why is that? Most companies seek out analytics because they want to do some sort of reporting or provide visualizations for the data. Consequently, your perspective and your data are integral to analytics and reporting. Without it, vendors like GoodData can’t build an effective analytic application that meets your needs.

And of course, throughout this process, you hopefully have your beta group providing constructive feedback. This might involve sharing their thoughts on certain aspects of the build, on features that might be included, the steps they are taking through the workflow to access the insights, or on capabilities that they wouldn’t find useful. Check in with your beta group frequently—no one wants to launch an application only to find out that it’s not valuable!

Step 3: Launching an analytic application

There are lots of ways to think about your launch strategy, but you always want to think about which group you’re going to launch to first. Typically, best practices state to launch to a subset of people, solicit feedback, iterate and tweak some features, then launch to the broader audience. That small subset could be your beta group, or maybe you’d prefer to launch to a specific segment of your entire user base first, like a vertical.

Part of the launch includes end user enablement. You’re not only giving people access to the application, but you want to make sure they know how to use it. Think through the training or enablement content you’ll need to provide your end users, especially those who may not be accustomed to working with analytics or analytic applications. Training material could include a series of webinars that explains where to log in, how to navigate, or where to get insights that will help answer questions. You can also create and send out a how-to guide to familiarize your users with the application.

After the launch, you should have a plan in place to answer questions from end users. Do you have an existing support team, and do they need to be trained on the application? Will you need to rely on the vendor’s support team? You’ll also need to figure out how those questions will get to the support team. Analytic platforms like GoodData’s are often white labeled and customizable, so within the application there may be support links and places where users can click to get help or send a note to a support team.

As you can see, there’s a lot that goes into creating an analytic application, and this is just the beginning! In a future blog post, I’ll dive into some of the common stumbling blocks that I see our customers encounter and recommendations for how to avoid those in your own process.