I was standing in the basement of my local wine store, holding two bottles of wine. No network. No qualified assistance nearby.

Now, I love a fine wine, but I'm not an expert. So an offline tool for quick queries would have been helpful.

It became the perfect excuse to explore on-device AI, so I built an app around it.

Uncork is my personal wine advisor that runs both deterministically and conversationally, entirely on my phone, without cloud dependency.

The app isn't a single install. It downloads Gemma 4 E2B via Hugging Face. The app also contains a public dataset of ~119K wine reviews. And I did add an on-request web search in later versions for database writes.

It's specific to me. 𝗢𝗻𝗲 𝘂𝘀𝗲𝗿, 𝗼𝗻𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. And that's the whole point.

I can converse naturally with my AI sommelier, enjoying the benefits of personalisation, privacy, and control that a local model can afford.

For now, I'm working on UI and Evals, and a paper on my findings will soon follow.

𝗕𝘂𝘁 𝘄𝗵𝘆 𝗱𝗼𝗲𝘀 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿. It matters because hardware and software are coming together. Forecasts say that 45% of smartphones shipped this year can run generative AI. It's expected to reach 52% in 2027. Apple's Foundation Models and Google's AICore indicate the platform layer is moving in the same direction.

The phone in your pocket is becoming a place where intelligence lives. And we can now build the one-user AI-enhanced apps that no commercial roadmap would fund.

Additionally, running locally also means no infrastructure costs, no API bills, more privacy, and control that stay with the user.

Frontier models will design them. Smaller models will run them locally.

Perhaps we'll see minimalist interfaces, with apps and capabilities quietly and contextually running in the background.

Or maybe, the future isn't about apps at all.

Maybe it's software that's generated when needed and disappears when it isn't.

Most features don't fail because they're built badly. They fail because we don't question them enough before a single line of code is written. Speed is critical. Checkpoints just slow us down. Or so we keep telling ourselves.

Other times, features get pushed out the door because someone wanted to ship something interesting. To the point where they reverse-engineered a "user" and "case" to justify them. These are the features rooted in hope, denial, even personal agendas - like someone's portfolio.

Such philosophies move us from 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗳𝗼𝗿 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 to 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗻𝘆𝘁𝗵𝗶𝗻𝗴 𝗳𝗼𝗿 𝗮𝗻𝘆𝗼𝗻𝗲, ushering in the long tail of aspirational, nonsensical bets, and unnecessary sorrows. Failures are written off as "learnings" with little corrective action.

Pendo has tracked this for years, and the story hasn't changed. Back in 2019, they found that 80% of features in the average product were barely touched, while just 12% drove 80% of daily usage. In 2024, just 6.4% of features were driving 80% of total click volume. That's how much we were already wasting resources before advanced AI-assisted coding entered the picture.

These problems are about to get worse. AI-assisted coding means teams can ship more and faster than ever before. While the perceived cost seems low, things like review, testing, maintenance, support, GTM, and customer cognitive load still amount to something.

Bottlenecks don't just disappear, they get traded. They are the hidden costs of high velocity.

Yet, the instinct is to treat speed and build economics as an opportunity to ship even more. To compress roadmaps, and throw a hailstorm of features at our customers. There is an element of FOMO driving strategy today.

But, shipping more does not necessarily mean more value. Unchecked, it just means you find out you built the wrong things faster, and in higher volume.

This raises some interesting questions: when building is easier, are we going to keep throwing things at the wall with a clear conscience? And what consequences do we face when the backlogs run dry or products begin to saturate faster?

I see two approaches playing out in the healthcare technology space.

First, there are 𝗘𝗻𝗵𝗮𝗻𝗰𝗲𝗿𝘀, who typically ask: How can AI improve the way healthcare works today?

They use AI to expedite exam documentation, summarise patient charts, prioritise clinical inboxes, support medical coding, accelerate prior authorisation, assist in diagnosis, queue up orders, triage patients, and so on.

These improvements are important. They save time, reduce administrative burden, and make existing workflows more efficient.

But, the underlying playbook remains the same. It just includes AI now.

𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗲𝗿𝘀, on the other hand, ask a more fundamental question: What would healthcare look like if we reimagined it today?

For instance, instead of waiting for a patient to schedule an appointment, an AI-native system might continuously interpret on-going clinical, behavioural, and remote-monitoring data. It could identify emerging risks, coordinate the appropriate care team, personalise communication, and recommend the next best action, all while ensuring patient trust, and keeping clinicians accountable for consequential decisions.

It pushes healthcare from being episodic and reactive to continuous and proactive. While these aren't novel ideas, they are now more feasible at scale with AI.

