Ask WHY First, or pay for it Later

By Ory Adler, July 7, 2026

MarTech projects often kick off with great fanfare and energy, a clear business case, and a reasonable budget. Fourteen months later you’re over budget, behind schedule, and the benefits everyone signed up for never show up. That’s the waterfall version of the failure. Run agile and you rarely get one dramatic reveal; instead the backlog keeps growing, the sprints keep closing on schedule, and the KPI the program was funded to move never actually moves. Leadership blames the vendor, timelines, the market, or "change management." Nobody blames the requirements and that's the mistake! In my experience, the requirements are often where the project broke, right at the beginning, and long before anyone noticed.

Here’s the pattern I have seen. Business analysts and product managers sit down with stakeholders and ask two questions: what do you need? and how do you want it solved? Those feel like the right questions, but they skip the one that actually matters: WHY? Skipping why quietly locks the entire project onto a path that was never tested against the actual business problem.

This isn’t a waterfall problem. Whether requirements get elicited in a single workshop or a backlog gets groomed sprint after sprint, the failure is the same the moment nobody asks why before what and how. Agile doesn’t remove the shortcut, it just spreads it across a hundred smaller decisions instead of concentrating it in one.

It’s a Process Problem

I want to be precise about what’s broken here. Most of the BAs and PMs I’ve worked with are sharp, organized, and diligent. The problem is the process they were taught to follow.

When you ask a stakeholder what they need and how they want it delivered, you're accepting their diagnosis and their prescription in the same breath. You never get the chance to ask whether the underlying need is even valid anymore. Business conditions shift, a requirement that made sense two years ago, when a loyalty program was younger or the competitive set looked different, might not make sense today, but nobody's asking. The elicitation process, as practiced, doesn't leave room for that question. It assumes the stakeholder has already done the diagnostic work and just needs you to execute.

The "how" question does something even more damaging. It forces a solution before anyone has agreed on the desired outcome. Once a stakeholder tells you how they want something solved, it pre-supposes a process and that becomes the requirement, and everything downstream gets built to protect that one answer. Except there are usually several ways to hit the same business outcome, and some of them are cheaper, faster, or better suited to what the technology can do out of the box. You never find that out, because the how was decided before the why was ever on the table.

Start with why instead, and something opens up. You get the chance to challenge whether the requirement should exist at all, or whether the business process feeding it needs to change instead of the software. You get multiple solution paths instead of one inherited from a stakeholder's mental model of how things have always worked or must work.

There’s a catch, and it matters. Asking why only works if the person asking is fluent enough in the subject matter to do something useful with the answer. I’ve seen the opposite too, where someone runs a mechanical five-whys exercise with no grounding in the business and just wears the stakeholder down. That’s friction, not insight. The practitioner asking why needs enough context to recognize the implications of the answer, push on weak areas, and know when the conversation has surfaced something real. Asking why is necessary but not sufficient; it has to come from someone who knows what to do with the response.

Think about what gets lost when a requirement skips straight to what and how. You lose the ability to notice that a “need” valid three years ago isn’t valid now. A loyalty tiering structure or earn-rate rule built for one competitive set can be dead weight once competitors restructure their own programs. Elicitation doesn’t revisit that logic, because it’s built to capture what the stakeholder currently believes they want, not to test whether the requirement should still exist.

You also lose optionality. Every business outcome can usually be reached more than one way, but once a stakeholder says “I need the system to do X in Y manner,” that becomes gospel, and the project spends months protecting X-done-in-Y-manner instead of asking whether Z gets you further for less money and less risk. The how question forecloses that comparison before anyone gets to make it.

And you lose the standing to question the process itself. A requirement is downstream of a process, and if the process is the actual problem, no amount of well-elicited requirements fixes anything. You’re just building better tooling around something that shouldn’t exist in its current form, and what-and-how elicitation is built to avoid ever having that harder conversation.

The Structural Problem Underneath

Technology and product organizations, in many companies I've worked in and around, sit in service to the business. That sounds harmless, reasonable and even virtuous. In practice it produces a client-vendor dynamic. The business hands over its ask, and technology's job is to deliver against that ask, not to interrogate it. Vendors take orders. They don't usually get invited to question the order, and even when they are invited, the incentive structure doesn't reward them for slowing things down with hard questions.

A value-added partner behaves differently. A partner pushes back. A partner says, before we scope this, tell me what you're trying to achieve, because there might be a better way to get there. That posture requires standing, and standing isn't something a methodology grants you. No amount of BABOK certification changes the org chart. If technology and product teams see themselves, or are treated as, order-takers, the why question won't get asked consistently, no matter what the requirements template says it's supposed to cover.

This matters because it explains why the failure repeats across companies with completely different methodologies, tools, and levels of process maturity. The common thread is also the relationship dynamic, not just the process.

I’ve watched technology and product teams that were genuinely excellent operationally, good at ceremonies, documentation, deadlines, still produce the wrong thing, because being good at execution doesn’t mean you’re delivering the right outcome. You can run a flawless sprint cadence and still build the wrong feature, because nobody with standing asked whether it should exist in the first place. Execution quality and requirement quality are two different axes, and most organizations only track the first one.

