BehavioralStrategy.com teaching pack v1.0
Author: Jason Hreha
Source file: methodology/choose-target-behavior.md
License for original text: CC BY-NC-SA 4.0 (existing site prose). External sources retain their rights.
Editable text copy; Markdown headings and tables are retained.

# How to Choose a Target Behavior

> **Definition.** Choosing a target behavior means selecting a specific, observable action for a defined population and context, based on its expected contribution to an outcome and the evidence that people can and will perform it.

Selection is a decision about what the service should enable. It includes comparing alternatives, identifying the work required from every actor, and choosing which uncertainty to test next. A promising rating or familiar success story cannot complete that work for you.

Use this guide when a team has a defined problem but is still choosing what people should do. Record your decisions in [workbook sections 1 to 4](https://behavioralstrategy.com/education/decision-workbook/#step-1), then use the [BMF testing guide](https://behavioralstrategy.com/methodology/validate-behavior-market-fit/).

## 1. Separate the outcome, action, and feature

An outcome is the useful change you seek. An action is something a person does. A feature is part of the system that may help them do it. Write all three separately.

**Invented teaching example: shift handovers.**

| Level | Example | What still needs evidence |
|---|---|---|
| Outcome | Incoming staff know who owns each unfinished task | Whether the information is correct and used |
| Action | Outgoing lead records the next action and owner; incoming lead acknowledges it before taking over | Whether both leads complete their parts during actual shifts |
| Feature | A shared handover form | Whether this form helps compared with the existing routine |

Opening the form is an intermediate action. It does not establish that the next shift received a usable handover. Explain the proposed link between the action and outcome, and identify how it could fail.

## 2. Generate materially different actions

Write alternatives using this structure: **who does what, in which context, on what opportunity, within which window, with what support**. Include the existing behavior or workaround as a comparator.

For the invented handover example, compare:

- An outgoing lead writes a short handover and an incoming lead acknowledges it.
- Both leads hold a brief discussion and record only unresolved items.
- A system drafts the handover from existing records; the outgoing lead checks it and the incoming lead acknowledges it.

These options are instructor examples, not observed results. They create different demands on people's time, skills, coordination, and available information.

### Challenge the amount of user work

Ask whether someone must perform the proposed action at all. Could a service complete part of it, reuse information already supplied, or make a repeated task unnecessary?

Count the work that remains. Automated drafting still needs access to correct records, an accountable reviewer, and a correction path. Human help still needs staff and capacity. An action such as learning or practicing may itself produce the desired outcome, so removing it may remove the benefit.

Do not assume that people must never learn a new action. Compare the value and practical cost of learning with the alternatives.

## 3. Map the complete actor chain

Follow the action beyond the product interface. Record each actor, prerequisite, handoff, completion signal, and fallback.

In the handover example, the chain includes updating the underlying task record, preparing the handover, resolving unclear ownership, acknowledging receipt, and acting on the information. A completed form can coexist with a failed handover.

Mark support as either:

- **Normal support:** a planned, affordable part of the intended service, such as training, an accessible interface, or a staffed help channel.
- **Exceptional support:** extra researcher coaching, gifts, manual repair, or privileged access outside that service.

Support can be part of a viable design. The question is whether the stated service can provide it when needed. Estimate staff time, peak demand, queueing, and cost for unsuccessful attempts as well as completions. Keep unsupported capacity estimates labelled as assumptions.

## 4. Compare evidence before ratings

Use a table that keeps each candidate's claims and uncertainties visible.

| Comparison field | What to record |
|---|---|
| Outcome contribution | The causal link you expect, its evidence, and a competing explanation |
| Current behavior | What people already do, including workarounds and refusal |
| Dispositional Fit | Evidence about recurring tendencies and preferences over the relevant horizon |
| Capability Fit | Required abilities, skills, and knowledge |
| Context Fit | External opportunity, time, tools, social conditions, and support |
| Delivery requirements | Every actor's work, service capacity, and cost |
| Evidence state | Direct observation, reported experience, inference, contradictory evidence, or unknown |
| Decision-changing uncertainty | A specific finding that would change the choice |

The [Behavior Fit Assessment](https://behavioralstrategy.com/glossary/behavior-fit-assessment/) can organize provisional judgments. If you use its numeric ratings, retain the source, rationale, uncertainty, and separate dimensions. Ratings are not probabilities or proof of viability. Do not turn missing evidence into a middle score, or let a high average conceal an unmet requirement.

Examine distinct populations and contexts when their requirements differ. A median-user summary can hide people who cannot access the service.

## 5. Choose a candidate and its next test

Select the candidate with the strongest supported path to a useful outcome, feasible delivery, and a worthwhile next test. Explain why the alternatives are less compelling under the current constraints. If a critical assumption remains unresolved, the decision can be to test that assumption.

**Illustrative handover decision.** A team could test the short written handover if its task records are too incomplete for automated drafts. Its next question is whether both leads can finish their parts during a real shift change. If acknowledgement routinely waits until after work starts, the team should investigate timing or test the discussion route. These are hypothetical choices; no handover study is reported here.

A below-screen BFA rating identifies a candidate bottleneck to investigate. It does not automatically reject the behavior. Equally, a high score does not justify proceeding without observation.

## Public cases for practice

The [Instagram decision exercise](https://behavioralstrategy.com/education/instagram-decision/) asks you to compare candidate actions before reading the worked analysis. The [M-PESA exercise](https://behavioralstrategy.com/education/mpesa-decision/) adds multiple actors and operating requirements. They are public-source teaching reconstructions. Their source records do not show that the organizations used this method.

For a measured example of separating first action from repeat action, use the [Wikipedia measurement exercise](https://behavioralstrategy.com/education/measurement-lab/#wikipedia). It asks what a tested feature bundle can support and what remains unresolved.

## Check the selection before you test

Your decision record is ready when another reader can identify the outcome, distinguish the candidate actions from features, follow the full actor chain, inspect the evidence, and name the uncertainty that could reverse the selection. It should include a less-user-work alternative and the cost of the proposed support.

Then complete [workbook sections 5 to 8](https://behavioralstrategy.com/education/decision-workbook/#step-5). A finished selection can lead to a bounded test, a revised service, or a reasoned stop. It does not need to pretend that the evidence has already settled the outcome.