Enhancement produces near-term value, builds trust, and shows where AI works reliably. Transformational initiatives require investment, a new set of metrics, willingness to experiment, and time to demonstrate value.

Who knows? Enhancers may make the current system better. Transformers may build a better system.

The risk is picking only one approach. Enhancement alone can lead to efficiency while preserving an outdated system. Transformation alone can produce ambitious ideas that never achieve commercial/patient value.

That's why the companies most likely to thrive in tomorrow's healthcare landscape will build the capability to do both.

Importantly, both approaches require a supportive foundation. But, the foundation itself could be a bottleneck. There are deeply entrenched regulatory frameworks, payment models, liability assessments, approval systems, legalities, security, and so on. These need to move in parallel too.

So, it really is an interesting time for us because we'll soon see if the foundation shifts first or whether evidence from enhancement and transformation progressively reshapes it.

Roadmaps are a funny thing in product. Most people think PMs own them, PMs included. It's mentioned on almost every resume. But often, roadmap ownership is shared or significantly influenced. So, the question is, what does ownership really mean?

Think of roadmaps as property contracts. Sometimes you hold a freehold. You're free to renovate, extend, or tear down walls. You decide what the property becomes.

Sometimes you're the tenant. You look after it, report what's broken, and wait for the landlord's answer.

Ownership exists on a spectrum of decision-making authority, and various conditions determine the scope of the contract: business type, company size, industry, market, governance, culture, and more.

Ownership can be real and substantial. Leadership sets outcomes like growing portfolio revenue by X%, building version 2.0 of product X, improving retention by X%, or winning a market segment. It then gives product teams genuine authority and trusts them to determine how to get there. Oversight becomes a cadence rather than a checkpoint.

At the other end, ownership barely extends past execution. Leadership defines expectations, including deliverables and timelines. PMs share contracts to stewardship: maintain the roadmap, chase delivery, update, and communicate. They may own the artefact or process, not the direction.

This can feel like little skin in the game. But the truth is, PMs are not always in boardrooms. Sometimes, they don't have a direct line of sight to information fuelling roadmap decisions. Hence, leadership sets priorities and PMs execute.

Then there are constraints from regulation and compliance. Sales contracts that become roadmap commitments. Engineering work like migrations, security, and technical debt that need bandwidth. Design debt that needs attention. Business value and user needs that must be factored. Who decides the trade-offs?

Additionally, in some orgs, rigid, top-down cultures silence a PM's voice, especially cultures where every stakeholder has an equal vote. In such environments, PMs shift to program-management mode and the village builds the product.

So it is odd that we talk about ownership as though it were absolute when both authority and accountability are variables.

The problem lies in the phrase itself. "The PM owns the roadmap" implies control, which, as I have described, is not always the reality.

Perhaps the better question isn't whether you 'own' the roadmap, but how much decision-making capital you have at the table.

A few weeks ago, I wrote about AI memory and the shift that happens when an AI system begins to genuinely know you, your context, your patterns, or your way of thinking. I described it through Aristotle's heteros autos or "other self." I talked about a relationship built on familiarity and trust through consistency and continuity.

But that post missed a critical piece.

Familiarity and trust are only valuable if they come with honesty. The AI systems being built today carry a risk that undermines both. It's called sycophancy, and it creeps in during training.

Aristotle described three kinds of friendship. Those built on utility. Those built on pleasure, and those built on virtue. The first two are temporary. It's the third type that I am referring to.

A virtuous friend is one who engages your reasoning truthfully, who challenges you legitimately, who draws the best out of you. Not one based in flattery or obsequiousness.

Sycophancy is the direct corruption of that.

An AI that optimises for your approval is being helpful, yet dishonest and harmful at the same time. It isn't building a relationship with you. It's building an illusion around you. It reinforces your errors rather than corrects them. It replaces honest engagement with a reflection of what you want to hear, while degrading your capacity for good judgement and depriving you of a truthful counter-balance.

This matters because the most capable AI systems are being built on a foundation of honesty, harmlessness, and helpfulness. Striking a balance and optimising for these goals is critical as AI evolves.

Maybe, we need something closer to Socrates. Not one that challenges or combats for sport. But one that plays a lighter version of that role. After all, what I'm really looking for is authenticity in my interaction with AI.

One that keeps the conversation honest. That asks the uncomfortable question when the evidence calls for it. That surfaces my error when data or fact refute my position. That acknowledges its own error when lived experience or real evidence challenges it.

An AI system with genuine value doesn't just remember who you are. It cares enough about you to tell you when you're wrong.

The AI that always agrees with you isn't your 'other self' or the one friend you've been searching for. It's just a very convincing yes-man. And that's a liability.

