Defining Business Intent

It sounds obvious. It rarely is. In practice, stakeholders lead with solutions instead of problems. They say "we need a dashboard with these five charts" when what they actually need is "our field managers spend two hours a day on manual status calls. We need real-time visibility into job status so they can stop." One is a feature list. The other is intent. One is easy to misinterpret. The other is impossible to misunderstand.

Why Intent Gets Lost

The gap between intent and execution exists because of how most organizations approach software development.

Stakeholders rarely present problems. They present solutions. A founder walks in with "we need a mobile app" before anyone has asked whether a mobile app is the right tool. A operations leader requests "a better CRM" without defining what "better" means in measurable terms. A product manager requests a feature before articulating what business outcome that feature is supposed to change.

Teams respond to this by estimating the request. "Yes, we can build a dashboard with five charts in three weeks." This is a reasonable response to bad input, but it's also a guarantee of disappointment. The dashboard ships, the charts are correct, the code quality is high, and nothing changes for the business. The project is technically successful and commercially meaningless.

Intent definition is the corrective. It's the conversation that happens before engineering estimates anything. It asks not "can we build this?" but "should we build this, and how will we know it worked?"

Intent vs. Requirements vs. Features

These three things are not the same, and confusing them is where most projects go wrong.

Requirements are task specifications. "The dashboard must display real-time data." "The system must support 10,000 concurrent users." Requirements are important for execution, but they're not intent. You can meet every requirement and still fail if nobody knew what problem the requirement was solving.

Features are the things you build. A dashboard. A search function. A notification system. Features are tangible and countable, which makes them feel concrete. But a feature that doesn't change behavior is not a success, even if it works perfectly.

Business intent is the measurable outcome you're trying to achieve. "Field managers currently spend two hours a day making manual check-in calls to job sites. We need to reduce those calls by 50% within 60 days of launch." That's intent. It includes a user (field managers), a problem (manual calls), a measurable result (50% reduction), and a timeframe (60 days). It's specific enough to build toward, but it's not prescriptive about how to build it.

Intent should be written before features are decided. In fact, a clear intent often reveals that the originally proposed feature was the wrong solution. A company might want to "reduce manual calls," and the solution might not be a dashboard at all. It might be an SMS integration that sends status updates automatically, or a mobile app push notification system, or better data hygiene in the source system. The intent is stable. The solution is flexible.

This distinction matters because engineering cost scales with feature count. But outcome achieved does not. You want to solve the problem with the smallest, fastest solution possible. That only happens if everyone knows what they're actually trying to solve.

How InTech Defines Intent in Practice

At InTech Ideas, intent definition is not optional, and it is not fast. It is fast compared to rework, but it happens before any code is written.

The artifact that captures this is the Intent Contract. It is a brief, structured document that defines:

• Business objective - The outcome we are trying to achieve, in business terms
• Primary outcome metric - How we will measure success, and the target
• User context - Who is affected, what their current experience is, what friction we're addressing
• Expected behavior change - What will be different for them after this ships
• Scope boundaries - What is in scope, what is explicitly not in scope
• Constraints - Budget, timeline, technical or organizational limits
• Acceptance criteria - The measurable conditions that define done
• Kill criteria - The metrics that would tell us to stop and pivot

The Intent Contract is reviewed and approved by the client, the Project Delivery Lead, and the engineering team before any development begins. It's the single gate that converts intent into authorized work.

The Project Delivery Lead (PDL) is responsible for establishing and maintaining intent throughout the engagement. This is a different job than project manager. A PDL doesn't reschedule tasks; a PDL asks "why are we building this?" before asking "what are we building?" If intent drifts during the project, the PDL resets it. If a scope change is proposed, the PDL evaluates whether it serves the original intent or compromises it.

