“Discover the 4+P Model for business transformation! Watch now: https://youtu.be/xytgXbqOu2s #BusinessGrowth #Innovation” Watch on YouTube

Every time you hear “the business wants this,” three things are almost certainly true: no single person owns the decision, the real trade-offs haven’t been surfaced, and the project is about to drift. In this episode of the Better Business Analyst Podcast, Benjamin Walsh unpacks why abstract language quietly destroys accountability — and what better BAs say instead. “The Business Wants This” — Why It’s Destroying Your Projects “The business” is not a stakeholder. It’s not a decision maker. It’s not a source of truth. It’s a fog — a convenient hiding place people use when they don’t want to commit to specifics. Which customer? Which revenue stream? Which risk are we accepting? The moment abstract language enters your requirements, your roadmap, or your strategic documents, you lose accountability, clarity, and decision speed. As Benjamin puts it: “Abstract language feels safe. Specific language forces commitment. And that’s what BAs are for — providing clarity.” A Real-World Example You’ll Recognise Here’s a classic scenario from the episode — one you’ve almost certainly seen: “The business needs a more flexible approval process.” Sounds completely reasonable. It’s completely useless. Dig deeper and you’ll find: Sales wants faster deal turnarounds. Finance wants tighter controls. Operations doesn’t want more exceptions. And nobody wants to own the trade-off. The solution? A bloated workflow with 14 approval paths, 27 edge cases, and everyone hates it. Not because the BA failed — because the real tension was never surfaced. The Pattern: How Abstract Language Creates Bad Solutions Benjamin breaks down the failure pattern in four steps: Abstract language enters early — “The business wants / needs.” Real tension stays hidden — speed vs. control, growth vs. cost, experience vs. compliance. Solutions become compromises — not deliberate choices, just attempts to satisfy everyone vaguely. Everyone blames delivery — devs built the wrong thing, BAs wrote bad requirements, Agile didn’t work. But the problem was never properly surfaced. This is why problem statements matter. This is why accountability on the “why” matters before anyone writes a requirement. What a Better BA Does Instead A strong BA doesn’t accept “the business” as an answer. They translate abstract language into decision language. When someone says “the business wants this feature,” you ask: Which customer segments does this benefit? Is this protecting revenue or growing it? What risk are we reducing — or are we actually increasing risk? The goal is to force the shift from opinions and preferences to consequences and trade-offs. Every project has both. Surfacing them is uncomfortable — and that’s the point. “Better makes things uncomfortable to provide clarity through consequences and trade-offs. If everyone agrees and everything seems fine, that’s usually the time to ask: have we missed something?” — Benjamin Walsh, BBAI Podcast Practical Language Swaps You Can Use in Workshops Today Here are the direct reframes from the episode — language swaps that turn vague requests into accountable statements: Abstract (avoid) Specific (use instead) “The business wants a dashboard” “Operations wants daily visibility to reduce missed SLAs by 15%” “The business wants flexibility” “Sales wants fewer approval steps for deals under $50k to reduce churn” “The business isn’t ready” “We’re accepting delivery risk because training and change management weren’t funded” Notice the pattern: each specific statement can be agreed with or disagreed with. Someone can own it. Someone can challenge it. Vague statements can’t be challenged — which is exactly why people use them. Why Leaders Use Abstract Language (and Why You Should Push Back) Leaders — particularly middle management — default to abstract language because it avoids conflict. It means not having to name winners and losers, not having to accept personal accountability for a decision. The result? Vague strategy, bloated backlogs, and rework baked in before a single line of code is written. The best BAs — the better BAs — don’t just document what’s said. They clarify what’s meant, even when it’s awkward, even at the leadership level. Benjamin shares a personal example: he produced analysis for leaders that surfaced real trade-offs, and the feedback wasn’t positive. But: “At least I got a yardstick, a starting point. If you come out with vague promises and then need to deliver to someone’s expectations, you need to be very clear about what they want and don’t want.” — Benjamin Walsh The Three Questions That Stop Vague Language in Its Tracks The next time someone says “the business wants,” stop the conversation and ask: Which customer are we talking about? Which revenue stream are we protecting or growing? What risk are we trying to mitigate — or willing to accept? If you can’t answer those three questions (customer, revenue, risk), you’re not solving a business problem. You’re building something that sounds safe. And safe is usually expensive. Key Takeaways “The business wants” is a fog — it hides accountability and kills good analysis Abstract language leads to compromised solutions, not deliberate ones Better BAs translate vague requests into decision language: customer, revenue, risk Specific statements can be agreed with, disagreed with, and owned — vague ones can’t Pushback is uncomfortable by design — that discomfort is the BA doing their job Subscribe to the Podcast New episodes of the Better Business Analyst Podcast drop regularly — covering requirements, stakeholder management, Agile BA, and building a better BA career. Subscribe on Spotify or watch on YouTube. Level Up Your Business Analysis Skills If this episode resonated with you, our BA training courses go deeper on requirements language, stakeholder management, and how to handle difficult conversations with leaders. Start free — no credit card required. Also worth reading: Stakeholder Management for Business Analysts | Requirements Gathering Techniques | BA Interview Questions Guide