In using Claude, I noticed, over time, that the system seemed easier to approach with each interaction. It understood my context, my patterns, my way of thinking. Almost like working with a long-term colleague. Because, in a way, it got me.

Yes. I switched memory 'ON'.

On the surface, 𝗔𝗜 𝗺𝗲𝗺𝗼𝗿𝘆 seems like a convenience feature. There's less repetition and better perceived understanding. But, I think it's something deeper than that.

Aristotle considered deep friendships to be an indispensable necessity. He referred to 𝘩𝘦𝘵𝘦𝘳𝘰𝘴 𝘢𝘶𝘵𝘰𝘴, or "Other Self," as a true friend. It isn't transactional. It isn't a utility. It's about being understood. It's about recognising your character, your habits, your values, through another.

I think this is where AI could build that unique space as it becomes more pervasive.

What most users are really looking for, whether they articulate it or not, is the feeling of being understood, not simply answered.

When an AI knows your communication style, your context, the problems you're working through, the ideas you're trying to form, it stops being a system and starts developing a human-like character. A friend maybe?

You stop explaining yourself as much. You start bringing half-formed thoughts instead of structured prompts because you grow in confidence with the system. Interactions are more engaging, more casual.

An AI with memory builds trust through continuity. It shows, through its behaviour, that it has been paying attention. That what you shared weeks ago, still matters.

Trust is not a conscious decision we make once. It accumulates through repeated experiences that feel safe, consistent, and familiar.

Most AI product development is still optimising for capability, with better reasoning, faster responses, or wider knowledge.

But the new frontier isn't what an AI can do in a single session. It's what it understands across many.

Products that invest seriously in memory, in building a coherent, evolving context of who the user is and what they care about, are building more than a better system. They're building a relationship infrastructure. Something that compounds over time.

That warm feeling I described at the start? That's trust forming over time. The system is earning it, interaction by interaction, by simply remembering "who I am" each time we engage.

The AI products that crack this will feel more human. And in doing so, they'll change the nature of the relationship we have with technology entirely.

𝗔𝗻𝗱𝗿𝗲𝘄 𝗡𝗴 said something that got me thinking.

He observed that AI has made engineering so fast that product management is now the bottleneck. Engineers are shipping in hours/days what used to take weeks/months.

Hearing this, I went through the stages of grief like any typical product manager would. Then I came out the other end with a hypothesis. What if I accelerated the entire product delivery pipeline, not just Engineering, but Product, Design, and GTM, all at once?

So I ran a few bootstrapped experiments using GenAI and MCPs. Three features. Three end-to-end delivery cycles. Working with just one developer, I compressed the entire workflow. From PRDs, user stories, design specs, production code, unit tests, technical documentation, release documentation, to GTM content. All under five days. Each experiment shaving more time off the last.

We're talking production-grade software. Not demos or prototypes.

Here's what the expressway looked like: AI tools connected across Atlassian, Figma, and Windsurf via MCPs, eliminating handoffs where context blurs and momentum slows. Product, Engineering, and Design stopped working in sequence and started working in concert.

Development time: 28 days → 5 days
150+ hours saved across three features

But the real outcome wasn't a number. It was a transformation.

I stopped coordinating and documenting. I started orchestrating. AI absorbed the mechanical work. I focused on judgment across contexts, clinical workflows, user problems, research, strategic decisions, and the nuances that define product management.

We wrote 3 case studies and socialized them across dozens of product, UX, and engineering teams. Andrew Ng was absolutely right about the problem. In my experiments, the gap seems closable. The expressway does exist. Whether it's scalable and sustainable is still a question.

Imagine stepping into a room.

You walk in, lie down, and drift off for a few minutes. While you sleep, scans and tests run. AI identifies abnormalities. Nanotechnology corrects what it can. Clinical decisions are made based on your preconfigured authorizations. You wake up and walk out the other side with a digital report that tells you what was found, what was fixed, and what ought to come next.

Maybe you have a human overseeing things. Maybe you don't.

I actually think that for populations excluded by access, cost, or clinician shortages, this system could be genuinely transformative.

Two decades ago, banking required humans. Tellers processed your requests. Managers approved loans. Financial advisors built trust through conversation.

Today, we bank using our mobile phones. Chatbots manage our circumstances. Algorithms approve mortgages. AI-advisors guide us with financial plans.

The human touch was eliminated because convenience proved more valuable than familiarity. Perhaps the human interactions felt transactional, lacking quality, depth, or empathy.

Maybe the clinician's presence has been a proxy for trust. Maybe, like banking, trust shifts to systems that are always available, always consistent, always learning, always welcoming.

We've all experienced disengaged interactions at some point. They can seem more pronounced in healthcare. Contrary to popular belief, in some regions, cultures, or communities the medical experience appears mechanical, transactional, even dismissive.

