When building a product, there is always a point where you want to do some kind of reporting on the information and display that to your customers.
There are 2 (kind of 3) schools of thought here.
- Build a reporting section where people can do what they want with the data
- Or do some kind of integration to a reporting suite like Tableau.
- Or the third option is to take an existing reporting library like Apex charts or jscharts and bake that into your product. For this example, I’m kind of assuming that is in essence option 1.
Here is how I think about it.
When should you build your own reports
- When you don’t want a user to leave the product for some reason (protecting retention maybe). This can be an important factor for a lot of teams. If any kind of leaving costs big dollars (say a gambling app) you might want to tread lightly here.
- When reports make up part of your wide moat of competitive advantage. There are lots of good examples of this, I would say DaisyDisk, a beautiful mac disk space tool that has incredible reports is a great example of this.
- When you have a traditional sales force. The reason I say this is that despite the effectiveness or usefulness of your reports, Reports in a sales pitch generally do really well. Sales teams love showing reports. There is a sense that reports = value. For a lot of customers, they are a proxy for extracting useful information. This isn’t true of everyone mind you, but I have noticed that sales teams will often complain when there isn’t enough reporting as their competitors.
- When the likelihood of a user being able to segment and filter the data is low. In a tool like Mixpanel for instance, it requires a good degree of familiarity to use, and be able to extract good reports. If users struggle with this, building your own reports allows you to simplify this way down so users can get what they need without feeling like they have to learn math. I fee like BaseCRM have done this really well. They took the most popular reports and just stopped there.
- When the visual design element consistency of your product is of importance.
When to do an integration
- When your small and don’t have the resources to dedicate. Sometimes it makes more sense to just plug into an existing application and call it a day.
- When the likelihood of 2 clients needing access to the same report (including filters) is very low. When you have an instance where every user needs a different report visualization, you will drown in feature requests. Like I mentioned in point 1, without resources to deal with this (or the cohones to say no) you might struggle with demand.
- When the technical acumen of the userbase is really high. A good example of this might be a product that interprets financial information on the stock market. The value of highly segmented reports matters more than the pain in the ass factor of doing an integration.