In a perfect world, every SaaS provider working on an embedded BI implementation would have ample time and resources to invest in the project: a dedicated team of developers and data experts, a UX/UI designer or two, business analysts ready to build your report library, a generous runway with time to spare…but we know this just isn’t the reality for most.
The majority of software vendors looking for an analytics boost need it fast because their IT teams are drowning in reporting requests and their sales teams are struggling to meet market demands. Some companies also have to contend with a long development cycle that limits them to just one or two major product releases per year, pushing them to implement quickly so as to make the next available window.
Striving for ambitious targets can overextend your development team unless you streamline the project accordingly. Figuring out how to pare down a BI implementation without compromising its value to customers can be challenging, so we’ve put together a list of strategies for fast-tracking your initial launch.
Strategies for Accelerating Your Initial Launch
- Evaluate using your ideal deployment team. This is crucial. Before you even decide on a BI solution, commit to having your would-be deployment team complete all evaluations. This way, when you settle on a vendor, the right people are already familiar with the product, in touch with vendor staff, and aware of discoveries made during the evaluation itself. Everyone is already up to speed, saving you time in deploying.
- Define your success metrics ahead of time. The most successful BI implementations are designed to meet predetermined goals. Without them, it’s difficult to gauge how your BI implementation is performing. Start by completing the following statement: We’re implementing embedded BI so that ______. Get as specific as you can when filling in that blank. For example, if your IT team is currently spending too much time fielding reporting requests from customers, perhaps the goal is to reduce that time by 75% in the year following the initial launch. To start, restrict yourself to just a few key goals that are easy to measure. As your BI implementation becomes more refined, you can add more goals and adjust your targets as needed.
- Pick the type of user or persona you’re going to prioritize. It’s hard to satisfy all users’ needs equally, particularly in an accelerated launch, so refer back to your success metric(s) for clarity on which users to prioritize. Investigate what types of reports are being requested (or those being run in your legacy solution). Determine who you primary users are. Then let reporting requirements and knowledge of your end users dictate what BI features are important for your initial implementation.
- Pick a final arbiter. You may want multiple stakeholders to weigh in on your BI implementation plans — visual integration, interaction design, data modeling, etc. — but not have time for prolonged debate. Prevent stalemates by picking a final arbiter ahead of time. You might have a few, each with veto power in a different domain. This helps keep the perfect from becoming the enemy of the good.
- Prep your data in stages. Got a lot of data? You don’t have to expose all of it to users all at once. Determine which tables are most essential to your initial launch and prepare those first.
- Refine your report library. If you’re transitioning from one BI solution to another, chances are you already have a substantial library of reports you’ll want to migrate. Cut down on your workload by culling the library down to the most essential reports. If you have report monitoring or auditing data, check to see if there are obsolete reports you can remove. It could also be helpful to check in with your users directly find out what reports they require. If you’re building a report library for the first time, strive to build stock reports that will satisfy 80% of use cases.
- Expose only a handful of features to a select group of users. If you can save resources by deploying a limited feature set initially, do so. Releasing to a limited number of customers may also save you time, depending on your customer demographics. For example, if your product is a CRM and the majority of your reporting requests come from your call center clients, you might prioritize reports specific to call centers and limit your first release to those customers.
- Do a simple visual integration that still satisfies user needs. You could make the entire BI solution accessible to users from the navigation bar, or you could expose a chart here, a dashboard there, creating a seamless experience. The latter requires some planning and additional development work, however, so if a bolt-on visual integration is the only one in the cards, make minor adjustments that will have the greatest impact. This might mean changing the BI application’s colors to match your brand, adjusting font, or adjusting a few terms to make language more consistent or clearer to your users.
The following scenarios illustrate how real companies have fast-tracked their initial BI launches.
Fee for Service
Company A operates on a long development cycle, and their next major release is only one month away. If they don’t add embedded BI to that release, it will be another year before their customers have access to the solution. They can’t afford to have IT building customer reports for another year, so they decide to use the two-month window to build a limited library of basic reports for which there is high demand. They will expose just those reports for the initial launch and charge a fee for ad hoc report requests. Next year’s release will expose self-service report building tools, completely eliminating IT’s involvement in customer reports.
Company B knows the majority of its users will have no use for advanced ad hoc reporting capabilities, so it accelerates its initial launch by exposing only a library of canned reports and a simple drag-and-drop report builder. Those users who want access to more sophisticated tools can upgrade their subscription plan. This system enables Company B to focus on a limited set of features for its initial launch, as it will take time for novice users to become proficient enough for the gated capabilities.
Careful consideration of your user base, business objectives, timelines, and resource capabilities will help your company select the right combination of fast-tracking strategies. We hope these suggestions and sample scenarios get you off to a strong start in your planning!