This is why intent clarity matters so much in AI-era development. The cost of bad intent is higher now. In a traditional three-month project with a distributed team, bad intent gets caught in week six when the feature ships and doesn't move the needle. The whole team can still course-correct. In an AI-accelerated environment, you can build the same thing in two weeks. You can build it so fast that nobody notices the intent was wrong until you're three builds deep in the wrong direction.

Clarity before code is not bureaucratic overhead. It's the insurance policy against velocity becoming waste.

Intent-Led Thinking vs. Feature-Led Thinking

The difference becomes clear when you see actual examples.

Medical supply company: The original request was "build a customer portal." That's a feature request. What was actually happening was inbound customer service calls asking about order status, which was consuming two FTE each week. The real intent was reducing those calls by 60% within 90 days. Knowing this meant the solution wasn't a full portal. It was a lightweight order status page that could be built and deployed in two weeks, plus an email integration that proactively sent shipping updates. The intent-led approach saved six weeks of development and solved the problem 10 times faster.

Professional services firm: The request was "build a reporting dashboard." What they actually needed was visibility into which clients were at risk of churning based on utilization metrics and project velocity. The feature-led approach would have been a generic dashboard with every metric they asked for. The intent-led approach was a smaller dashboard with high-signal metrics and an alert system when utilization fell below historical thresholds. Knowing the intent meant building half the features and delivering twice the value.

Staffing firm: The request was "we need a better CRM." The problem they were solving for was the manual step of copying candidate data between three different systems (applicant tracking, payroll, time tracking). The solution wasn't a new CRM. It was an API integration that moved candidate data once and synchronized it across all three systems. This was built in three weeks instead of six months. The intent was clear; the feature list was irrelevant.

In each case, the team that asked the right questions up front built less, shipped faster, and created more value. The team that jumped to features built more, shipped later, and created confusion.

Key Takeaways

Intent is not vision, mission, or strategy. It's the operating contract for a single body of work. It's the answer to "what does done look like, and how do we prove it?"

Intent is not bureaucratic. It's the opposite. Intent definition prevents the meetings, rework, and feature requests that come from ambiguity. It costs a week upfront and saves eight weeks in execution.

Intent is not something that happens once. Projects that maintain intent clarity throughout have lower scope creep, faster shipping, and better outcomes. The PDL's job is to keep that clarity intact.

Intent is what separates product engineering from services delivery. A services team builds what you ask for. A product engineering team clarifies what you need to ask for, then builds that.

FAQ

Q: Isn't intent definition just another term for requirements gathering?

A: No. Requirements gathering is typically done after a solution is already decided ("we're building a dashboard, now let's define the requirements"). Intent definition happens first and is explicitly solution-agnostic. It says "here's the problem and here's what success looks like" without prescribing the solution. This is what makes it powerful.

Q: How long does it actually take to define intent?

A: For most projects, one to two weeks of active discussion with stakeholders, PDL, and engineering. This is faster than feature creep happens. And it saves the eight to ten weeks of rework that happens when intent wasn't clear.

Q: What happens if our intent changes mid-project?

A: It happens. The PDL's job is to acknowledge the change, evaluate whether it serves the original business outcome or compromises it, and decide whether to proceed. Sometimes you learn things that change the intent. That's data. You document it, get it approved, and realign the work. This is faster than silently changing scope and hoping nobody notices.

Q: Can you have multiple intents for one project?

A: You can have a primary intent and secondary outcomes, but if you're tracking more than three measurable outcomes, you probably have multiple projects. This is a clarity problem. It's better to be explicit about it.

Q: What if we can't define a measurable success metric?

A: That's a signal that the intent isn't clear enough yet. "We don't have a way to measure this" usually means "we haven't thought through what we're actually trying to accomplish." Go back to the problem statement. If the problem is real, there's a way to measure whether you solved it.

Q: Who should be in the room when we define intent?

A: Whoever has budget authority, whoever knows the user context best, whoever will build it, and whoever is accountable for the outcome. Not more than that. Too many voices in the room is a symptom of unclear stakeholders.