The Next Release

Product Management often feels like steering a ship through unpredictable seas. Over my career, I’ve learned when to grip the wheel and dive into execution, when to step back and chart the strategic course, when to find that sweet spot in between, and when to simply hand the helm to the crew and trust them to steer. I call this balance Product Helmsmanship . The Origin Story When I first stepped into tech, I started from the lower decks. I began in execution, first as a developer writing code since I was 12, then as a Business Analyst turning requirements into documents and diagrams right after university, and later as a Project Manager focused on delivery. The transition into Product Management felt natural , but in the early years my role often felt like translation, helping business leaders and technical teams understand one another, sometimes mapping business requirements to technical jargon and vice versa. Over time, I realised Product Management is less about translating and ...

Earlier this month, I spent a few days creating a workshop on AI as Copilot for Product Managers. The feedback was positive, so I invested another couple of days turning the content into a comprehensive blog post. I was pleased with the result and genuinely believed it could be useful for others new to this space. I finished writing around 2:00 AM on Saturday and decided to schedule it for auto-publishing on LinkedIn on Monday, 8 September. Then Father’s Day happened. As a proud dad, I shared a casual photo of my gifts on Instagram along with a dad joke about ROI (Return on Investment). When my daughter asked what ROI meant, I realised my professional humour might not land everywhere, so I quickly adapted the post for LinkedIn in just five minutes, just for fun. On Monday morning, after a sleepless night with a sick child, I completely forgot about the scheduled post. As a result, the two posts went live only a day apart. The outcome? The LinkedIn version of the Father’s Day post not...

Lately, I’ve seen more and more Product Managers diving headfirst into Vibe coding, spending most of their time learning and using low-code or no-code tools, developing, and deploying their “production-ready” builds. At the same time, some mid to large-sized companies are cutting engineering or design roles and expecting PMs (assuming with the help of AI-enabled tools) to do it all, going from requirements to release, solo. This might work in a startup or simple products, but it rarely scales well in complex or mature products. At least not yet. To my fellow PMs rushing to learn Vibe coding as their primary goal: Exploring tools can spark creativity and speed up prototyping, and all good with that! Let’s only remember, as Product Managers, your core mission is to define the 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆, prioritise the 𝗿𝗼𝗮𝗱𝗺𝗮𝗽, and work closely with customers to build the right 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲 thing. Tools and tech stacks are there to support that mission, not replace it. 𝗙𝗼𝗰𝘂𝘀 on what...

  AI makes building a new product easier, no doubt. But standing out? That’s on you! It’s 10x easier to build, 100x harder to differentiate. Your edge: Start with curiosity, keep experimenting! #ai #product — Ali Vahed (@alivahedinfo) June 11, 2025

The Scene:   INT. OFFICE – DAY A sleek high-rise office with floor-to-ceiling windows. A formal interview is underway for a role in a Software development team. A table sits between the INTERVIEWER and the CANDIDATE CASTING The INTERVIEWER: Professional, relaxed. Someone who interviews for any role, from a Sales rep to Software Engineer to C-level Executive, inspired by The Wolf of Wall Street , loves asking questions that throw candidates off guard. The CANDIDATE:   Suited up, a bit nervous but composed. A seasoned software professional: Product or Project Manager, Business Analyst, or experienced Software Engineer, ready for whatever the interview throws their way.    ACTION INTERVIEWER:  (smiling confidently) Please sell me this pen! CANDIDATE  (pauses, raises an eyebrow, thinking: “Seriously? For this role?” but decides to roll with it) Sure... that’s a good question. (leans forward slightly, zoomed in on the candidate's face, thinking out loud) B...

  There are two moments I absolutely love in any project: - Kicking off a brand new product , when everything seems possible! - Launching it for the first time, when the results start rolling in and life feels pretty good! Then there are these two moments I secretly dread: - Right before kickoff , when I second-guess every decision I’ve made. - Right after launch , when I can’t help but think, “You could’ve done better…!” And there’s this one rare moment I genuinely struggle with: Shutting down a product I helped bring to life. Even if it’s the right business decision for the client, it still stings! Living one of those moments right now and yeah, it sucks! But … this too shall pass!

It’s your choice: If you want to deliver exactly what your customers asked for at the start, go with the Waterfall model(1) . If you want to uncover what they actually need , use prototyping techniques (2) . But if your goal is to make them truly happy , be  Agile(3) . Simple. (1) Waterfall Model: In the Waterfall model, requirement analysis is the first step of the Software Development Life Cycle (SDLC). The software is built strictly based on these initial requirements, which are typically signed off by the customer. The problem is that there is often a significant gap between what customers say they want and what they actually need. (2) Prototyping Techniques: Prototyping is commonly used by Business Analysts to discover the customer's real needs and core requirements. However, one challenge is that these needs often change. What the customer wanted at the start of the project may no longer be relevant by the time the software is ready. (3) Agile Ap...