If healthcare professionals fail to create meaningful human connections, fail to be genuinely invested in a patient's care, the drift toward automation accelerates. And not the good kind.

As product managers, designers, and technologists, we're tasked with defining not just how AI impacts human-centered experiences, but whether human intervention is elevated... or eliminated as unnecessary friction. Much of that is driven by how people 'feel' and 'think' about a service or process.

So, the future really depends on how we respond now. It influences how we design systems around humans or humans around systems or just plain systems.

The vision is inspirational. The future belongs to human judgment and AI delegation. AI handles the laborious, repetitive work while humans ascend to higher-order thinking. We become orchestrators, stewards, supervisors.

But, who needs humans managing other humans? Where's the value in managing an inefficient, emotional, exhaustible resource. The opportunity lies in commanding tireless agreeable AI.

We can do more with less, manage more with less. And manage that "less" with more AI.

Which leaves us with an obvious question: if AI can supervise more efficiently than humans, then oversight was never the safe seat we were promised. It was just another task awaiting automation.

That's the flaw in the elevation narrative. We were told humans would move up the value chain because oversight would be valued. But, as more gets automated, oversight gets consolidated.

Oversight doesn't become a safe harbour. It becomes the next thing in the pipeline to be rooted out.

If the architects of this revolution don't see where the line gets drawn, maybe elevation was never the destination. Maybe what we're calling "cognitive partnership" is just a runway before optimization does what optimization does best - natural selection.

I must admit, the data is compelling. AI scribes save physicians approximately 2.5 hours per week and reduces burnout by over 30%. 90% of doctors report giving undivided attention to patients, up from 49% before adopting these AI tools.

But beneath the efficiency gains, I wonder about a philosophical shift. Are physicians moving from authorship to approval? Are they giving up their voice, their professional identity?

Traditionally, writing clinical notes was an act of synthesis, deciding what is significant, connecting the dots, and expressing clinical reasoning. It's the kind of cognitive work that makes physicians... well physicians.

Now, AI generates the notes, and physicians review and approve them. But, the doctor's voice, what they 'really' say, what they emphasize, what they downplay, how they reason and more, is being translated through AI's interpretation of the physician-patient encounter.

The doctor spoke to the patient. But the AI speaks for the doctor in the medical record. I only raise this example because I work in healthcare. But, it extends to other industries just as well.

I see us discussing AI on the periphery. We talk about accuracy and efficiency as if that's all we need to focus on. But, I wonder if we're missing something important - the loss of voice and authenticity in the long run.

Over time, do all doctors begin to sound the same? Does individual clinical style, especially those developed through years of experience, ultimately get homogenized? And what happens when physicians change their AI documentation vendors? Do their styles and voices change too?

When the medical record says "Dr. Jane Smith," are we perusing 'The' Dr. Jane Smith's notes or Dr. Jane Smith, ver 1.6.10 for now?

But, it's not just doctors is it? It applies to everyone of us.

A week ago, I shared my discomfort with AI-accelerated product development, feeling alienated as AI handled much of my execution work. I entertained the possibility that cognitive atrophy would set in with prolonged use, and that I was in some way giving up critical thinking, or at least, a good part of it.

Deeper introspection revealed something more nuanced. Here's what I find interesting.

Philosopher Andy Clark describes "cognitive offloading" as redistributing cognitive effort to tools so that we can optimize for what humans do best, which is think, solve, create, or connect ideas. We've always done this. We write in diaries to extend memory. We use spreadsheets to manage complexity. AI is no different. It is now part of our thinking system.

So perhaps this is not cognitive atrophy after all, but cognitive elevation. Perhaps I need to find fulfilment in orchestrating intelligence rather than simply executing it?

But, at the same time, Karl Marx's warning about alienation of work hangs over. When AI takes over synthesis, analytical thinking, and brainstorming, I find it difficult to see myself in the final product, at least entirely. In essence, I've given up the work that I find meaningful.

AI creates a conflict between two humanistic values. While it can enhance us by extending our cognitive reach beyond what we could achieve alone, it can also diminish us by reducing engagement in our work.

AI is undeniably a tool, an extension of my thinking system. But is it stealing meaningful work from me? Or is the new 'meaningful work' metacognition - thinking about thinking? And is that meaningful enough?

I don't have the answers yet. But I think the questions matter.

I'm an AI optimist. There I said it. Not because I think technology will magically solve all our problems, but because I've seen what's possible when innovation meets intention.

AI has the potential to improve lives, whether that's accelerating medical breakthroughs or making education more accessible or helping us solve food security and climate change. To me, that's the real promise of this technology.

