Building an ESG Reporting Module: A Rollercoaster of Resilience, Revelations and Regulatory Curveball
Dive into the real, unfiltered story of building an ESG reporting SaaS platform!
When Your Customers Ask for Something “Simple”
Picture this: It’s 2024, your inbox is flooded with customer requests, and everyone wants the same thing – ESG reporting. “Can you help us with CSRD reporting?” they ask innocently, as if they’re ordering a latte. Little did we know that this “simple” request would send us down a regulatory rabbit hole that would make Alice’s Wonderland look like a peaceful Sunday stroll.
As a product professional in the ESG space, you’d think I’d be prepared for chaos. But nothing, and I mean NOTHING, could’ve prepared me for the beautiful mess that is ESG reporting frameworks. Spoiler alert: we built an entire reporting solution only to have the regulations pull a plot twist worthy of a Netflix thriller. But I’m getting ahead of myself.
Let me take you back to where it all began.
The “Oh, This Should Be Easy” Phase (It Wasn’t)
When the European Union announced CSRD (Corporate Sustainability Reporting Directive) and mandated ESRS (European Sustainability Reporting Standards) reporting, companies across Europe collectively panicked. And when your customers panic, they come running to you with hopeful eyes asking, “Can you solve this?”
Here’s the thing about being a SaaS company: we build products based on user needs. It’s supposed to be our superpower. Our customers needed ESRS reporting? Sure, we’ll build it! How hard could it be?
Cue the dramatic foreshadowing music.
The year was 2024 – the pre-advanced AI tools era (yes, I’m calling it that ironically). ChatGPT was still in its infancy, and we didn’t have fancy AI tools like NotebookLM to read 3,000 pages of regulatory documents and summarize them in bullet points. It was just us, Excel, coffee, and an unhealthy amount of determination.
Do check out my blog on: Building a Carbon Emissions Calculator: When Your Product Name Becomes Your Destiny
Research Phase: Down the ESRS Rabbit Hole
It was time to roll up our sleeves and get our hands dirty with ESRS framework!
Here’s what research looked like in the non-AI era:
Reading PDFs that were longer than most novels
Cross-referencing multiple regulatory documents that seemed to contradict each other
Having team meetings where everyone said “I think it means this,“ followed by “Actually, maybe not!“
Creating flowcharts that looked like abstract art
Questioning our life choices while trying to map materiality assessments
The ESRS framework isn’t just one document: oh no, that would be too simple. It’s a collection of standards covering everything from climate change (E1) to business conduct (G1). Each standard has disclosure requirements, data points, and enough cross-references to make your head spin.
But as they say, perseverance is the key! We created Excel-based models because that’s what Product Managers do when faced with impossible tasks: we break them down into spreadsheets and hope for the best.
Our approach was methodical:
Deconstruct each ESRS standard into disclosure requirements
Map data collection needs for each requirement
Design data structures that could accommodate the complexity
Build workflows that made sense (or at least tried to)
Pray that we understand the regulations correctly
The Framework Apocalypse: When One Just Isn’t Enough
Just when we thought we had ESRS figured out, we realized something terrifying: ESRS is NOT the only reporting framework in town.
Enter the cast of characters:
GRI (Global Reporting Initiative): The OG of sustainability reporting, been around forever
ISSB (International Sustainability Standards Board): The new kid on the block trying to standardize everything
BRSR (Business Responsibility and Sustainability Report): India’s answer to sustainability reporting
SASB (Sustainability Accounting Standards Board): Industry-specific standards, because why make things simple?
And guess what? Companies don’t just report on one framework. Oh no, that would make our lives too easy. Many companies need to report on MULTIPLE frameworks simultaneously because different stakeholders want different reports. And if they operate in multiple geographies, then they have to comply with the local regulatory mandates!
It’s like being asked to cook the same meal using five different recipes at the same time, each written in a different language, with contradictory instructions.
The Technical Translation Nightmare
Now, here’s where things get spicy. Converting regulatory frameworks into technical product requirements is like translating poetry into assembly code: something is ALWAYS lost in translation.
The Challenges We Faced (And Sometimes Still Do):
1. The “What Does This Even Mean?” Problem: Regulatory language is designed by lawyers and policymakers, not product designers. Terms like “materiality assessment” and “double materiality” sound straightforward until you try to build a UI for them. How do you create a user-friendly interface for something that takes three paragraphs to explain?
2. The Data Point Disaster: Each framework requires hundreds (sometimes thousands) of data points. ESRS alone has over 1,000+ disclosure requirements. Mapping these into database schemas while ensuring they remain auditable, traceable, and user-friendly? That’s like solving a Rubik’s cube blindfolded while riding a bicycle.
3. The Interoperability Headache: Different frameworks ask for similar information but in completely different formats. Climate emissions in GRI might be structured differently than in ISSB. We had to create mapping logic that could handle these nuances without making users enter the same data seventeen times.
4. The Dynamic Nature of Regulations Here’s a fun fact: regulations change. Mid-development, CONSTANTLY. We’d be building Feature A based on Version 1.0 of a standard, and boom – Version 1.1 drops with “minor” updates that require major architectural changes.
5. The Workflow Complexity: ESG reporting isn’t a solo sport. It involves multiple departments – sustainability teams, finance, HR, operations, legal. Building workflows that accommodate all these stakeholders while maintaining data integrity and audit trails? It’s like conducting an orchestra where every musician is in a different time zone.
6. The “Excel is NOT a Database” Realization: We started with Excel models, which worked great for prototyping. Converting those into a scalable SaaS solution? That’s where the real engineering challenges emerged. Suddenly, we’re dealing with data validation, version control, calculation engines, and ensuring everything runs smoothly for thousands of users simultaneously.
Features That Saved Our Sanity (And Our Users’)
While building the reporting module, we realized that just collecting data wasn’t enough. We needed to build a complete ecosystem:
Material Topics Selection
Not every company needs to report on everything. We built an intelligent material topics selection tool that helps companies identify which ESG topics are actually material to their business.
Workflow Engine
Because ESG reporting involves more stakeholders than a corporate town hall, we created workflows that could route data collection tasks, approvals, and reviews to the right people at the right time. No more “Hey, did you fill out that form?” emails at 4:59 PM on the submission deadline.
Analytics Dashboards
Numbers without context are just... numbers. Our dashboards turn mind-numbing data into visual insights that actually tell a story. Because if you’re going to collect 1,000 data points, you better be able to understand what they mean.
Multiple Reporting Formats
Different frameworks, different audiences, different formats. We built the flexibility to generate reports in various formats: from sleek PDF sustainability reports to data feeds for regulatory submissions.
The Plot Twist: The Omnibus Rule Bomb
Everything was going great. We had built a solid product, our customers were excited, we were ready to launch, and ESRS reporting was going to be our crown jewel.
And then... the European Union dropped the Omnibus rule.
TL;DR: CSRD reporting deadlines were postponed by 1-2 years for certain organizations.
Let that sink in. Our biggest differentiator, our USP, our ace card – postponed.
I won’t lie: there was a moment of panic. That moment might have lasted a few days. Okay, maybe a week. But then something clicked: we had built an ESG reporting platform, not just an ESRS reporting tool.
The Pivot: When Life Gives You Regulatory Delays...
This is where the story gets interesting (and where we learned our biggest lessons).
We didn’t give up. Instead, we looked at what we had built:
A robust data collection engine ✅
Workflow automation ✅
Multiple framework support (GRI, ISSB, BRSR, SASB) ✅
Analytics and dashboards ✅
Materiality Assessment capabilities ✅
We realized we weren’t dependent on ESRS alone. We had a multi-framework reporting solution!
The GTM Pivot
We shifted our go-to-market strategy:
Target Market Expansion: While ESRS was delayed, ISSB and GRI reporting were very much alive and kicking globally
Geography Diversification: BRSR was mandatory in India, SASB was big in the US: we weren’t limited to Europe anymore
Value Proposition Shift: From “ESRS compliance solution” to “Comprehensive ESG reporting platform”
And you know what? It worked. Companies still needed to report. The demand didn’t disappear; it just shifted.
The Learnings (Where I Get Philosophical)
Here’s what this crazy journey taught me:
1. Never Put All Your Eggs in One Regulatory Basket
Lesson learned the hard way: Building your entire product strategy around ONE regulatory requirement is like building a house on a single pillar. Sure, it might be a very strong pillar, but what happens when that pillar shifts? (Spoiler: Your house wobbles.)
What we should’ve done: From day one, we should’ve built for multiple frameworks simultaneously. Yes, it’s more complex, but it’s also more resilient.
2. Regulations Are Fluid (Like Really, Really Fluid)
The reality: Regulations change, deadlines shift, requirements evolve. This isn’t a bug; it’s a feature of the regulatory landscape. If you’re building in the ESG/compliance space, build flexibility into your architecture from the beginning.
Practical application: Create modular architectures where framework-specific logic can be updated without requiring a complete system overhaul. Future-you will be grateful.
3. Customer Needs vs. Regulatory Timelines
The insight: Just because a regulation is delayed doesn’t mean customer needs disappear. Companies were still preparing for ESRS, still working on their ESG strategies, still needing tools to manage their sustainability data.
The opportunity: Early adopters who start before mandates hit are actually your best customers: they’re genuinely committed, not just checking compliance boxes.
4. Build for the Problem, Not Just the Regulation
The mistake: We initially built an “ESRS reporting tool.” The fix: We should’ve built a “sustainability data management and reporting platform that supports ESRS (among others).”
See the difference? One locks you into a single use case; the other gives you room to grow.
5. Multi-Framework Architecture Is Non-Negotiable
If I could go back in time and tell our product team one thing, it would be: “Design for multiple frameworks from day one.” The overlaps between GRI, ESRS, ISSB, and SASB are significant. Smart data modeling can accommodate all of them without creating four separate products.
6. Stay Obsessively Close to Regulatory Developments
Create Google alerts, follow regulatory bodies on social media, join industry forums, attend webinars, basically become a regulation stalker (in a professional way). In the ESG space, being blindsided by regulatory changes can be fatal.
7. User Experience Trumps Regulatory Complexity
No matter how complex the regulation, your users shouldn’t need a law degree to use your product. Invest heavily in UX. Simplify, simplify, simplify. Add tooltips, help text, and wizards. If your grandmother couldn’t figure it out, redesign it.
8. The Importance of Being Product-Led vs. Regulation-Led
Regulation-led thinking: “ESRS requires X, so we’ll build X.”
Product-led thinking: “Our users need to manage sustainability data, generate reports, collaborate with teams, and demonstrate compliance. How do we solve that holistically?”
Guess which approach survives regulatory changes better?
9. Resilience > Perfection
We could’ve waited until every framework was perfectly implemented, every feature polished, every edge case handled. Instead, we launched with ESRS, then added GRI, then ISSB, then BRSR. Iterative development in the face of changing regulations beats perfectionism every time.
The Silver Lining (Yes, There Is One!)
Here’s the beautiful irony: The Omnibus rule delay, which felt like a disaster, actually made our product BETTER.
Why? Because it forced us to:
Think globally instead of regionally
Build for multiple use cases instead of one
Create a more flexible, scalable architecture
Develop deeper partnerships across different markets
Understand the ESG landscape more holistically
If ESRS had gone ahead as planned, we might’ve built a one-trick pony. Instead, we built a thoroughbred that can run multiple races.
The Meta Learning (Because I Can’t Help Myself)
If there’s ONE thing I want you to take away from this saga, it’s this:
Building products in highly regulated spaces is equal parts product management and chess. You need to think several moves ahead, anticipate changes, and always have a Plan B (and C, and D).
Also, sense of humor. You definitely need a sense of humor.
Final Thoughts
Building ESG reporting solutions has been one of the most challenging, frustrating, educational, and ultimately rewarding experiences of my product career. Would I do it again knowing what I know now?
Absolutely.
But I’d pack more coffee and definitely build for multiple frameworks from day one.
Until next time, stay curious, stay resilient, and remember – in the world of ESG regulations, the only constant is change. Might as well learn to enjoy the ride.
P.S. If you enjoyed this story, you might also like my post on building a Carbon Calculator (link) – where I dive into the technical challenges of converting emissions data into meaningful insights. It’s equally chaotic, equally educational.
P.P.S. Comments are open! Tell me your product horror stories, regulatory nightmares, or product pivot victories. Let’s commiserate and celebrate together.
P.P.P.S. If you found this useful, three ways to support this blog:
Share it with someone building or using products
Comment with your biggest product challenge
Subscribe to get the next post in your inbox
Let’s make products that don’t suck!
About Me
Hey! I’m Ekta, your Product Manager next door - bringing ideas to life! I am very very glad you are here! Welcome to my little world of everything product.
I am a seasoned product manager with a knack for problem-solving and analytical skills. I am passionate about building products from 0 to 1! I have a strong ability to translate complex requirements into products!
Three words that describe me: Problem Solver (Always one problem at a time), Meticulous (A little lesser than OCD), Adaptable (RMG? Climate-tech? Name an industry I can create stellar product solutions end-to-end).
Subscribe to follow the series:
Weekly posts on building AI-powered ESG products, product management in general, and lessons from shipping real tools.