The business case is dead. Long live the opportunity canvas. Every PMO lead and traditional project manager just felt a disturbance in the force — but here’s the truth: business cases, as most organisations use them, are relics. Outdated, slow, and political. In most cases, written to justify a decision someone already made. Why the Traditional Business Case Is Broken The classic business case has been a staple of project governance for decades. It promises rigour — a structured argument for investment, backed by ROI calculations, risk registers, and options analysis. In theory, it forces decision-makers to think clearly before committing resources. In practice? It’s usually a political document dressed up as analysis. Here’s what actually happens in most organisations: A senior leader or sponsor decides they want something. A BA or PM is asked to “write the business case.” The numbers are worked backwards to justify the predetermined answer. Governance approves it — because nobody wants to be the person who killed the exec’s project. The project starts with false confidence and manufactured consensus. The business case didn’t create clarity. It created the illusion of clarity. And that’s worse. The Three Real Problems with Business Cases 1. They’re Built for Approval, Not for Decision-Making A business case is designed to pass through a governance gate. That gate is the audience. So the document is optimised to satisfy the gate — not to surface what’s actually true about the opportunity, the risks, or the alternatives. Real decisions require honest trade-offs. Business cases written to win approval bury trade-offs in appendices, round numbers favourably, and hedge language where specificity would cause friction. 2. They’re Too Slow for Modern Delivery A traditional business case takes weeks to months to produce. By the time it’s approved, the market context that justified the investment may have shifted. Competitors may have moved. The customer problem may have evolved. Agile delivery was supposed to fix this — but many organisations just layered Agile sprints on top of waterfall governance. You still need a 40-page business case to start the work, then you run in two-week sprints once approved. That’s not agility. That’s a slow start to a fast run. 3. They Create False Certainty A five-year NPV calculation in a business case is not analysis. It’s fiction presented with Excel precision. When you see “projected ROI: 340%,” someone picked a number that would get the project approved, then worked the formula backwards. False certainty is more dangerous than acknowledged uncertainty. It stops teams from asking the questions they should be asking throughout delivery: Is this still the right thing to build? Are the assumptions holding? Should we pivot? Enter the Opportunity Canvas The opportunity canvas is a lean, honest alternative to the business case. Instead of a lengthy document built to survive governance, it’s a single-page (or single-screen) artefact built to drive conversation. Where a business case asks “can we justify this investment?”, the opportunity canvas asks “should we pursue this opportunity, and what do we need to learn to be sure?” The key difference is epistemic honesty. An opportunity canvas explicitly separates what we know from what we assume, and what we need to validate before committing fully. What an Opportunity Canvas Covers A well-structured opportunity canvas addresses six things on one page: The problem or opportunity — stated in customer or business terms, not solution terms. What’s broken, missing, or possible? Who it affects — specific customer segments, internal stakeholders, or market groups. Not “the business.” Actual people with actual needs. The current impact — what is this costing us, or what are we failing to capture? Revenue, time, risk, experience. The proposed response — a broad direction, not a fixed solution. Room for the team to discover the right answer. Key assumptions and risks — explicit, not buried. What has to be true for this to work? What could kill it? The next learning step — not “approve the project.” What’s the smallest thing we can do to test the most critical assumption? That last point is the most important. The opportunity canvas doesn’t end with approval — it ends with a validated next step. It treats investment as iterative, not binary. The BA’s Role in Shifting from Business Case to Opportunity Canvas This shift isn’t just a document swap. It’s a mindset change — and BAs are well-placed to lead it. Here’s how to start introducing opportunity canvas thinking in your organisation without declaring the business case dead overnight: Start with the Discovery Phase Before anyone writes a business case, run a structured discovery sprint. Use the opportunity canvas format to explore the problem space. Then decide whether a formal business case is even necessary — or whether the canvas itself is sufficient to get started. Separate Problem from Solution The most common business case failure is jumping to a solution before the problem is fully understood. An opportunity canvas forces the problem statement first. No solution language until the problem is agreed and evidence is presented. Make Assumptions Visible Every business case has hidden assumptions. An opportunity canvas surfaces them explicitly — and assigns ownership. “We assume customers will pay $X. Here’s how we’ll validate that in the next sprint.” That’s BA work at its best. Replace Five-Year Projections with Nearest Learning Steps Instead of a five-year NPV, define what you need to learn in the next 30 days to justify the next phase of investment. This aligns with how good product teams work — staged funding tied to validated learning, not upfront approval tied to fictional forecasts. When the Business Case Still Makes Sense To be fair: there are contexts where a formal business case is appropriate and necessary. Regulatory or compliance-driven investments — where governance requires documented justification regardless of strategic clarity. Large capital expenditures — infrastructure, plant, or major system replacements where the decision is genuinely binary and irreversible. External funding applications — grants, board approval, or investor decks that require a structured document format. Mergers, acquisitions,