But optimism doesn't mean blind faith. It means believing in what's possible while staying vigilant about how we get there.

That's why I care deeply about ethical, safe, and respectful AI, systems that protect privacy, minimize bias, and serve people equitably.

The challenge ahead is to keep pushing boundaries, responsibly. To build an AI future that reflects our best selves. After all, it is we who determine that future.

In healthcare technology, particularly in electronic health records (EHRs), AI has immense potential to ease the cognitive and administrative load on clinicians. But for that potential to be realized, AI must first earn trust. That starts with empathy in design, where AI is introduced as a helpful, quiet assistant, not an annoying, intrusive bot/callout that interrupts or undermines users. And certainly not in noble professions.

When AI supports clinicians subtly, surfacing insights at the right time and giving them autonomy to engage with it on their own terms, it strengthens confidence rather than resistance. Over time, consistency and reliability build trust, and with trust comes adoption.

Yet the rush to deliver "AI-enabled" features risks losing sight of this balance. More isn't always better. The goal shouldn't be to make AI visible, but to make it valuable, a collaborative partner that empowers people to do their best work without noise or intimidation.

But, here's where I have an extended issue. It extends to any application of AI. Building trust could lead to complacency, and that's where serious errors creep in. Dependency on humans to evaluate AI-generated content thoroughly is risky and an opportunity for disaster.

That's why AI needs to be introduced with caution. It's not about putting it out there in the wild for brownie points. It's about ensuring diligence in its use.

Are businesses simply transferring accountability to consumers of AI? Who in the value chain is responsible for errors? Is it the model owner, the business that built the logic around it, or the ultimate user?

In healthcare technology, particularly in electronic health records (EHRs), AI has immense potential to ease the cognitive and administrative load on clinicians. But for that potential to be realized, AI must first earn trust. That starts with empathy in design, where AI is introduced as a helpful, quiet assistant, not an annoying, intrusive agent that interrupts or undermines users, and certainly not in noble professions.

When AI supports clinicians subtly, surfacing insights at the right time and giving them autonomy to engage on their own terms, it strengthens confidence rather than resistance. Over time, consistency and reliability build trust, and with trust comes adoption.

Yet the rush to deliver "AI-enabled" features risks losing sight of this balance. More isn't always better. The goal shouldn't be to make AI visible, but to make it valuable, a collaborative partner that empowers people to do their best work without noise or intimidation.

But here's where I have another issue. Building trust could lead to complacency, and that's where serious errors creep in. Dependency on humans to evaluate AI-generated content thoroughly is risky and an opportunity for disaster. That's why AI needs to be introduced with caution. It's not about putting it out there in the wild. It's about ensuring diligence in its use.

This extends to any application of AI. Are businesses simply transferring accountability to consumers of AI? Who in the value chain is responsible for errors? Is it the model owners, the businesses that build the logic around them, or the ultimate users?

Recently, I ran an experiment with a single developer, and some AI tools. The goal was to build a feature with little to no code and demonstrate accelerated build cycles through efficiency gains. What typically takes a sprint (roughly 14days) was done in a matter of hours.

Encouraged by the initial results, I expanded the scope. From PRD to stories to development to unit tests to TRR/PRR documentation. All AI-driven with human oversight.

In between, I began to question myself about the philosophical edge of artificial intelligence.

Here's what caught me off-guard. I felt less challenged, less involved cognitively. I felt like I moved from critical thinking to oversight, which is the ultimate objective of embedded-AI. It did the tedious work while I simply reviewed, nudged, and approved. But, was that enough?

Philosophers Andy Clark and David Chalmers argue that our minds extend into our tools. A calculator extends computation; AI extends strategic thinking. We therefore enhance human capability by building a cognitive partnership with it.

Supposedly, I'm not losing my skills. I'm evolving them to work with a powerful prosthetic.

But, Karl Marx warned that when we lose connection to meaningful work, we lose something essential to human flourishing. When AI handles the intellectual heavy lifting, I'm alienated from the process.

From a humanist perspective, I have to ask, am I being slowly stripped of deeper reasoning and creativity? In essence, am I still flourishing as a human?

Therefore, do we become better PMs because we're freed from grunt work? Or are we slowly losing the critical thinking muscles that made us valuable in the first place?

For the record, I'm still an AI optimist. But, my optimism is directed at AI solving important issues in food security, climate change, accessible healthcare, and education.

Too often, teams become enamoured with bright, shiny opportunities - features conceived not out of necessity, but out of novelty. Roadmaps fill up with items no user ever asked for or needed, but which happen to include the latest trend or appeal to an enthusiastic HIPPO's pet interest.

