The Next Release

Over the past few months, I’ve reached out to a few people whose work or ideas had an impact on me, asking for their feedback on my work or ideas. Many responded and provided valuable feedback, and I’m genuinely grateful to them. But a few, like a teacher I learned from, an author whose article inspired my approach, and start-up founders in different countries who implemented similar ideas, didn’t respond. Each time, I shared my thoughts or work, asked for feedback, or simply asked if I could learn from their journey. Each time, there was no reply. Assuming they received my messages but chose not to respond, I wondered: Why no reply? Was I doing something wrong? Am I invisible to them? Was it my message or my name? Or do I have unrealistic expectations of replies to an old student or a stranger from a far, far away country down under? I reviewed my messages again and could not find any issues. Talking it through with my “unofficial therapist / copywriter” ChatGPT(!) to have a second op...

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 ...

I spent hours and hours a few weeks back crafting a perfect playbook for user story creation, then got my AI co-pilot to create perfect user stories. They were INVEST, criticised by an Agile Coach role, and written with so much detail that there was no ambiguity in them. Crystal clear. I was so proud of them. It turns out, they were not perfect after all. In our retro yesterday, we discussed them. They had extra details, and the team needed to spend more time reading them. Having requirements (functional, non-functional, assumptions, and design) broken down into different sections also made it hard for QA to create and link test cases. The team wanted something simple. Simple is what they get. At the end of the day, the format of a user story does not matter. It is the outcome that matters. I spent a few hours and simplified some of the user stories. Next step: I will simplify the playbook for the AI copilot to create simpler and imperfect user stories from now on. [Unpolished] po...

As highlighted ( here ), I recently ran a workshop for our team on Agile Frameworks tailored for Product Managers. In an attempt to take my mind off everything happening in the world lately, I decided to turn the key takeaways from that session into a set of simple, visual study cards. These slides offer a quick tour through a few popular frameworks, such as  XP, Kanban, Scrum, Lean, LeSS, SAFe, etc.,  with just enough context to learn (or refresh) your understanding. Hope you find them useful! Click here to access and download the file.

You know that satisfying moment when you realise you’ve been doing something right, without even labelling it? There’s a quote that often shows up in Agile articles: “D𝘰𝘯’𝘵 𝘫𝘶𝘴𝘵 𝘥𝘰 𝘈𝘨𝘪𝘭𝘦, 𝘉𝘦 A𝘨𝘪𝘭e. ” It hit me again while I was prepping for a workshop I’d promised my team. I ran the 𝗔𝗴𝗶𝗹𝗲 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀 𝗳𝗼𝗿 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿𝘀 session, covering a few key topics: • What Agile really means • What Product Managers need to know • A quick tour through XP, Kanban, Scrum, Lean, LeSS, SAFe, Nexus, and more While working on the content, I paused and asked myself: 𝘏𝘢𝘷𝘦 𝘸𝘦 𝘢𝘤𝘵𝘶𝘢𝘭𝘭𝘺 𝘣𝘦𝘦𝘯 𝘱𝘳𝘢𝘤𝘵𝘪𝘴𝘪𝘯𝘨 𝘵𝘩𝘪𝘴 𝘸𝘦𝘭𝘭? And the answer surprised me: 𝘠𝘦𝘴, 𝘸𝘦 𝘸𝘦𝘳𝘦 𝘢𝘭𝘳𝘪𝘨𝘩𝘵! Not perfect. Not by the book. But real, grounded progress. We may not have ticked every box in a framework, but we are almost Agile. Especially in the Product Team, we are improving month after month, and that matters. Agility isn’t just about ...

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...

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...