Custom ERP implementations are the doctorate-level project of business analysis. Every process is connected to five others, configuration is as consequential as code, and getting it wrong can paralyse an organisation. In this episode, Benjamin Walsh walks through the seven-step blueprint for how a BA should tackle a custom ERP — and what separates the BAs who survive them from those who don’t. Why Custom ERP Is a Different Universe for Business Analysts If you’ve only ever worked on SaaS apps, integrations, or workflow tools, an ERP implementation will feel like a different planet. Here’s why: An ERP is the organisation’s nervous system. Touch it wrong and you paralyse something critical. Every process is coupled — a change to procurement affects inventory, inventory affects finance, finance affects reporting, reporting affects governance. There’s no isolated change. There’s no “just this one area.” That tightly coupled nature is both the power and the risk of systems like SAP, Oracle ERP, Microsoft Dynamics, and custom-built equivalents. And unlike a Salesforce implementation where you’re configuring known patterns against established IP, a custom ERP often requires you to define how the entire business runs — not how people think it runs. “The business doesn’t really know what they really need — not because they’re incompetent, but because ERPs force them to define how the business actually runs, not how they think it runs.” — Benjamin Walsh, BBAI Podcast Configuration Is as Powerful as Code This is the insight that separates experienced ERP BAs from everyone else: in a custom ERP, configuration can make or break the entire solution. If the BA doesn’t get it right, developers cannot rescue it. The system is designed to be configurable — which means it will do exactly what it’s configured to do, right or wrong. Whether it’s mapping a GL account structure, pointing item code 197 to the right cost centre, or defining workflow approval thresholds — these decisions belong to the BA. They’re not an afterthought. They’re the product. The Seven-Step ERP Blueprint for Business Analysts Step 1 — Understand the Enterprise Before You Touch the ERP You cannot jump to future-state design without first understanding the operating model, the value chain, the financial model, customer flows, how data moves through the organisation, and where the real bottlenecks are. Without this foundation, the ERP becomes a Frankenstein of assumptions — and you get led through each module individually, creating a mess that nobody can maintain. This current-state understanding is not optional. It’s the entire basis for every configuration decision that follows. Step 2 — Deep Dive into End-to-End Process Mapping ERPs require full end-to-end process modelling — not isolated functional mapping, not user story mapping. The standard ERP process flows you must map include: Lead to Cash / Opportunity to Order Procure to Pay Hire to Retire Forecast to Report Build to Deliver / Make to Stock Asset Lifecycle Management Customer Service to Resolution Each should be modelled at three levels: Level 0 (high-level value chain), Level 1–2 (core process areas), and Level 3 (detailed steps, business rules, data elements, and actors). This is where 50% of real BA value is created on an ERP project. Step 3 — Define Solution Scope via Process Gaps On an ERP project, you don’t define scope by what users want. You define it by gaps — aim points, control issues, data issues, compliance requirements, and process inconsistencies. ERP is about fixing the model, not replacing today with a digital version of the same problems. This reframing is critical: the goal is standardisation and operational integrity, not feature delivery. Step 4 — Write Architectural-Level Requirements ERP requirements are not business-as-usual user stories. They must map to process steps, procedures, master data rules, integrations, reporting requirements, and financial controls. This is epic-level, architectural requirements writing — and it requires a different level of rigour and abstraction than standard feature requirements. Step 5 — Configuration Requirements (Where Junior BAs Fall Over) This is the step where 90% of junior BAs struggle. Configuration requirements means mapping: Business workflows → system behaviour Business rules → configuration objects Organisation structure → system hierarchy Roles → permissions Data models → master data structures You must understand how the ERP wants the business to work — what constraints you’re accepting by using the system, where you can flex, and critically, what configuration choices will break downstream processes or financial integrity. Getting this right is what earns you the title of Senior BA. Step 6 — Define the Wrappers (Custom Extensions and Integrations) Every custom ERP implementation has extensions — custom modules, custom workflows, API layers, data transformations, and integration points. These must be defined in detail and validated against core processes. This is a substantial body of work on top of the core ERP configuration, and it cannot be left to developers to define. Step 7 — Cutover, Data Migration, and Operational Readiness ERP go-lives succeed or die on this step — even if everything else was done perfectly. A lead BA must own: Master data cleansing and validation Data format transformation and mapping (old structures → new) Cutover playbook development Role-based training content (what each role does in the new system) Process-based UAT scenarios tied to real end-to-end flows Business readiness assessment Most teams de-prioritise this because time runs out. Most failed ERP go-lives trace back to inadequate data migration or operational readiness — not technical failure. What BAs Must Do Differently on ERP Projects Be harder on process owners. “This is how we’ve always done it” is not acceptable. ERPs hate bespoke — every customisation means pain, delays, cost, and technical debt. Push towards standardisation. Treat data as a first-class citizen. Every ERP process relies on data discipline. BAs must lead this — not assume someone else will handle it. Own the process-to-system traceability. You are the translation layer between the business and the system. No one else is positioned to hold this. Protect financial integrity. ERP originated as a financial system. If BA decisions break

