“Kini” , Radhika Kini

We love Lovable ❤️ From MVP ➜ MLP — this is the real shift in product building. ✨ Anyone can launch a Minimum Viable Product. But today, viable is not enough. Users want Minimum Lovable Products — products that feel good, look good, and create an emotional connection from day one. When you focus on lovable, everything changes: 🚀 Faster adoption 💡 Better feedback 🤝 Strong loyalty 🔥 Higher retention ✨ And users actually enjoy the experience The future belongs to products people love, not just tolerate. Ready to build your first AI MLP product ? https://lnkd.in/drsJq5Wj #ProductManagement #MLP #Innovation #DesignThinking #AI #SaeedAlHasanAiMaster

13

2 Comments

As product manager roles are transmutating from a pure manager type role to a PM engineer type role, here's the checklist for you - 1. Everyday play and experiment with different AI tools, internally make a list on which model to use for what purpose (this step is critical, as this compounds). 2. Never use AI for the initial draft when you are writing something. Writing brings you detailed clarity and in this AI age, clarity is king. Finish up your draft with AI, but start manually. 3. Always pay and use the frontier model. Don't cut corners here. The output of an Opus 4.6 is drastically different from sonnet when it comes to complex tasks. Having said that, develop a mental map on which model to use for what complexity of tasks. Otherwise you will just burn tokens for simple tasks. 4. When learning or understanding a concept, be deliberate and progressive when using the AI tools as well. For example, start with ChatGPT, take that output, understand it, add your own thoughts and then go to claude. Again point number 3, do apples to apples. If you are using the free tiers, treat all the free tiers as equals. 5. Learn to write agent native specs. Agent native specs are living docs which live in the repo, which the agent has direct access to. Take care of the smaller nuances. For example - If your team is using a context window of 100k models, then don't write specs which are too large. Eventually the agent will run out of context and start hallucinating. 6. When you have developed a strong intuition about points 1-5, then and only then build. The world is moving away from a PRD driven build environment to an agent spec driven build environment. Internalise that change. Change your workflow to adapt to it. 7. Build prototypes with the speed of thought, but remember these are prototypes and not actual production code. The prototype to production code journey is a bit far along. But that doesn't mean, you don't build, build your ideas quickly. Again the idea here is for you to develop enough intuition and judgement so that you can keep up with the agent. 8. As we are shifting from "vibe coding" to "agentic engineering", please remember this shift is going to be chaotic. Remember the world required 1-2 yrs to fully understand what actually is an "agent". So don't get overwhelmed, don't get any FOMO. Remember there's still a lot of time for the world to make this transition. All you can do is prepare better. Finally, anyone who is transitioning from a traditional PM to an AI native PM builder, remember, "chaos is a ladder". Be curious, be eager to learn, be adaptable, be flexible. Spend a lot of your time with the AI tools, stress test them, understand their limits, understand their context window and memory. This is in no way any exhaustive list (in fact I would argue this is a beginners list). But as you climb each stair in this ladder, you will develop enough intuition to move even further.

9

1 Comment

It is hard to understand Fabric's long-term strategy. On one hand, it was smart to build it around PBI, the leading BI platform. On the other hand, the key to Power BI's success in dethroning Tableau was its' extremely affordable licensing. Competitive licensing is not an element that Fabric's always-on pricing model can boast of at current rates, especially when the likes of Databricks, Snowflake, and other rising platforms are around. Perhaps Microsoft will be content with Fabric always being the 3rd/4th best option?

39

32 Comments

