Recommendations for a Phased BI Rollout
Jul 9, 2019
One of the top challenges enterprises face in deploying business intelligence solutions is lack of resources. With other high-priority projects going on, it can be hard for teams to bring their ideal BI implementations to fruition on deadline. Something’s got to give, and sometimes that something is the deadline, but sometimes it’s the roadmap. As much as SaaS stakeholders might want all customers to have access to all features all at once, it sometimes just makes more sense to stage a gradual, phased rollout instead.
Not only does this approach require fewer resources and less time in the short-term, it often results in long-term savings as well. A gradual rollout typically involves releasing a beta version of the software to a select group of users and gathering feedback before preparing a more widely available version. Not only does this feedback help guide the product team, but it also becomes a source of testimonials, case studies, product reviews, and other promotional materials. As an added bonus, introducing new features and concepts bit by bit often results in higher user adoption as well.
A piecemeal release plan offers resource-strapped teams a way to go GA later without losing momentum.
Although slower, a piecemeal release plan offers resource-strapped teams a way to go GA later without losing momentum. It’s also a way to help ensure that what resources they do have aren’t wasted on development initiatives that fall flat upon deployment. While the beta as a concept is old news, its usefulness in major product updates and feature launches sometimes gets overlooked. When it comes to releasing an embedded BI beta as part of a SaaS application, we have some recommendations to consider for each stage of a phased rollout.
Stage 1: Implementation
SaaS providers looking to enhance their products with embedded analytics are often swamped with reporting requests from users. Their IT teams are spending too much time querying databases and appeasing customers to give adequate attention to their intended responsibilities. Keep this dynamic in mind as you plan your BI implementation roadmap. The sooner you relieve your team’s technologists of their reporting duties, the sooner they’ll be free to help with the BI deployment and other projects.
To this end, consider making a report library one of your initial priorities. Take stock of the most frequently requested reports and set about building those in the application. In Exago BI, users can easily interact with canned (ready-made) reports in HTML format — changing sorts, filters, styling, and even applying conditional formatting without having to learn new UI controls or know anything about report building. This means that you can use the beta test to revise and expand on the library but don’t have to spend resources training end users just yet. Some BI vendors may, like Exago, even assist you with report creation to further free up your technical resources during the initial rollout. If all goes well, you’ll be able to satisfy 80% of users with your first GA release, buying your team time (and bandwidth) to work on the next set of features.
Note, however, that clean, well-structured data is a prerequisite for an effective report library. It’s important that the data you release — even if it’s not all the data — be organized, reliable, approachable (well aliased), and secure. While leveraging a highly normalized database generally provides better performance, some amount of denormalization will make the data more accessible to end users. The more complex the data model, the more challenging it becomes for ad-hoc reporting users, so tempered denormalization in exposed data objects is usually a good idea. (To learn more about preparing data for reporting, check out An Introduction to ETL Data Transformations in our learning library.) Time spent making sure the right data is available and well prepared is time saved when it comes to report building and user experience/training. User trust in the solution is paramount to its success down the line, and that trust starts with the data itself.
Last but not least, consider offering limited access to a more ambitious feature in the beta, specifically for user testing purposes. Maybe you want select users to have report-writing capabilities, for example, so that they can help guide the next phase of your deployment; or maybe you want to see how some users like interacting with dashboards. The goal is to anticipate implementation questions that will be coming down the pike post-beta.
Stage 2: Beta
Give the beta release to customers that will gladly provide feedback, and make sure they know it’s a beta, as unrealistic expectations will skew user reviews.
How long you wait before moving on to the feedback stage will depend on user adoption, so consider setting up a monitoring system for tracking BI traffic. Keep your timeline in mind, but also give users a chance to get familiar with the new tools before soliciting feedback.
While the solution is in beta, you can either work on other projects, freeing you up for the next phase of your BI deployment, or you can work on BI tasks unlikely to be influenced by public response to the beta. Either way, use the downtime to get ahead.
Stage 3: Feedback
Work closely with your UX and/or user testing teams to gather feedback from beta users, referring back to the usability questions you posed during implementation. If possible, get a mixture of both observed and self-reported feedback, as the two formats are most powerful in tandem with one another. Probe for:
- Points of confusion or frustration
- Functionality users are requesting
- Unexpected feature behavior
- Unexpected user behavior
Use this feedback to prioritize your roadmap moving forward, and be sure to pass on any/all relevant insights to your embedded BI provider. Shore up existing functionality before adding new features. It can be tempting to spring for the most requested features first, but it’s important to first square those requests with your resources and timeline so as not to fall prey to feature creep. While directly satisfying user requests for features or system changes can give an immediate “win,” looking at the larger picture sometimes reveals the need for more general changes yielding greater benefits in the long term.
Remember that you may also have the option of soliciting your BI provider for feedback on your implementation. Exago’s Services team, for example, performs system integration and security audits in advance of GA releases to screen for concerns before the solution goes live.
Lastly, be sure to make beta users available to your marketing team as well so they can source testimonials, petition for product reviews, get quotes for future press releases, and author case studies. Keep all teams responsible for publicity up to date on your roadmap plans and united in their messaging.
Stage 4: GA
Whether you put out a second beta before releasing to your general audience is up to your discretion — some companies prefer an even more gradual rollout than we’re recommending here.
Regardless of when you go GA, you’ll want to think carefully about how you package your BI offering. Embedded analytics can be a powerful upselling tool if segmented properly. Many SaaS providers will make report libraries universally accessible but only give basic report authoring capabilities to those in the next pricing tier. As customer companies grow, they may then become interested in more advanced features, such as dashboard authoring or report scheduling, etc. Some providers may prefer to tier pricing on a user-by-user basis. For example, a basic plan might include unlimited professional accounts but only one analyst-level account with access to advanced controls.
One advantage of using a tiered packaging structure is that you can work on releasing the lower tiers first, satisfying the majority of customers before seeing to the minority. This works toward your goal of freeing up IT resources for future projects.
Ultimately, the finer points of this and any rollout plan will depend on your business’s unique needs and context. Consider what’s right for your company, and keep a gradual deployment plan in your back pocket as a possible plan of attack.