Salesforce. Everyone’s heard of it. Few really understand what it takes to implement it well — until they’re neck-deep in conflicting requirements, an eager tech team configuring before the business knows what it needs, and stakeholders wondering why the system feels wrong. In this episode of the Better Business Analyst Podcast, Benjamin Walsh breaks down exactly how a better BA approaches a Salesforce (or any CRM) implementation: not as a systems analyst, but as a bridge between process, people, product, and project. Why Most Salesforce Implementations Fail (And Who Gets Blamed) Here’s the pattern Benjamin sees repeatedly, particularly in the education sector: Salesforce implementations go badly, and the system gets blamed. But when you investigate, two things almost always caused the failure: The upfront business analysis was never done. The project was led by architecture or IT, not business outcomes. The system was over-customised. So many bespoke modifications were made that it’s no longer Salesforce — it’s a custom CRM that happens to run on Salesforce infrastructure, with all the maintenance costs that implies. Both failures have the same root cause: the business analyst’s job wasn’t done before the technical team started configuring. Here’s the six-step framework for getting it right. Step 1: Understand the Business Problem, Not the Salesforce Product Don’t start with objects, fields, and automation. Start with why Salesforce? What problem is the organisation trying to solve? Often the real issue is poor process, not a poor tool. A sales team missing targets might be struggling with poor visibility, process delays, or unclear responsibilities — not a CRM gap. If you don’t surface this first, you’ll solve the wrong problem with a very expensive solution. Before any solution workshops: map stakeholders (sales, marketing, finance, IT) and how they interact. Use personas and process modelling to visualise current workflows. Capture pain points. Only then can you determine where Salesforce will actually touch the business — and where it won’t. Step 2: Map Stakeholders and Current Processes Stakeholder and process mapping isn’t just a checkbox — it’s the foundation everything else rests on. You need to understand who uses what processes today, where the handoffs break down, and what “good” actually looks like for each role. This is also where you surface the question that determines the entire project’s scope: Are we implementing a CRM, or transforming the way we manage customers? They are two completely different projects with different timelines, change management requirements, and definitions of success. Step 3: Define Success and Scope Before Touching the System Translate business outcomes into measurable objectives. Use SMART goals. Define what “done” looks like before anyone logs into a Salesforce sandbox. Critically: define what’s out of scope early. Integration with marketing automation, for example, often comes later — and many CRM suites don’t handle marketing well natively, requiring add-on products. Lock this down early or scope creep will eat the project. Step 4: Elicit Requirements the Salesforce Way Once you’ve done the three steps above, you can start requirements elicitation — but with a twist specific to platform implementations. When an organisation has already purchased Salesforce, you can’t be platform-agnostic. You need to validate every requirement against Salesforce’s standard capabilities. For each user story, ask three questions: Does this already exist as a standard Salesforce feature? Does it need configuration (fields, layouts, views)? Does it need customisation (code, workflow changes) — and if so, is that actually justified? This is the hard conversation BAs often avoid. If a business says “we call them prospects, not leads” — you need to coach them through Salesforce’s standard lead → opportunity → order workflow. This isn’t arbitrary: it’s the best-practice sales workflow that millions of organisations use, and it’s why Salesforce was built the way it was. Changing it creates maintenance debt immediately. The test for whether a process difference justifies customisation: Does this difference create value for your customers? Is it genuinely unique IP? Does it give you a market advantage? If the answer is “no, it’s just how we’ve always done it” — adopt the standard workflow and coach the team through the change. Step 5: Map Current Data — Sources, Ownership, and Migration Data migration is where Salesforce implementations quietly die. In Benjamin’s experience, data migration to any CRM becomes at least half the implementation effort. Change management takes most of the rest. The actual configuration work is often the smallest piece. Key questions to answer before any data work begins: What gets migrated, what gets cleaned first, and what gets archived? Who owns customer data once Salesforce goes live? Is Salesforce becoming the master of customer data — and does the business understand what that means? If you don’t have clean answers to these questions, the technical team will make decisions in your absence. Those decisions will be technically reasonable and business-wrong. Step 6: Configuration Yes, Customisation No (Until Proven Otherwise) The whole value proposition of Salesforce is that super users can add fields, change layouts, and create views without writing code or calling a vendor. That’s configuration. Customisation — writing code, changing fundamental workflows — is a completely different thing, and in Phase 1 of any implementation, it should almost never happen. The BA’s role here is to be a governor of scope creep and technical gold-plating. When the business asks for custom workflows in Phase 1, the right answer is: park it. Use the system in anger first, change your processes, and then evaluate whether the customisation is still needed. Most of the time, it won’t be. The practical goal: keep Salesforce as vanilla as possible in Phase 1. Turn off fields you don’t need rather than adding new ones. The system ships with far more than most organisations need. Start simple. Testing and Change Management: The Part BAs Often Skip BAs should define UAT scenarios from real-world processes — not from the system’s features, but from the actual workflows the business runs today. The test cases should reflect how users will actually use the system, including

