Joel Sooriah
Product and Tech Guy
9 posts
About this blog
Blogging helps me reflect on my day to day initiatives at work - product intitiatives, methodologies, interaction with cross functional teams, customers, management, and end users. Being quite fascinated by the human centered design element of things in an excessively digitalized world, I came to realise that most problems encountered by organisations, are ultimately a human problem - lack of alignment, team boundaries, communication, lack of empathy, ..., and the list can be long, ...very long. After some years of experience in the field, I found myself solving these problems, whenever I see teams struggling, I cannot help from finding ways to solve them. As a matter of fact, that's exactly how I transitioned from engineering to product management. Blogging helps me learn while I am writing - whenever I experience the desire to write on something that I believe should be shared to others, I run also some research to support my writings and learn along the way.
Building an agentic RAG tool to support my hobby research into the history of the French Revolution in the Indian Ocean
Academic research generates an enormous volume of PDF documents—papers, theses, archival materials, and historical analyses. Across the years, I found myself interested into the history of French revolution in the Indian Ocean. This history and its impact spans over decades across multiple locations like the Mascarene Islands, India, and of course, France and the UK as well. Given the huge amount of information that my brain needs to process to get a good understanding of all the intricacies happening on at that time, I have decided to build a RAG pipeline powered by graph databases to help me out. This is perfect for a RAG system based on graph representation of entities. This experiment addresses that challenge head-on, building a Retrieval-Augmented Generation (RAG) system that transforms raw research PDFs into an intelligent, queryable knowledge base augmented with relationship understanding through graph technology.
Don't go chasing waterfalls and turn the ship around
Historically, many organisations operated with a waterfall-like model where product managers or business analysts would create detailed specifications that engineers would implement. Engineering teams would receive “clearer guidance upfront” with regular check-ins to ensure alignment. This approach treats engineers primarily as implementers who translate requirements into code.
Gherkin Syntax - The Rosetta Stone of Cross-Functional Alignment
In 1799, French soldiers discovered a stone tablet in Egypt that changed our understanding of ancient civilizations. The Rosetta Stone contained the same decree written in three different scripts—hieroglyphics, Demotic, and ancient Greek. Because scholars could read Greek, they could finally decode hieroglyphics.Your product team needs a Rosetta Stone.Not to decode ancient languages, but to translate between the four dialects we identified in Part 1 - customer outcomes, product capabilities, engineering logic, and business metrics. You need a syntax that all four groups can read, write, and understand without losing meaning in translation.That syntax already exists. You've probably seen it in your engineering team's test suites. It's called Gherkin.
Root Cause Analysis In Product Management Learning The Hard Way
As tech people, we’re often eager to build. The excitement of creating something new, something that showcases our technical capabilities and vision, can be intoxicating. But sometimes, our rush to solution-building can blind us to the fundamental question that should drive every product decision:What problem are we really solving?
The Agent Memory Landscape - A PM Guide to Building Context-Aware AI Systems
AI agents, quite often, don’t remember. They are brilliant in the moment, terrible across moments. Every conversation is day one. Every interaction starts from zero ! That limitation—and the architectural challenge of solving it—has become close to fascination to me. LLMs and agents are nothing without memory and context. An agent that forgets is just an expensive API call. An agent that remembers becomes something closer to a very good friend or assistant ! The landscape of agent memory solutions has exploded in the past two years. For product managers building AI-native products, understanding this landscape isn't optional—it's foundational. Here's a map of the territory.
The Coordination Infrastructure of Small Talk in Remote Teams
Remote work hasn't just changed where we work - it's exposed how much of our coordination machinery was invisible. When teams went remote and small talk evaporated, what broke wasn't morale or "culture" in some fuzzy sense. It was the infrastructure for coordination itself. Small talk wasn't downtime between real work. It was the continuous background process that made everything else work - the ambient context sharing, the trust building, the calibration of shared understanding. Teams that lost it found collaboration got harder, not easier, even with all the productivity tools in the world.
The Evolution of UX in the Age of AI - From Interfaces to Intelligence
Users don’t fundamentally care about your interface — they care about what it helps them accomplish. Nobody opens Photoshop because they love its toolbar; they open it because they need to edit an image. The interface is just the mediator between intention and result. This realization brings us to a critical inflection point - What if our obsession with UI elements has been missing the bigger picture of UX — the holistic user experience? What if AI could help us transcend the limitations of traditional interfaces to focus directly on user outcomes?
The Pragmatist Roots of Agile - John Dewey's Philosophy and Modern Software Development
The Pragmatist Roots of Agile - John Dewey's Philosophy and Modern Software Development. When the seventeen software developers gathered at the Snowbird ski resort in Utah in 2001 to draft the Agile Manifesto, they were articulating principles that would revolutionize how teams build software. What they may not have realized is that they were echoing ideas first developed nearly a century earlier by American philosopher and educator John Dewey. The parallels between Dewey's pragmatist philosophy and agile software development reveal a deeper truth - both represent responses to rigid, theoretical approaches that fail to account for the messy, adaptive nature of real-world problem-solving.