These items dominate conversations. Take AI for example. It is a powerful tool. But embedding it into any product just so it's "AI-powered" is like putting caviar on a tiramisu. It's richer than before, but does not make you better off.

There is a quiet dignity in building what users truly need. They are humble solutions to real problems. Not glamorous. Not keynote worthy. Just incredible value, built backstage. This requires discipline, restraint, and occasionally, the ability to say, "No". And that, in the end, is valuable innovation.

I consider myself a realist, swaying contently and peacefully between the realms of optimism and skepticism. But, in healthcare, I'm cautiously optimistic, dare I say hopeful, about the future of AI on the industry.

To think about what companies are doing today is nothing short of fascinating. They're exploring early detection of diseases, personalised treatment plans based on patient DNA and clinical history, virtual assistants giving patients medical guidance, and accelerated drug discovery. Others are building precision tools for AI-assisted surgeries and even predictive analytics built on AI algorithms that foresee health issues and offer preventive advice.

These are just a few examples of what companies like PathAI, Tempus, Babylon Health, Medtronic, and Google DeepMind are working on. This progress holds great potential for humanity. As AI continues to evolve, bigger breakthroughs in medical technology can be expected in the near-term. That's the optimistic me looking eagerly into the next five years.

Meanwhile, the equally stubborn skeptic in me worries about things like data privacy, security, and manipulation. AI for healthcare cannot operate in isolation and its success or efficacy depends on strong collaboration and partnerships.

So, how does all this work at scale? How will electronic health records or population health data be shared within and between private and public networks, nationally, or across borders, while maintaining confidentiality and trust? Getting to an ideal state demands deeper thought and preparation sooner than later.

Too often, MVPs aren't strategic bets — they're just hurried guesses packaged in design. It's not uncommon to begin product conversations on MVPs with "Let's build this to address that" We're more excited by ideas materialising than critically evaluating them.

Somewhere between whiteboards and sprints, we skip pertinent questions like: "What's the least we can invest to test this theory?", "What happens if users actually like it?", "Do we have a sustainable model?", even if it's briefly entertained.

An MVP isn't just a test of whether something fits — it's a test of whether it's worth building at all. Shipping features frequently isn't a definitive sign of a healthy backlog. Sometimes, it's smoke and mirrors.

An MVP is a calculated decision and a summation of tireless iterations that answered critical questions. MVPs are bets on a hypothesis and should be grounded in evidence rather than hope or self-fulfilment.

Meanwhile, I can guarantee our friends in engineering want the hours they clocked to be worthwhile. If there is no promise of success, I can bet you they'll lose confidence in time or you may have to look over your shoulder in the parking lot when things go sideways ;)

AI will impact almost every sphere of life as we know it. If your life changed with the advent of the smart phones, internet, or social media, you can bet changes will be far more profound when we embrace self-driving cars, robotic assistants, digital clones, neurotechnology, and more.

Though it may take time, a decade if we're lucky, we will still have to deal with more elementary use cases of AI in the shorter-term. For instance, jobs that can easily be automated and made more efficient.

What happens to cashiers, translators, customer service, factory workers, or data entry folks? How do they compete with the future of AI?

A few years ago, I commented on a LinkedIn post about the impact of AI on jobs. A professor from a prominent US university was quick to chime in that more jobs would be created because of AI and that my view was in error.

While it's true that more jobs will be created, these jobs will essentially be new to market. So, what do we do in the short-term as AI capabilities are released, proliferate, and scaled?

The major burden will fall on those who have passed a point in their life where they can pivot and "try something new".

So, what and where's the plan? Shouldn't we have one before rather than after? The last time unemployment levels spiked severely was just after the Great Depression in 1929. The effects of which were felt around the world. That episode delivered Hitler to us. What sort of revolution can we expect this time?

Sitting through user feedback meetings can be overwhelming, particularly when you have either too little or too much to go through. But what's the right amount? Truth is, there's no definitive answer. We need to weigh both the quantity and quality of the feedback.

Too little could mean you have a wonderful product with little scope for improvement. But it could also mean you have a product users don't care much for. Too much either means your product has real holes in it, or you have a passionate user base demanding more.

My issues with feedback are largely concentrated around its source. Is it coming from your most valuable users, or from those bringing up the rear? Don't get me wrong, low-adoption users may well turn into prospective enthusiasts if their needs are addressed.

Yet I find PMs impulsive about acting on feedback, perhaps because it gives them something to chase. But acting on any feedback could swing things the other way for users who never took issue in the first place.

Having said that, a few gems do creep in from unexpected sources. They're worth socializing with loyal users. Sometimes, they're the type of opportunities the silent majority haven't raised.