Most people hear “5G” and think faster phone downloads. Business analysts should hear something different: a web of connected data and processes capable of transforming entire industries. In this episode of the Better Business Analyst Podcast, Benjamin Walsh unpacks what advanced connectivity — 5G, IoT, edge computing, and smart city technology — actually means for BAs, and how to find the real business opportunities hiding inside it. What Advanced Connectivity Actually Means for Business Here’s the technical picture, stripped of the buzzwords. 5G and 6G networks create ultra-low latency connections — data moves between devices, sensors, and systems in near real time. Pair that with IoT (billions of sensors and smart devices, many available for a few dollars on AliExpress) and you have live operational data everywhere. Add edge computing — which processes data locally rather than sending everything back to the cloud — and you get faster insights, lower costs, and new levels of automation. But here’s the BA translation: every sensor or device is part of a process. Every data point is a potential decision trigger. Every connected system creates an opportunity to add — or lose — value. The technology isn’t the story. The process change it enables is. Three Questions That Surface Every Connectivity Opportunity When Benjamin encounters new connectivity capabilities, he asks three questions to find where the real BA work is: Where does new data appear? — What sensors, systems, or connections are generating data that didn’t exist before? How does it change decisions? — Which decisions that used to be made manually, slowly, or with incomplete information can now be made faster or automated? What services, risks, or costs does it affect? — Where is the business impact — cost reduction, new revenue, risk mitigation, or improved customer experience? These three questions turn a technology trend into a BA engagement. The role of the BA is to map where connectivity meets the business — and that’s a process story, not a technical one. Real Examples: Where Connected Data Creates BA Opportunity Utilities and Energy: Smart Meters Smart meters and IoT sensors stream usage and fault data continuously. The opportunity: predictive maintenance (fix faults before they cause outages), dynamic pricing (charge more at peak times, less at off-peak), and customer transparency (show customers their real-time usage). A BA can define the data flows, map the changed processes, and qualify the business case — including the flip side: smart meters cost significant money to deploy and operate. Does the business case actually hold up once you model it properly? That’s a BA question, not a technical one. Local Government and Smart Cities Traffic sensors, GPS-tracked waste collection trucks, and connected street lighting all generate operational data. The opportunity: smarter truck routes (fewer kilometres, lower emissions, lower cost), faster fault detection (knowing when a streetlight fails before a resident reports it), and better traffic management. The BA connects that raw data to performance metrics and service delivery goals. This is process improvement at city scale — and it’s an area Benjamin is increasingly focused on. Healthcare: Wearables and Remote Monitoring Wearables, remote monitoring devices, and connected diagnostic tools shift healthcare from reactive to preventative — which is fundamentally a cost and outcomes story. For the BA, the work is analysing stakeholder needs (patients, clinicians, administrators), mapping patient journeys, and understanding the data dependencies between them. Security and privacy constraints are also key BA considerations in this space. The Core BA Insight: Sense, Decide, Act Faster When you strip away the technology jargon, what 5G and IoT actually deliver is the ability to sense, decide, and act faster. That’s a process story. The BA’s job is to identify which processes benefit most from that speed and visibility: Where are manual decisions slowing things down that could be automated or accelerated? Where can data remove guesswork or delay from a process step? Where can predictive analysis change when an action is taken — from reactive to preventative? These are the intersections where BA work lives: business process, technology capability, and customer value. That’s where BAs are most effective — and most needed. What This Means for BA Skills Data Literacy Is Now Core, Not Optional You don’t need to be a data scientist. But you do need to understand data flows, sources, latency, value, APIs, and where data is generated within a process. Benjamin has worked on data projects for two years and considers data literacy a foundational BA skill — not a specialisation. Process Modelling Must Evolve Traditional process models mapped human activities. Modern process models need to include digital actors too: sensors, bots, APIs, and events. A practical example from Benjamin: does that user need to fill in a form with their address, or does the mobile phone already know it? That’s an IoT-informed process decision — and it belongs in your process model. BAs Sit Between IT, Operations, and Strategy In a connected world, BAs need to connect business outcomes to network and data capabilities. That means collaborating with IT architects, operations leaders, and strategists — and representing the business perspective in conversations that can quickly become too technical. The skill is translation: turning connectivity into capability, sensor data into business decisions. Think Like a Value Designer Benjamin introduces the concept of “value engineering” — treating every connected device as an opportunity to measure and improve something, and every data stream as a potential fuel for a new service, a better customer experience, or a cost-saving initiative. The best BAs won’t just capture requirements in a connected world. They’ll translate connectivity into capability — turning streams of sensor data into smart decisions and better business outcomes. Three Questions to Start Using This Week Benjamin closes with three questions every BA should be asking right now, in any sector: What data do we already have that we’re not using to make better decisions? What data could we collect — or what’s coming — that we’re currently blind to? How can we turn that data into

