Defining Business Intent

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. An 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. It usually takes days, not weeks, and comes out of the assessment when there is one. It always happens before any code is written.

The artifact that captures this is the Intent Contract. An Intent Contract is a short, signed-off statement of the outcome, scope, success metrics, constraints, human authority boundaries and acceptance criteria. It is not a legal agreement; commercial terms live in the engagement agreement.

On the business-intent side, writing one means working through:

• 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 Product Delivery Lead, and the engineering team before any development begins. It's the single gate that converts intent into authorized work.

A Product Delivery Lead (PDL) is accountable for the outcome, managing intent, milestones, and the rhythm of delivery across the engagement. Intent comes first: 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↗ (opens in a new tab), 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 in practice. Three illustrative examples (composites, not client results):

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 the equivalent of two full-time employees 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 takes days up front and saves far more than that 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.