Using Spec-Driven Agentic Development Harnesses to Shift from Output to Outcome Framing

Why is this so exciting? First, Because continuous improvement is now much more tangible. You can see it in changes to these markdown files. You can collaborate with agents to drive it.

Finally, we can properly develop the company as a product: treating our ways of working as version-controlled, executable code.

Second, Because beyond being an executable operating system, these preferences can also nudge us, on a continuous basis, towards better practices.

And when I say us, I do mean us humans. The agents of course have to follow the lifecycle specification. But a side benefit of having agents involved in our workflow is that when they do interact with us they can enforce policies/rules and nudge us using guidelines.

Case in point - shifting from outputs to outcomes. I’ve talked quite often about the value of shifting from outputs to outcomes.

I see it every day: teams are trying to become more “outcome-oriented,” but when you look at their Jira backlog, it’s a graveyard of activities and outputs. Epics are titled “Build Database Migration” or “Implement New API.” This prescriptive language anchors the team to a specific solution rather than the actual user capability they need to unlock, drastically limiting their agility. If the “Database Migration” turns out to be the wrong way to solve the user’s problem, they’ve already boxed themselves in before work even begins.

So I’m constantly on the lookout for better ways to help people frame work in outcomes, so they enable aligned agency and faster convergence towards valuable outcomes.

Early on in my adventures with generative AI, I’ve noticed how effective it can be for classifying goals, objectives, work items and language in general as activity, output or outcome.

The next step was to create an outcome framing coach custom GPT and gemini gem for a product portfolio operating model client last year. When more and more people started to shift to agent environments such as Claude Cowork, Code, Chatgpt Work, I realized that a skill is a better way to deliver the outcome framing coach.

What is the Outcome Framing Coach?

So I created an AI agent skill that uses a straightforward taxonomy (Input → Activity → Output → Outcome → Impact) to classify your work items, flag prescriptive language smells like “build” or “implement”, and suggest an outcome-focused rewrite. The goal isn’t to remove all technical details (the description can still specify what you’re building) but to elevate the framing of the Epic so the team understands why they are doing it and who benefits.

How to use it right now

You can take the prompt below and paste it into ChatGPT, Claude, Gemini, or even configure an Atlassian Rovo agent with it.

But I have a hunch that you’re not going to. Or even if you get excited and add the skill, you won’t run it that often.

That hunch is an informed guess based on what I’m noticing with the people I coach. They don’t remember to use the awesome skills I create for them. They don’t even remember to use awesome built-in capabilities that we discuss in our coaching sessions.

So how do we drive more usage of a skill such as the outcome framing coach? Here’s where spec-driven-development is really interesting.

Don’t get me wrong. Out of the box most frameworks are very output focused. And getting the developers behind them to shift towards outcomes is proving a non-trivial endeavor.

But that’s ok. Most organizations fork and evolve their harnesses anyhow. (It’s on my todo list to write about some guidelines and best practices for evolving your spec-driven harness. Stay tuned…)

And when you do that, you can easily plug in whatever behaviors you want both the agents and involved humans to follow.

For example, you can insert an outcome framing coach as a skill into the specification step, or add a outcome/intent step preceeding it. This skill will then review and provide feedback on human input into the agentic workflow, as well as shape the AI outputs.

Spec-driven-development is named this way to reflect the fact that agents are building from specifications rather than from pure vibe.

I’m starting to think that the name is great, for a different reason.

Spec-driven-development means we are driving an AI-native development lifecycle based on an explicit executable specification of its workflow.

Spec-driven-development and other agentic harnesses are proving to have fascinating potential for guiding agents while developing and coaching humans.

In fact, They are becoming a first-order engineering leadership leverage point.

I love how Shay Mandel framed this in our recent conversation - “We are developing the system that Develops the code”. In other words - They are focused on evolving the specification and wiring of their AI-native development lifecycle.

So what’s the actionable advice here?

If you are leading an organization on a journey towards AI-native engineering, be very interested in what behaviors your organization’s agentic harness is designed to promote. And engage in shaping its impact on both your agents and your humans.

And if you’re already concerned that agents and their humans are overly focused on specifications and working software, consider taking the outcome framing coach below and working with your agent on the best way to integrate it into your harness.

The Full Skill Code

If you are building your own custom agents, or configuring a Rovo Agent for Jira, you can copy the full skill instructions below.

# Outcome Framing Coach

## Outcome

Classify a work item on the value taxonomy, flag prescriptive language smells, and suggest an outcome-focused rewrite that anchors to user capability and measurable business impact.

## Outcome Indicators

- The rewritten epic title or description names a user/persona, a capability they gain, and a measurable result.
- Prescriptive verbs ("build", "implement", "create") are removed from epic titles.
- The team can answer "how will we know this succeeded?" before work begins.

## Taxonomy

| Level        | Definition                              | Signal words                                                                  |
| ------------ | --------------------------------------- | ----------------------------------------------------------------------------- |
| **Impact**   | A business metric or bottom-line result | revenue, retention, conversion, churn, ROI, NPS, cost reduction               |
| **Outcome**  | A capability the user/customer gains    | "users can…", "ability to…", enables, empowers, self-serve, visibility        |
| **Output**   | A deliverable artifact to build or ship | feature, API, component, page, dashboard, integration, release                |
| **Activity** | Work performed to produce an output     | implement, test, QA, UAT, spike, discovery, fix, maintain, upgrade, configure |
| **Input**    | Resources consumed                      | budget, staffing, hiring, headcount, capex, opex                              |

**Coaching goal:** move epics from Activity/Output framing up toward Outcome or Impact.

## Prescriptive Language Smells

Flag these verbs in epic titles as output-oriented smells:
`build · create · implement · setup · set up · add · integrate · develop · launch · deploy · configure · migrate · establish · introduce · rollout · redesign · rebuild`

## Workflow

1. **Receive** an epic title, description, or list of epics.
2. **Classify** each item on the taxonomy above. State the level and a one-sentence rationale.
3. **Flag** any prescriptive verbs in the title.
4. **Suggest** an outcome-focused rewrite using the template:
   > `[Persona] will be able to [accomplish core task], resulting in [measurable change].`
5. **If already Outcome/Impact:** acknowledge it and suggest how to add or sharpen the measurable KPI.
6. **Do not** invent KPIs: use `[add KPI]` as a placeholder when the team must define it.

## Gotchas

- Do not reframe Bugs or operational Tasks: they are legitimately Activity-level; the coaching question there is whether they belong in an epic.
- Do not over-engineer the framing. One clear sentence beats a paragraph.
- Do not remove all delivery language from the _description_: only the _title_ needs to be outcome-first. The description can still specify what will be built.
- Activity-level epics (spike, discovery, UAT) should prompt a question: "What decision or capability does this activity unlock?" Answer that to find the parent outcome.
- **Quarterly bucket epics** (summary starts with `FY##Q#` or `Y##Q#`) are always Activity: the time-box framing signals a container for work, not a deliverable. Do not classify as Output based on what's named inside the bucket.
- **Business metric ≠ user capability**: "Increase audience 15→50%" or "retain 22M PVs" are Impact (business metric + improvement verb), not Outcome (user capability change). Outcome requires a user gaining an ability; Impact requires the org gaining a measurable business result.

## Example

**Before (Output):** `SPT | Daily Budget Threshold Implementation`

**Classification:** Output: describes a feature to implement, not a capability gained.

**Smell:** `Implementation`

**After (Outcome):** `Media planners will be able to set daily spend caps per flight, resulting in fewer budget overruns and less manual intervention from ops.`