I think this is the biggest structural opportunity in GTM right now. Foundation Capital (Ashu Garg Jaya Gupta) published a few follow-ups from their initial article on "context graph," with the core argument that the companies that capture decision traces(the reasoning, not just the outcomes) will build the next billion-dollar platforms. I've been building this in GTM. Not theoretically. In production. On my own go-to-market. Most teams run agents on top of Salesforce or HubSpot. That's outcomes without reasoning. Here's the setup. I'm orchestrating all of GTM architecture from sales, marketing, pipeline, content, partnerships, and operations. Just agents running and operating simultaneously. Each agent owns a different function. Each one receives the same raw inputs: call notes, emails, and meeting context. But each one filters for what matters to its lane. SDR agent has visibility on advertising messaging but doesn't take action. Marketing takes the learnings from deal mechanics and apply to iteration on demand gen. They capture the customer journey, extract what's relevant to their specific role, and update their own outputs. Aaron described it perfectly: "It might end up as a Markdown file in a folder an agent has access to, and that helps your workflow." Here's what I'm seeing after running this for 100+ prospect conversations: Pattern recognition that no single tool gives you. After ~50 calls, the system started surfacing patterns I didn't consciously see. Which founder archetypes close fastest? Which verticals have real budget vs. aspirational budget? Which referral sources produce the highest-quality pipeline? Not gut feel, traced decisions across dozens of interactions. One call does the work of five people. A 30 minute discovery call now generates a qualified pipeline entry with decision rationale, marketing signals for vertical targeting, content angles for thought leadership, and behavioral profiling that sharpens every future conversation. Automatically, and the best part....the context compounds. Every interaction makes every agent smarter, not just for that account, but across all accounts. The 100th call is exponentially more useful than the 10th because the context graph grew. What I'll say plainly: I think this is the biggest structural opportunity in GTM right now. Not because agents are new. Because the context layer is new. The old way is making crucial decisions based on a siloed system of records; the futuristic way is making crucial decisions based on connected and enriched contexts. The teams building in that methodology today will have own reasoning that compounds and can't be copied. That’s the strategic moat. If you're running GTM, and you're tired of static tools but don't actually understand your business at its core, DM me or comment "context" below. I'll send you what I've built.​​

50

12 Comments

Quantization in Large Language Models (LLMs) As LLMs scale, intelligence is no longer the bottleneck — memory, latency, and cost are. Quantization turns out to be one of the most powerful (and misunderstood) techniques enabling real-world deployment of large models. In this blog, I break down: • Why LLMs are surprisingly quantization-friendly • INT8 vs INT4 vs NF4 — what actually works in practice • How modern architectures absorb low-bit noise • Where quantization fails and how to design around it Quantization is no longer an optimization step — it’s foundational infrastructure for production LLM systems. Link: https://lnkd.in/gqGje75G #LLMs #AIEngineering #Quantization #MachineLearning #GenAI #MLOps

9

2 Comments

AI agent success in enterprises starts with choosing the right architecture pattern. Here are 7 types of Ai agent architectures: First of all, I want to thank Prashant Rathi for this visual. 𝟭) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗴𝗲𝗻𝘁 + 𝗧𝗼𝗼𝗹𝘀 - One agent receives the user message - It calls tools like Calendar, Gmail, CRM, DB, etc. - It responds back after tool execution use cases: “Schedule a meeting and email invite” 𝟮) 𝗦𝗲𝗾𝘂𝗲𝗻𝘁𝗶𝗮𝗹 𝗔𝗴𝗲𝗻𝘁𝘀 (𝗦𝘁𝗲𝗽-𝗯𝘆-𝘀𝘁𝗲𝗽 𝗰𝗵𝗮𝗶𝗻) - Output of Agent 1 becomes input for Agent 2 - Each agent has a clear responsibility - Works like a pipeline (A → B → C) use cases: Research → Summarize → Create final post ✅ Best when work has stages and “handoffs” 𝟯) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗴𝗲𝗻𝘁 + 𝗠𝗖𝗣 𝗦𝗲𝗿𝘃𝗲𝗿 + 𝗧𝗼𝗼𝗹𝘀 - One main agent handles logic - MCP Server acts like a common tool gateway - Tools become reusable across teams (standardized connectors) ✅ Best when you want tool standardization at scale 𝟰) 𝗔𝗴𝗲𝗻𝘁𝘀 𝗛𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆 + 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹 𝗔𝗴𝗲𝗻𝘁𝘀 + 𝗦𝗵𝗮𝗿𝗲𝗱 𝗧𝗼𝗼𝗹𝘀 - Multiple agents run in parallel - One “manager agent” splits the task - Shared tools and shared integrations - Results are merged into one final response Best use cases: Enterprise incident response. - Agent 1: logs - Agent 2: metrics - Agent 3: knowledge base - Security investigation + compliance check 𝟱) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗴𝗲𝗻𝘁 + 𝗧𝗼𝗼𝗹𝘀 + 𝗥𝗼𝘂𝘁𝗲𝗿 - A router decides what path to take The same agent can: - call the right tools - trigger the right workflow - send to the correct endpoint (webhook) 𝟲) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗴𝗲𝗻𝘁 + 𝗛𝘂𝗺𝗮𝗻-𝗶𝗻-𝘁𝗵𝗲-𝗹𝗼𝗼𝗽 + 𝗧𝗼𝗼𝗹𝘀 - Agent drafts actions (email, approval, change request) - Human approves or edits before execution - Then tools execute safely Best use cases: Finance approvals and vendor payouts 𝟳) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗴𝗲𝗻𝘁 𝘁𝗵𝗮𝘁 𝗗𝘆𝗻𝗮𝗺𝗶𝗰𝗮𝗹𝗹𝘆 𝗖𝗮𝗹𝗹𝘀 𝗢𝘁𝗵𝗲𝗿 𝗔𝗴𝗲𝗻𝘁𝘀 - One agent is the “orchestrator” - It calls other specialist agents when needed - Like “agent teams on demand” Best use cases: Sales agent calling. - Pricing agent - Proposal agent - CRM agent How to choose the right architecture (simple): - If tasks are simple → Single agent + tools - If tasks have stages or multiple departments → Sequential / Router / Specialist agents - If risk + approvals matter → Human-in-the-loop (mandatory) If this was useful, save it, repost it, and follow Shubham Vora for practical AI agent use cases and implementation ideas for real business teams.

