DAY 3 | The Kano Model: Why Satisfaction Isn't Linear MoSCoW answers a specific, narrow question well: how urgent is this, relative to everything else competing for the same limited capacity. It does not answer a different, equally important question: what does actually building this earn you in customer satisfaction, and does that return scale the way you'd assume. That second question is what the Kano model, developed by Noriaki Kano, answers, and the shape of the answer su

DAY 2 | MoSCoW, Done Properly Almost every team that uses MoSCoW makes the same mistake, and it is not about the framework itself, it is about the discipline of applying its first category honestly. The MoSCoW sorts requirements into four categories: Must, Should, Could, and Won't. The framework itself is simple enough to explain in a minute. The discipline of applying it honestly, especially to the Must category, is where almost every real implementation quietly breaks down

DAY 1 | Why "Everything Is a Priority" Is Not a Strategy I once tracked a real team's backlog labelling over ten consecutive sprints. In sprint one, 22% of items carried a high priority tag. By sprint ten, it was 96%. Nobody made one bad decision that caused this. Every single markup, looked at in isolation, was individually reasonable. A stakeholder had a genuine reason their specific item mattered. Nobody on the team wanted to be the person who told someone else, to their

DAY 5 | From Diagram to Decision - Getting a room to actually act on a process map A process map that gets a polite nod in a meeting and never gets opened again has failed at its actual job, regardless of how correctly every symbol on it follows the notation covered this week. The diagram itself was never the deliverable. The decision it enables is the deliverable, and the majority of process maps that quietly die after one meeting die for the same reason: nobody in the room

DAY 4 | The Mistakes That Often Make a Process Map Useless A process map can use every BPMN symbol technically correctly, follow every rule from Tuesday's toolkit, and still be wrong in a way that only becomes obvious once someone actually tries to use it to answer a real question. Two mistakes cause most of the practical damage I see in real process maps, and both are easy to miss during a review, because the diagram still looks complete and professional at a glance. Mistak

DAY 3 | Map the As-Is Before You Touch the To-Be The most common mistake I see in process improvement work, more common than any BPMN notation error, is skipping straight to how a process should work without ever properly mapping how it actually works right now. It feels efficient to jump straight to the redesign, especially under time pressure. It usually is not, because the current, messy version of a process almost always contains information nobody has said out loud in a

DAY 2 | The Handful of Symbols That Do Almost All the Work - The practical BPMN toolkit: what each core symbol means and when to use it The full BPMN specification runs to dozens of event types, gateway variations, and connector rules. A genuinely useful process map, the kind that survives being shown to a real stakeholder, leans on about six of them, used consistently and well. This is the practical toolkit, the version that actually gets used on real projects rather than t

DAY 1 | Why Nobody Reads Most BPMN Diagrams Twice - The gap between a technically correct diagram and a genuinely useful one Most business analysts learn BPMN once, in a course or a certification prep, and then spend years afterwards either avoiding it entirely or producing diagrams so dense that nobody but the person who drew them can actually follow the flow. I have watched both failure modes cause real damage on real projects. The analyst who avoids modelling describes a

DAY 5 | Knowing When You've Outgrown Informal Mentorship Informal mentorship - an occasional coffee, a message when something comes up - is genuinely enough for most of a career, for most people, most of the time. At a certain point, it quietly stops being enough, and most people miss it entirely because informal mentorship rarely fails loudly. It just slowly stops moving you forward, and the slowness itself makes it hard to notice. Three honest signs None of these signs is

DAY 4 | Being a Mentee Worth Investing In - What makes a mentor keep showing up, and what quietly makes them stop Getting a mentor to say yes to one conversation is the easy part, once you have actually asked. Keeping that relationship alive and worthwhile for years is a completely different skill, and it is one almost nobody is taught explicitly. I have mentored many people into this field now, and I have watched a predictable pattern in the relationships that quietly fade

DAY 3 | How to Find and Approach a Mentor - A practical framework for identifying the right person and actually asking Most people who say they never had a mentor never actually asked anyone. They assumed the answer would be no, or that reaching out uninvited was somehow inappropriate, and the assumption itself became the entire barrier, long before anyone had the chance to actually say no. This is worth stating plainly because it changes where the actual work is. The hard p

DAY 2 | What a Good Mentor Actually Does (and Doesn't Do) The single biggest reason mentorship disappoints people is a mismatched expectation, set long before the first real conversation ever happens. Most people carry a quiet, half-formed hope that a mentor will hand them something close to a shortcut. A referral into a role. A problem solved on their behalf. A map with no ambiguity left anywhere on it. When the actual conversation turns out to be more modest than that, som

DAY 1 | The Mentor Gap - What trying to figure everything out alone actually costs, in time and avoidable mistakes I studied computer engineering, did a masters in software technology, and somewhere in the middle of it had to admit something that felt almost embarrassing at the time. I did not have a flair for coding. Everyone pointed me toward the obvious consolation route for someone who could not code. IT support. A stack of certifications. I refused a career chosen by de

DAY 5 | Internal Visibility and External Visibility Are the Same Muscle The habit that gets you seen inside your organisation and the habit that builds a reputation outside it are the same underlying muscle, and almost nobody trains both of them at once. Most people fall into one of two patterns. Some manage up well, staying trusted and visible inside their own company, while remaining completely unknown to anyone outside it, which quietly caps their options if that company

DAY 4 | Managing Up When the News Is Bad - Staying visible and trusted even when what you have to report is a delay, a miss, or a mistake The habit that has built more trust with every manager I have had than any good news update ever did is not how I report progress. It is how I report the weeks that did not go well. Most people default to one of two instincts when the news is bad. Bury it inside a longer update, hoping it slides past without becoming the headline. Or delay

DAY 3 | The Four Moments Worth Flagging - A quick-reference framework for what earns visibility, and what should stay quiet The fastest way to make managing up feel like self-promotion, both to yourself and to the person receiving it, is treating every task like it deserves a spotlight. Most of what happens in a working week is routine, and routine work should stay in your own notes, not in a message to your manager. Four specific moments genuinely earn a flag, and the entire

DAY 2 | The Weekly Visibility Habit - A five-minute structure that keeps you on your manager's radar without feeling like self-promotion I send my manager one short message most Fridays, and it takes about five minutes to write. It has done more for how I am perceived over the last few years than any single big presentation I have ever given. The habit only works because it is small enough to actually sustain every week without becoming a chore or starting to feel like perfo

DAY 1 | Your Manager Knows Less About Your Work Than You Think A manager with six direct reports has roughly forty minutes a week to spend on each one, once their own meetings, their own deliverables, and everyone else's fires are subtracted from a normal working week. Forty minutes is not enough time to notice the stakeholder relationship you quietly rebuilt, the requirements gap you caught before it became a costly rebuild, or the calm judgment call that kept a project fro

DAY 5 | What Actually Moves the Needle Besides Certifications If you have read this whole series and still are not sure what to actually do next, that is a fair thing to feel, and it is worth closing with the plain version rather than another layer of nuance. Five days of frameworks and examples can start to feel heavier than the actual decision needs to be. Underneath all of it, there are really only six common situations, and almost every business analyst reading this fits

DAY 4 | What Actually Moves the Needle Besides Certifications A hiring manager will forget the letters after your name within the hour of reading your resume. A genuinely good work sample sticks with them for weeks, sometimes long enough to be the reason they call you back over someone else with a stronger credential and nothing to show for it. This is not an argument against certifications. It is an argument for spending at least as much energy on the evidence a certificatio