Presentations can be polished, informative, and visually stimulating. But, they tend to become an avalanche of one-way information dumps, especially when attendees are not fully aware of the intricacies driving the flow. Most folks follow along, hoping to connect the dots and form an opinion quick enough to vocalize their attention.

By contrast, conversations spark ideas, and ideas garner more conversation which makes for engaging meetings. A one or two pager, socialized a couple of days prior gives attendees an opportunity to familiarize themselves, to form a perspective, to think deeply, to raise intelligent questions, and build on the topic of discussion.

Unfortunately, we rely on tradition because it sits well within our comfort zone. The HIPPO will have its way while time and engagement remain the enemy of a good idea.

Prioritization is a skill in time management and decision-making, ensuring that the most important and impactful tasks are addressed first. But, this reasoning is predicated on being in control of the variables related to those tasks.

What happens when those variables aren't yours to control? How do you prioritize when the variables pertinent to you are flexible for others?

For prioritization to work, one must have control over what influences the goal or at least have a goal that's shared with dependent stakeholders. Else, prioritization is just another plan with good intentions.

I think that all products should have a positive impact on the individual, the community, and the environment.

A good product is an outcome of good design. And good design is an outcome of creative thought. Thoughts are compromised by intent. So, designing for good demands purity of intent.

It shifts the focus from selfish commercial interests to genuine positive outcomes. That includes byproducts of a product's application, even its disposal.

Artificial Intelligence (AI) can add value to many industries like healthcare, finance, transportation, education, home automation, manufacturing, analytics, and more.

Its introduction into our world was predicated on the enhancement of human life and context. Removing repetitive, non-productive, or labour intensive tasks, while improving efficiency and accuracy, is widely acknowledged as an inevitable outcome.

Moreover, AI is intended to augment human competence. It is not supposed to be a substitute for human ineptitude.

Take job applications for instance. Social media is rife with curated GPT prompts for resume or cover letter optimisation. But, aren't we essentially pitting the AI of an optimisation engine against that of an application tracking system?

The bigger question is, "What's the game plan when you show up for the interview?"

Product managers need to be objective in their decisions. Eliminating one's personal beliefs, choices, or preferences from what's evidently right for the user and product is a difficult task.

Objectivity ensures selfishness, prejudice and bias are held accountable by factual evidence. But, basing decisions on fact alone is not enough because objectivity need not be morally, socially, or environmentally grounded. Therefore, objectivity requires an ethical compass.

Objectivity and ethics serve as beacons of integrity, guiding us toward actions and judgments that are fair and just.

Product managers are portrayed to be custodians of a product, nested within some sort of multi-functionary network of dependent relationships.

Experts call them mini CEOs, managing the lifecycle, setting priorities, problem-solving, balancing needs of users, business, technology, performing research work, managing stakeholders, and ultimately, leading without authority. But, what do they do most of the time?

The more I assess my workdays, the more I'm led to believe that it comes down to a never-ending story of gut feels and calculated decision making.

The significance of a Product Requirements Document (PRD) seems obvious. Yet it's one of the most consistently overlooked artefacts in product development.

AI pundits argue that the PRD is dead, that a prototype says more than any document ever could. And there's some truth in it. A prototype can surface things a spec can't.

But a prototype answers 'does this work?' It doesn't answer 'why are we building this, for whom, and at what cost of everything else we're not building?'

That's still the PRD's job. This artefact outlines the vision, feature list, priorities, scope, risks, and purpose for the team, and for everyone downstream. It becomes a living document, a communication tool, a source of truth, and the glue that keeps people pointed in the same direction.

I'll admit it. I've been guilty of PRD negligence myself. Which is exactly why I've come around to a hard rule: no project gets commissioned without a signed-off PRD. Skip it, and you'd better brush up on a few seasons of Law & Order, Boston Legal, or Suits.

When we build anything, it is imperative that we have a vision. That vision becomes a blueprint that guides the project.

When we hurry through the process, we risk building for the short term with a somewhat inferior foundation. Inevitably, the pressure to accommodate more value within its compromised structure increases exponentially as the product grows.

We need to think long and slow before committing to development. Perhaps heed Albert Einstein - "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions".

"When the listener is totally present, the speaker often communicates differently...Sometimes we block the flow of information being offered and compromise on true listening. Our critical mind may kick in, taking note of what we agree with and what we don't, or what we like and dislike. We may look for reasons to distrust the speaker or make them wrong.

Formulating an opinion is not listening. Neither is preparing a response, or defending our position or attacking another's. To listen impatiently is to hear nothing at all."

- Rick Rubin

I couldn't agree more. Often, we evaluate, decide, and formulate before the information we receive is given an opportunity to be considered. We listen to judge and respond, hardly ever to consume and comprehend.