Too many business analysts get stuck in the delivery weeds — writing requirements, managing backlogs, doing Jira admin — and forget the bigger picture. The 4P+ Framework is the mindset that changes that. In this episode of the Better Business Analyst Podcast, Benjamin Walsh goes deeper than ever into the model he’s developed over years of practice: People, Processes, Projects, and Products. Not as a theoretical framework, but as a practical way of seeing that separates high-value BAs from task-takers. Why the 4P+ Framework Matters More Than Any Methodology You can know every Agile ceremony, every BABOK technique, and every Jira shortcut — and still be a low-value BA. The difference between a task-taker and a value creator isn’t technique. It’s how you see the world of business change. The best analysts zoom out. They see how everything connects: the people using and shaping work, the processes that define how things run, the projects that drive change, and the products that deliver ongoing value. The 4P+ Framework is the lens that makes this possible. P1: People — The Human Layer Every process, every project, every product starts and ends with people. People follow processes. They deliver projects. They use products. If you don’t understand the people, you cannot design good systems or solutions — regardless of how well you document the technical requirements. This is why personas, empathy maps, and stakeholder analysis aren’t “nice to have” tools. They’re essential. They uncover real needs and pain points — not by asking for them directly, but by extracting them. Benjamin makes a sharp distinction here: requirements elicitation (extracting requirements, pushing on areas, seeing which ones hurt) is fundamentally different from requirements gathering (writing a list of what stakeholders say they want). A people analysis often reveals that the real problem isn’t what was assumed. Staff frustrated by an inconsistent process? It might not be a system issue — it might be a communication issue. Clients struggling with poor service? It might be frontline staff with different interpretations of the same process, not a technology gap. Start with people. Always. P2: Processes — The Engine Room of Any Business If people are the heart, processes are the engine. They define how work gets done today: the steps, decisions, and interactions that turn inputs into outputs — or ideally, outcomes. Here’s a point Benjamin makes that surprises many BAs: current state analysis ideally shouldn’t need to be done. In a well-run business, processes are already documented at the capability level. Business architects and enterprise BAs know the high-level process landscape. When someone starts a project, they already know the box they’re playing in. The reality? No one’s documented what they actually do. So BAs spend time on current state analysis — process mapping, swim lanes, BPMN — to visualise how things actually flow. Not how management thinks they flow. How real people do them. The critical insight: processes exist before the project or product that’s changing them. They’re the source of the problems that justified the funding. Understanding them at capability level (value chains, business architecture) tells you where the real issues lie — and that’s the foundation everything else rests on. P3: Projects — The Vehicles for Change Projects are how organisations make change real. They exist to solve process problems and deliver improvements through products, services, or capabilities. But here’s where most BAs go wrong: they drop into projects halfway through, are expected to “get the requirements done,” and treat that as their primary job. Your job isn’t to gather requirements. It’s to make sure the right change happens. That means understanding where the project sits in the wider organisation and strategy, who owns the change, and what success actually looks like — not just for the project, but for the process it’s meant to fix. Benjamin shares a real example: a project scoped as “implement a new CRM” that turned out to be a data quality and process alignment problem. The team reframed it — running a CRM project and a change project in parallel — because the real problem wasn’t the tool. This kind of reframing is the BA’s most valuable contribution to a project, and it only happens when you understand the process layer first. P4: Products — Delivering Value Beyond the Project Projects end. Products live on. This is an important distinction, especially in organisations running lean startups or product management teams where “continuous improvement” can blur into endless delivery without strategic anchor. In the world of product — whether a system, service, or internal tool — the product delivers ongoing value to the business and its customers. Products evolve, get feedback, get updates, and change shape over time. Modern BAs need to think like product analysts as well as project analysts. The danger in pure product-team thinking: it can lose its purpose within the greater business capabilities and the people it ultimately serves. The product team becomes obsessed with its own users and metrics, disconnecting from the organisation’s strategic goals. The 4P+ model keeps the product layer anchored within the broader context of processes and people. The Plus: The Feedback Loop The model is cyclic. People using products generate insights that improve the next cycle of change. That’s the “+”. The feedback loop where real-world usage data flows back to inform better processes, better projects, and better products. The four statements that hold it all together: People follow processes Projects aim to fix, enhance, or remove processes Projects deliver products Products create value for people And the plus — the feedback loop — means people using the product generate insights that start the cycle again. This is why products are never truly “finished.” They’re the beginning of the next round of continuous improvement. How to Apply the 4P+ Framework on Monday Morning The next time you’re dropped into a project, use the 4P+ lens before you do anything else. Ask: Who are the people involved? — Who is affected, and how do they experience the current