Despite the wide spread adoption of BI and analytics in almost every department of organizations, software products are still being mainly driven by various interests and gut feelings of its several stakeholders rather by real data.
This session argues that the collection of software usage data has to be rooted in the software engineering department, creating a software product that is proactively designed to generate analytical data, instead of being treated as a reactive, sales driven BI project. We present a case study to support our thesis.
Target Audience: CTOs, Product Owners/Managers, Software Architects
Prerequisites: Basic project management experience
Despite the wide spread adoption of BI, big data and analytics in almost every department of organizations, software products still seem to be mainly driven by the various interests and gut feelings of its several stakeholders rather by real usage data. In an ideal world, every software vendor should be able to easily answer the following questions:
How many customers do we have and which products/editions do they use?
Which features are (not) used, how often?
Which product versions (builds) are (not) used?
How many customers
do we acquire/loose per month (churn)?
are direct/indirect (reseller acquisition)?
In reality, (part of) this information is usually either missing, or not updated or not in the required granularity. The lack of such information poses a significant risk for the viability of software solutions since it should be the cornerstone of strategic product development and backlog prioritization.
This session argues that the collection of this information has to be initiated in the software engineering department, creating a software product that is proactively designed to generate analytical data, instead of being treated as a reactive BI project driven by the sales/marketing department.
Additionally, we show that such information has cross-departmental effects helping e.g., QA and Support engineers, marketing departments, and sales representatives.
This session presents:
How the usage of software analysis APIs can revolutionize the way product development decisions are made
The pros/cons of designing a custom solution vs. using third party APIs
A case study supporting our arguments