I stopped us from building a BI product.
Product case studyRealpad~15 min
Realpad needed better reporting.
The obvious answer was to give customers more BI tooling.
I wasn't convinced we understood the problem yet.
01 / Context
Reporting was becoming a product problem.
Realpad is a ~€2M ARR B2B SaaS platform used by real-estate developers across complex sales, financial, legal and construction-linked workflows.
As customers relied on Realpad for more of their operations, they increasingly needed to understand and report on the data inside it.
REALPAD
The underlying system was complex before we even touched reporting.
02 / Hypothesis
"Let's give customers Metabase."
“Let's give customers Metabase.”
There was only one problem:
we hadn't established that customers wanted to become BI analysts.
Technical feasibility ≠ product validation
03 / Product call
Before building it, I pushed us back into discovery.
- Who actually needs reporting?
- What decisions are they trying to make?
- How do they solve this today?
- Do they really want self-service BI?
04 / Discovery
"Reporting" turned out to mean three different things.
SMB
Smaller customers
- Lives mostly inside Realpad
- Excel is familiar
- Little or no internal BI capacity
- Wants common questions answered quickly
Core need
“Give me the answer.”
MID-MARKET
Mid-market
- Multiple operational systems
- Some reporting capability
- Recurring custom requirements
- Wants flexibility without maintaining BI infrastructure
Core need
“Let me adapt the answer.”
ENTERPRISE
Enterprise
- Dedicated BI / data teams
- Realpad is one data source among many
- Existing Power BI / analytics stack
- Sophisticated permissions and integrations
Core need
“Give me the data.”
There wasn't one reporting problem.
So there couldn't be one reporting product.
05 / Insight
Customers didn't want BI. They wanted outcomes.
We assumedCustomers want to build reports
We learnedMost customers want answers
We assumedFlexibility creates value
We learnedFlexibility also creates complexity
We assumedOne reporting experience
We learnedDifferent analytics maturity
We assumedMore tooling
We learnedMore cognitive load
The right abstraction wasn't "a BI tool."
06 / Decision
Don't build BI. Build the layer around it.
STANDARD REPORTING
Common questions, opinionated defaults
CONFIGURABLE REPORTING
Additional flexibility where useful
DATA / ADVANCED
Support more sophisticated customer requirements
Metabase wasn't the product.
The product was deciding what reporting experience each customer actually needed.
07 / Delivery
Discovery changed what we built. Then we shipped it.
- Discovery
- Requirements
- Architecture
- Prototype
- Customer validation
- Embedded reporting
- Rollout
08 / Outcome
The best feature was the product we didn't build.
Avoided
Building and maintaining our own BI product
Reused
A mature analytics engine instead of recreating one
Standardised
Common reporting needs into reusable product capabilities
Preserved
Flexibility for customers with more advanced needs
[INSERT DEFENSIBLE METRIC / RESULT HERE]
09 / Reflection
The hard decision happened before the first ticket.
- Hypothesis
- Challenge
- Discovery
- Divergence
- Decision
- Delivery
Challenge the solution
Not the person proposing it.
Create evidence
When opinions are stronger than data.
Reduce complexity
Before handing anything to engineering.
My job wasn't to choose Metabase.
It was to make sure we were solving the right problem before committing the company to a solution.
Why I chose this case
Technical possibility is only the beginning.
The technology is obviously different at Valka.
The product problem is familiar.
REALPAD
"We can give everyone BI."
Should we?
AI / RESEARCH PRODUCTS
"The model can now do X."
Should X become a product?
I want to work exactly at that boundary.
Between what technology can do and what the business and user actually need.