188

104 Comments

Gemini 3 is here! It was incredible reading about Google's new model. It's feels far more than a simple performance bump—it signifies a real shift where AI moves into being a genuine “thought partner”. Few features that stood out: • State-of-the-Art Reasoning: I'm excited that this model is built to genuinely grasp depth and nuance, which means it's phenomenal at "reading the room" for complex problems and is setting a new standard for intelligence. • Advanced Agentic Power: What really caught my attention is Google's claim that this is their most powerful agentic and vibe-coding model yet. It enables planning and executing complex, multi-step workflows, which is a massive leap forward for productivity. • Broad Multimodality: I was amazed to read it's claimed as the best model in the world for multimodal understanding. It can seamlessly synthesize information—vision, code, and text—helping us learn, build, and plan complex tasks in totally new ways. Looking at these features, we are entering a new era of intelligence. I absolutely cannot wait to see what everyone builds with this! #Gemini3 #GoogleAI #AIInnovation #FutureOfWork #LLM #AI https://lnkd.in/guMDTxAU

114

4 Comments

healthcare data has an identity crisis: We've become professional problem-sustainers, not problem-solvers. spent an awesome day at Out-Of-Pocket's Data Camp 2025 with 80 of the sharpest healthcare data minds. huge thanks to Nikhil Krishnan and the OOP team for creating the space where we can talk building, not "data theater" (just like product theater but maybe worse). same conversations we had 15 years ago: → Semantic layers that nobody uses → Dashboards that collect dust → "Big data" architectures for small/medium data problems then Greg Inman from Zero Health drops a great DuckDB + MCP + Claude Code demo. solves in 30 minutes what most health systems spend 18 months building. so the insight he called out: most "big data" problems are small data problems wrapped in enterprise theater. here's what gives me hope: met several data product managers thinking in actual products, not just pipelines. I'm not alone in the world! > being "a part of the value chain" and "deciding what to build" is huge for healthcare data people. the builders in the room aren't the problem. They're fighting the good fight against a system designed to extract value at scale from people and failing hugely at the quadruple/quintuple aim the providers on the front lines? they just want to have real conversations with patients, not wrestle with "enshittified" Tableau dashboards. The real villains: • "Big Data" vendors selling $2M solutions to $20K problems (looking at you Salesforce) • insurers hiding behind abstraction layers • platforms that peaked in 2015 but still cost like it's their heyday not into "sustaining problems" in healthcare data anymore. more into being a builder. the weird builders at Data Camp? they're my people. time to build what providers and patients actually need. not what vendors think they should buy. what's one "complex" healthcare data problem that's actually just over-engineered simplicity? [FULL DISCLOSURE: there are a ton of justifiably complex healthcare problems - its real and as a "non-provider" (no formal medical training), im still a proud idiot in this space] #healthcaredata #dataproducts

24

6 Comments