This is where agile’s real strength turns into a blind spot. A prototype-and-feedback loop is very good at catching the wrong how fast, a clunky flow or a feature nobody uses gets flagged within a sprint or two. It has no equivalent mechanism for catching the wrong why. A user story already has a why built in, the “so that” clause, but once a story is written and groomed into the backlog, almost nobody goes back and re-tests that clause against the business outcome or the end to end process. Teams end up iterating beautifully on features that were never validated to begin with.

Where This Shows Up First: Buying Software

The what-and-how habit doesn't stay contained to a workshop. It travels straight into procurement.

Companies write requirements shaped like solutions, not outcomes, and those requirements go into an RFP. Vendors read a solution-shaped RFP and do the obvious thing: they say yes. Of course we can do that. Every vendor in a competitive process is incentivized to say yes to almost anything at the RFP stage. The real test doesn't happen until implementation, when the software turns out to work the way it was designed to work, not the way the RFP imagined it.

That gap is where I’ve watched good projects go sideways. The failure at that point is almost always leadership and rarely the technology and I’ve seen it surface in two forms.

The first is avoidance, leaders that either can't accept that the software isn't going to do exactly what was promised, or ones that privately accept it but won't have the hard conversation with the executive stakeholders who are expecting the original vision. So instead of resetting expectations, they try to bend the project into something that notionally looks like the original ask, or they build a narrative around it that doesn't hold up once people start to use the solution. Everyone nods along in steering committee meetings while the gap between what was promised and what's shipping quietly widens.

The second is a lack of follow-through on the organizational side. Business leaders won't, or can't, drive the process changes the software requires to work as designed. Instead of adapting the business, they keep leaning on delivery teams to force the software into behaving like the old process. And here's the part that really costs money: delivery leadership usually doesn't push back. They absorb the pressure and try to comply, which is exactly how a "customization" becomes a permanent maintenance liability instead of a two-week configuration decision.

Both versions have the same shape. A real misfit surfaces between what the business asked for and what the software does, and instead of correcting the premise, leadership distorts the project to protect it. It's the identical failure from the elicitation stage, just showing up later and costing a lot more to fix.

There’s a useful diagnostic here, and SAP ERP implementations are the cleanest example I know. SAP enforces a rigid, structured methodology that maps business functions into predefined workflows, and business is made to conform to SAP rather than the other way around. SAP pushes back hard on customization requests because decades of failed implementations taught the company that heavy customization produces delays, cost overruns, and years of painful maintenance debt afterward.

The test SAP effectively forces on you is this: instead of walking in with your requirements document, ask the vendor how their software expects your business to run, and why. That single reframe does the WHY work that elicitation skipped. In core commodity functions, finance, procurement, HR, order management, conforming usually costs the business nothing, because there’s no real differentiation to protect in those processes anyway. The catch is knowing where that’s true versus where you’re giving up meaningful market differentiation, and that’s the same judgment call the WHY question was supposed to force earlier in the process, just applied at the vendor table instead of the requirements workshop.

Where It Shows Up Again: Building or Customizing

The same trap resurfaces whenever a company decides to build custom software, or heavily customize an existing platform, instead of buying and configuring.

The justification is almost always the same: "our need is unique." Sometimes that's true. Often it isn't tested at all. Nobody's mapped the end-to-end business process to confirm that the "unique" need connects to a real business outcome, a sales lift, a cost reduction, a customer experience improvement that matters. Skip that mapping and you end up building expensive, custom software in service of a requirement that was never validated against anything.

This is showing up more now with AI, and the stakes are higher because the spend and the hype are both bigger. AI initiatives are getting greenlit as efficiency plays, promising sales lift or cost reduction, without anyone doing the process work to prove the causal link exists. You can automate a step in a workflow and still not move the outcome you claimed you were chasing, because the step you optimized was never the bottleneck. Without end-to-end process mapping tied back to the outcome, you're funding a hypothesis, not a business case, and you won't find out which one you had until well after the money's spent.

The same test applies here: does conforming cost you real differentiation, or are you protecting a requirement nobody ever validated? Most of the time, across most MarTech platforms, it’s the second one.

What Actually Fixes This

The instinct, once you see this pattern, is to reach for a better template, a more rigorous elicitation checklist, a more thorough discovery phase. That's treating the symptom.

The real fix is harder and requires ensuring that you have the right leaders asking WHY before WHAT and HOW. Drive elicitation with people who have enough business fluency to do something with the answer, not just process-follow a script. And be honest, structurally, about the relationship dynamic, because as long as technology and product are made to function as order-takers, the WHY question stays theoretical no matter how good your discovery workshop output looks on paper.

If there’s one habit I’d want every MarTech project to adopt tomorrow, whether it runs on a Gantt chart or a backlog, it’s this: before you write a single requirement or story, inquire as to what is the outcome you’re actually trying to produce? and how this outcome will ultimately realize incremental revenue or cost savings for the business? Doing this may feel uncomfortable as you kick off discovery workshops or sprint zero, but take my word that it’s a lot less uncomfortable than explaining, eighteen months and several million dollars later, why a project was late, why the benefits case never materialized, or why a backlog three years deep still hasn’t moved the metric it was funded to move.

At Innovate Marketing, my partners Uwe Stueckmann, Steve Rothwell and I built Checkpoint Loyalty to catch exactly this. It’s a structured assessment that ensures end-to-end requirements are validated, optimized and are tied back to the business case as well as technical designs to minimize unpleasant surprises.