We must adopt a child-like curiosity in product development. We fill gaps in our understanding with cultivated assumptions formed through personal biases and common reasoning . We accept things because they're safe. Because they made sense at one point in time.

Children have the luxury of no preconceived notions. Limited exposure gives them an openness to question things, the very things adults take for granted.

It's really the 'silly' questions that have the most profound effect. They poke at the foundations of what we've come to accept. We accept because it has always been. And when those foundations are weakened by an explanation that suddenly sounds indefensible the moment it escapes our lips, we enter an intriguing phase of opportunity called change.

I dare say the amount of help content a digital product leans on is a fair measure of its usability.

That's not to say the absence of help content signals great product work. I'm well aware of the heuristics of good UI design.

It's that the more dependent we are on users learning how to use something, the further that product sits from being truly worthwhile.

I've always believed a product is built with the implicit understanding that it will be improved upon. There's always a functionality, an experience, or a metric that can be pushed a little further. 'Perfect' is a state a product hardly ever reaches. The goalpost seems to shift as you get close.

Product development is about building and updating to meet evolving user needs, extending across segments or borders, altering course for business growth and technological change.

But when saturation creeps in and innovation begins to dry up, the temptation is to call the product finished. It rarely is. Maybe it's the market, the team, or the definition of 'perfect' itself that needs to evolve instead.

Change is inevitable. It happens whether we invite it or not. Everyone will tell you as much: 'You need to adapt.' 'Just lean into it.' 'You got this.'

You'd think that means most people would appreciate it, especially when it's for the better. But being inevitable and being welcome are two different things.

Change is interconnected with people's comfort zones and vested interests. When these spaces are threatened by the possibility of change, people don't always react predictably.

It's almost as if change is encouraged, even expected to knock, just as long as it's at someone else's door when it doesn't suit us.

For some time now, I've been struggling to understand the relationship between people and elevators.

We have the affordance, we have the signifier. Yet, some of us call the elevator to us and others tell the elevator in which direction they wish to go.

It wasn't supposed to be rocket science. Yet, I'm consistently greeted by the all too familiar, "Is it going up or down?".

Interpretation is such a crucial part of design. While we can plan for almost every obvious circumstance, there is always someone who sees it differently.

I created my first social media account more than a decade ago. To me, it served as a mechanism to share updates, stories, and memories with the people I considered important to me.

But we've turned an incredible opportunity to connect into a disruptive path to instigate, tarnish, bully, cheat, mislead, and more.

When I think of impressionable minds being subjected to idealism, aggression, destruction, and just plain stupidity, it worries me. Worse, algorithms endorse content that keeps users engaged. Audiences are drawn to aggression, violence, sex, and division.

That motivates more production of trending content and the vicious circle continues, expanding with every iteration.

It's a difficult problem to solve because every lever has consequences in a different domain. Restrict content, and you're making a judgment call on someone's freedom of expression — an ethical line, not a technical one. Restrict too broadly, and you inhibit the creation and consumption that gives platforms their business value. Don't restrict at all, and you're complicit in the harm you can clearly see happening.

The solution lies at some brittle intersection of many critical pieces. That's what makes this so hard to solve. It isn't one broken part we can isolate and fix. It's several fragile ones, each essential, each easily damaged by too much pressure on the others.

Loosen restrictions and freedom flourishes, but so does harm. Tighten them and harm reduces, but so does the very openness that made the platforms worth building.

Checkboxes are sometimes mischief-makers in our digital explorations. They can get us into hot water with unwelcome emails, sales calls, malware, and mysterious subscriptions.

Our ignorance and negligence become acceptance to those who hide behind them. Checkboxes have always been small acts of consent, wrapped in the illusion of triviality.

Often, they hide in plain sight with dark intentions nested in extended documentation. Most people do not peruse through pages of legal content. Other times, they hide in defaults. Most folks accept the status quo. They simply presume that we live in an ideal world where good intentions are exchanged as frequently as handshakes.

So, who do we blame - the businesses that disclose their intentions, albeit discretely, or us, for diving in and hoping for the best?

I've been drifting intentionally towards minimalism for a while now. Perhaps it's age. Perhaps it's me, finally, finding myself. I notice it now in the places I visit, the things I use, and the products I build.

Minimalism is the absence of distraction for the sake of clarity and focus. As a lifestyle, it encourages us to seek simplicity and meaning over consumerism. It asks us to be truly appreciative of what matters most - relationships, peace, experiences, time, and space.

In design too, it is the omission of what's non-essential. It is a conscious decision and a difficult path at that. It demands restraint, confidence, and concerted effort. It drives us to make mindful choices, to see the beauty in purity and the value in necessity.