<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
<channel>
    <title>Happy Apps</title>
    <description>Designing products and teams, the human centric way</description>
    <link>https://jsooriah.github.io/happyapps</link>
    <language>en-US</language>
    <lastBuildDate>Mon, 29 Jun 2026 16:23:17 +0000</lastBuildDate>
    <pubDate>Sun, 28 Jun 2026 15:22:08 +0000</pubDate>
    <ttl>250</ttl>
    <atom:link href="https://jsooriah.github.io/happyappsrss.xml" rel="self" type="application/rss+xml"/>

<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-bastien-scapin-ergonomic-criteria-a-practitioners-guide-to-a-method-that-outperforms-the-heuristics-you-already-know/</guid>
    <title><![CDATA[ The Bastien &amp; Scapin Ergonomic Criteria - A Practitioner&#39;s Guide to a Method That Outperforms the Heuristics You Already Know ]]></title>
    <description><![CDATA[ If you&#39;ve run a heuristic evaluation, you&#39;ve probably used Jakob Nielsen&#39;s 10 usability heuristics. They&#39;re fast, well-known, and good enough for a first pass. They&#39;re also not the only option — and in at least one direct comparison, not the better one. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-bastien-scapin-ergonomic-criteria-a-practitioners-guide-to-a-method-that-outperforms-the-heuristics-you-already-know/</link>
    <pubDate>Sun, 28 Jun 2026 15:22:08 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/closing-the-gap-between-automation-goals-and-customer-experience-goals/</guid>
    <title><![CDATA[ Closing the Gap Between Automation Goals and Customer Experience Goals ]]></title>
    <description><![CDATA[ Most organizations building chatbots or voice assistants frame their objectives around two goals - automation and customer experience. These goals are often treated as if they pull in opposite directions. Automation is associated with efficiency, cost reduction, and scale — qualities that read as cold and transactional. Customer experience, by contrast, is associated with warmth, empathy, and individual attention. The implicit assumption in many organizations is that you can optimize for one or the other, but not both at once. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/closing-the-gap-between-automation-goals-and-customer-experience-goals/</link>
    <pubDate>Fri, 19 Jun 2026 07:08:19 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/rag-in-content-moderation/</guid>
    <title><![CDATA[ RAG In Content Moderation ]]></title>
    <description><![CDATA[ Evaluating retrieval-augmented generation pipelines for AI content moderation, comparing domain-specific HateBERT embeddings against general-purpose BGE-M3 embeddings across retrieval quality, rule induction, and downstream classification. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/rag-in-content-moderation/</link>
    <pubDate>Wed, 17 Jun 2026 10:00:00 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/why-your-best-growth-opportunity-isnt-asking-for-anything/</guid>
    <title><![CDATA[ Why Your Best Growth Opportunity Isn&#39;t Asking for Anything ]]></title>
    <description><![CDATA[ Most roadmaps are built on a structurally flawed input - the customers who engage most actively in discovery are rarely the customers who represent the largest growth opportunity nor the one your organization need at a specific point in time. They are also potentially vocal, articulate, and easy to build a business case around. They are, more often than not, a minority of the addressable market — and the energy spent serving their sophistication is energy not spent on the segment that would actually move the revenue needle. This is the minority segment problem. It doesn&#39;t show up in your funnel metrics your NPS or your win/loss analysis. It shows up when a competitor enters with a simpler product captures a segment you never knew you were ignoring and grows faster than your roadmap can respond. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/why-your-best-growth-opportunity-isnt-asking-for-anything/</link>
    <pubDate>Fri, 05 Jun 2026 19:55:34 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/openspec-bringing-specification-driven-development-to-a-research-prototype/</guid>
    <title><![CDATA[ OpenSpec Bringing Specification-Driven Development to a Research Prototype ]]></title>
    <description><![CDATA[ Research prototypes have a particular failure mode - they work, and then they grow. What starts as a script to test an idea becomes a pipeline. The pipeline gains a frontend. The frontend gets tabs. New retrieval modes are added. A knowledge graph appears. An agent memory layer. Six months later, the codebase is genuinely complex — but the only documentation is the code itself, scattered comments, and whoever wrote it remembers most of what it does.This is exactly where the RAG assistant for historical research in the Indian Ocean found itself. Eight distinct subsystems — ingestion, chunking, embedding, retrieval, generation, knowledge graph, agent memory, evaluation — each with non-obvious constraints, silent failure modes and subtle interactions. No single file explained how they fit together or *why* certain decisions were made. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/openspec-bringing-specification-driven-development-to-a-research-prototype/</link>
    <pubDate>Sat, 18 Apr 2026 13:46:53 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/sdd-the-spec-as-a-new-social-contract/</guid>
    <title><![CDATA[ SDD - The Spec as a New Social Contract ]]></title>
    <description><![CDATA[ Spec-Driven Development — SDD — is, at its best, a proposed answer to this perennial failure of translation. But it is arriving in 2026 not as a project management reform but as an engineering methodology, carried into organisations on the back of agentic AI tools. And that origin shapes everything about its promise and its limits. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/sdd-the-spec-as-a-new-social-contract/</link>
    <pubDate>Wed, 08 Apr 2026 17:55:53 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/before-the-graph-on-the-necessity-of-ontology-design/</guid>
    <title><![CDATA[ Before the Graph On the Necessity of Ontology Design ]]></title>
    <description><![CDATA[ I have been dwelling into GraphRAG for a few weeks now, vibe coding in my spare time. I started vibe coding GRAPHOS — a Graph-based Research Assistant for Historical and Ontological Sources (I recently changed the project name to reflect the importance of ontologies in this piece of work) — I assumed the hard problem would be the ingestion pipeline. Parse the documents. Extract the entities. Build the graph. Let the system answer questions.I was wrong about where the hard problem was. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/before-the-graph-on-the-necessity-of-ontology-design/</link>
    <pubDate>Mon, 06 Apr 2026 08:00:00 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/from-feature-requests-to-customer-jobs-basecamps-root-cause-analysis-approach-to-product-strategy/</guid>
    <title><![CDATA[ From Feature Requests to Customer Jobs - Basecamp&#39;s Root Cause Analysis Approach to Product Strategy ]]></title>
    <description><![CDATA[ Product teams face a universal challenge, customers constantly request features, but building everything would create bloated, unfocused products. The traditional approach—either ignoring requests entirely or meticulously tracking them in spreadsheets—fails to extract the strategic intelligence buried within these requests. Basecamp&#39;s evolved methodology demonstrates how Jobs-to-be-Done interviewing transforms raw feature requests into customer-centric product strategy. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/from-feature-requests-to-customer-jobs-basecamps-root-cause-analysis-approach-to-product-strategy/</link>
    <pubDate>Sat, 31 Jan 2026 11:27:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/gherkin-syntax-the-rosetta-stone-of-cross-functional-alignment-jtbd-part-2/</guid>
    <title><![CDATA[ Gherkin Syntax - The Rosetta Stone of Cross-Functional Alignment ]]></title>
    <description><![CDATA[ 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&#39;ve probably seen it in your engineering team&#39;s test suites. It&#39;s called Gherkin. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/gherkin-syntax-the-rosetta-stone-of-cross-functional-alignment-jtbd-part-2/</link>
    <pubDate>Thu, 15 Jan 2026 14:57:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/building-an-agentic-rag-tool-to-support-my-hobby-research-into-the-history-of-the-french-revolution-in-the-indian-ocean/</guid>
    <title><![CDATA[ Building an agentic RAG tool to support my hobby research into the history of the French Revolution in the Indian Ocean ]]></title>
    <description><![CDATA[ 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. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/building-an-agentic-rag-tool-to-support-my-hobby-research-into-the-history-of-the-french-revolution-in-the-indian-ocean/</link>
    <pubDate>Wed, 14 Jan 2026 11:27:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/why-your-product-team-speaks-a-different-language-than-your-customers-jtbd-part-1/</guid>
    <title><![CDATA[ Why Your Product Team Speaks a Different Language Than Your customers ]]></title>
    <description><![CDATA[ Every product team has experienced this moment. You ship a feature you&#39;re certain customers need. The engineering was solid. The design was clean. The rollout was smooth. And then... crickets. Not because customers don&#39;t have the problem you&#39;re solving. They do. But because the way you understood their problem and the way they actually experience it exist in two completely different universes. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/why-your-product-team-speaks-a-different-language-than-your-customers-jtbd-part-1/</link>
    <pubDate>Mon, 12 Jan 2026 14:57:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-pragmatist-roots-of-agile-john-deweys-philosophy-and-modern-software-development/</guid>
    <title><![CDATA[ The Pragmatist Roots of Agile - John Dewey&#39;s Philosophy and Modern Software Development ]]></title>
    <description><![CDATA[ The Pragmatist Roots of Agile - John Dewey&#39;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&#39;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. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-pragmatist-roots-of-agile-john-deweys-philosophy-and-modern-software-development/</link>
    <pubDate>Fri, 12 Dec 2025 13:02:11 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-agent-memory-landscape/</guid>
    <title><![CDATA[ The Agent Memory Landscape - A PM Guide to Building Context-Aware AI Systems ]]></title>
    <description><![CDATA[ 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&#39;t optional—it&#39;s foundational. Here&#39;s a map of the territory. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-agent-memory-landscape/</link>
    <pubDate>Sun, 07 Dec 2025 13:32:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-silent-kitchen-what-sebastien-bras-reminds-us-about-building-products-and-teams/</guid>
    <title><![CDATA[ The Silent Kitchen - What Sébastien Bras Reminds Us About Building Products and Teams ]]></title>
    <description><![CDATA[ We&#39;ve all absorbed the mythology of the chaotic kitchen—the screaming, the clanging, the barely controlled chaos of a dinner rush. Gordon Ramsay has built an empire on it. &quot;Yes, chef!&quot; shouted at maximum volume. Pans slammed for emphasis. The kitchen as controlled explosion. The brigade system as military operation, with hierarchy enforced through decibels. This mythology is so pervasive that we accept it as the natural state of excellence under pressure. We assume that when stakes are high and standards are higher, chaos is not just inevitable but necessary—the very proof of seriousness, of commitment, of refusing to accept mediocrity. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-silent-kitchen-what-sebastien-bras-reminds-us-about-building-products-and-teams/</link>
    <pubDate>Thu, 13 Nov 2025 03:23:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/dont-go-chasing-waterfalls-and-turn-the-ship-around/</guid>
    <title><![CDATA[ Don&#39;t go chasing waterfalls and turn the ship around ]]></title>
    <description><![CDATA[ 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. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/dont-go-chasing-waterfalls-and-turn-the-ship-around/</link>
    <pubDate>Sat, 06 Sep 2025 11:27:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-coordination-infrastructure-of-small-talk-in-remote-teams/</guid>
    <title><![CDATA[ The Coordination Infrastructure of Small Talk in Remote Teams ]]></title>
    <description><![CDATA[ Remote work hasn&#39;t just changed where we work - it&#39;s exposed how much of our coordination machinery was invisible. When teams went remote and small talk evaporated, what broke wasn&#39;t morale or &quot;culture&quot; in some fuzzy sense. It was the infrastructure for coordination itself. Small talk wasn&#39;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. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-coordination-infrastructure-of-small-talk-in-remote-teams/</link>
    <pubDate>Sat, 06 Sep 2025 11:27:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/root-cause-analysis-in-product-management-learning-the-hard-way/</guid>
    <title><![CDATA[ Root Cause Analysis In Product Management Learning The Hard Way ]]></title>
    <description><![CDATA[ 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? ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/root-cause-analysis-in-product-management-learning-the-hard-way/</link>
    <pubDate>Thu, 29 May 2025 15:54:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/the-evolution-of-ux-in-the-age-of-ai-from-interfaces-to-intelligence/</guid>
    <title><![CDATA[ The Evolution of UX in the Age of AI - From Interfaces to Intelligence ]]></title>
    <description><![CDATA[ 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? ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/the-evolution-of-ux-in-the-age-of-ai-from-interfaces-to-intelligence/</link>
    <pubDate>Tue, 20 May 2025 14:57:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/about-this-blog/</guid>
    <title><![CDATA[ About this blog ]]></title>
    <description><![CDATA[ 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&#39;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. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/about-this-blog/</link>
    <pubDate>Sat, 19 Apr 2025 14:57:12 +0000</pubDate>
</item>
<item>
    <guid isPermaLink="true">https://jsooriah.github.io/happyapps/blog/posts/shift-from-product-thinking-to-customer-progress-thinking/</guid>
    <title><![CDATA[ Shift from product thinking to customer progress thinking ]]></title>
    <description><![CDATA[ Every product manager has sat through a roadmap prioritization meeting that devolves into chaos. Engineering wants to pay down technical debt. Sales wants features that will close their current deals. Customer success wants fixes for the loudest complaints. Leadership wants innovation that moves metrics. Everyone&#39;s arguing about what to build. Nobody&#39;s asking why any of it matters. This is the natural endpoint of product thinking —a mode of operating where the product itself becomes the center of gravity. Features become the unit of value. Roadmaps become lists of things to ship. Success becomes adoption metrics. Product thinking feels productive because there&#39;s always something to build, something to measure, something to optimize. But it&#39;s fundamentally disconnected from the reason products exist in the first place. This is what Jobs-to-be-Done forces you to confront, customers don&#39;t want your product. They want progress. Your product is just a means to that end. ]]></description>
    <link>https://jsooriah.github.io/happyapps/blog/posts/shift-from-product-thinking-to-customer-progress-thinking/</link>
    <pubDate>Tue, 18 Mar 2025 11:27:12 +0000</pubDate>
</item>

</channel>
</rss>
