Every product team has experienced this moment. You ship a feature you're certain customers need. The engineering was solid. The design was clean. The rollout was smooth. And then... crickets. Not because customers don't have the problem you'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.
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.
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.
We'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. "Yes, chef!" 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.
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.
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.
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?
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?
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.
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's arguing about what to build. Nobody'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's always something to build, something to measure, something to optimize. But it'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't want your product. They want progress. Your product is just a means to that end.
Every product team has experienced this moment. You ship a feature you're certain customers need. The engineering was solid. The design was clean. The rollout was smooth. And then... crickets. Not because customers don't have the problem you'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.
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.
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.
We'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. "Yes, chef!" 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.
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.
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.
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?
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?
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.
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's arguing about what to build. Nobody'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's always something to build, something to measure, something to optimize. But it'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't want your product. They want progress. Your product is just a means to that end.