Product decisions

Small choices.
Consequential behavior.

Five product decisions about what users need to see, what rules should mean and what a release should preserve.

Assignment dashboard · operator's next step

A count isn't an answer.

On an assignment dashboard, “Needs Review” could show that something needed attention. It did not, by itself, tell an operator which accounts to investigate.

I asked for a direct path from the signal to the affected records and challenged labels that suggested more than the data could establish.

A below-five count was a useful observation. Interpreting it as available capacity required a reliable view of who was available.

Read the related case

From signal to investigation

SignalNeeds Review
ReachAffected accounts
ActInvestigate

A below-five count is an observation. Available capacity needs a reliable roster.

Assignment rules · testable outcomes

Define what wins.

Assignment rules can make sense separately and still conflict when they apply to the same case.

I kept asking which conditions made an assignment valid, which expressed a preference, and what should happen when they overlapped.

A hard constraint determines whether an option is allowed. A preference helps choose among allowed options. Each proposed branch needs a defined outcome before engineering and QA can test it.

Explore the assignment decision

Validity before preference

Check validityHard constraints
Compare valid optionsPreferences
Specify the next stateDefined outcome or open question

Search behavior · bounded emergency change

Faster still has to work.

A query can become faster while making the product feel broken if people can no longer find the records they need.

Before treating exact matching as the answer, I asked how people searched and what information they actually had. I challenged the diagnosis against available evidence and pushed for one bounded emergency change.

Query efficiency, findability, and release scope had to be weighed together. Several possible improvements did not justify bundling them into one emergency release.

Read the related case

One bounded change, three checks

QueryCan the read path improve?
PersonCan they still find the record?
ReleaseCan the change be tested and reversed?

Release communication · audience understanding

Explain the change, not just the release.

A technical story title could make a change sound broader than the actual behavior or omit restrictions users needed to know.

I asked about timing, restrictions, and acceptance criteria before describing the change to users, then shaped the explanation around what each audience would see and do.

A shorter note helped only if it preserved the conditions that mattered. The translation had to separate the change itself from what different audiences should expect.

See the enterprise delivery case

What the audience needs to know

AudienceWho needs to know?
ChangeWhat actually changes?
RestrictionsWhen does it apply?
BehaviorWhat should a person expect?

I translate the technical description into the change a person needs to understand.

Rehab workflow · shared representation

Give the workflow one shared meaning.

Stories and interface behavior can describe different slices of a workflow without giving the team one compact account of its states and transitions.

I moved from stories and interface behavior toward a model of phases, entry and exit triggers, and expected system behavior so the next step could be interpreted consistently.

The model separates the business phase and its triggers from what the interface displays. Proposed technical behavior still needs to be marked as proposed, not silently treated as a confirmed requirement.

Explore the shared platform case

A shared workflow contract

PhaseWhich business state?
Entry triggerWhat starts it?
System behaviorWhat should happen?
Exit triggerWhat ends it?

Product decisions from my work.

Continue the story

Small decisions sit inside a larger product system.

The choices about labels, priorities and state belong to a wider platform. The enterprise case connects those decisions to product scope, migration, adoption and continuing delivery.

See the enterprise platform story Inspect the assignment priority correction Discuss a role

I apply this decision discipline to evidence selection, tool contracts and evaluation. Inspect my AI systems

Sources and measurement

Count to action

On an assignment dashboard, “Needs Review” could show that something needed attention. It did not, by itself, tell an operator which accounts to investigate.

I asked for a direct path from the signal to the affected records and challenged labels that suggested more than the data could establish.

A below-five count was a useful observation. Interpreting it as available capacity required a reliable view of who was available.

The count is a signal for attention, not a diagnosis or a completed task.

The requested interaction should let an operator reach the affected records, then investigate the cause.

Keep the below-five observation distinct from a confirmed view of available capacity.

Rule precedence

Define what wins. Assignment rules · testable outcomes Assignment rules can make sense separately and still conflict when they apply to the same case. I kept asking which conditions made an assignment valid, which expressed a preference, and what should happen when they overlapped. A hard constraint determines whether an option is allowed. A preference helps choose among allowed options. Each proposed branch needs a defined outcome before engineering and QA can test it. A simple order for resolving overlaps: check validity, compare preferences among valid options, then define the outcome or the open question. See the reasoning and context Separating validity from preference keeps the reason for a choice visible. An unresolved overlap belongs in the decision specification, not in an engineer's or tester's guess. Document an open branch so the team can define and test its intended outcome. It gave engineering and QA a clearer way to handle competing rules, including branches that still needed a decision.

Performance tradeoff

Faster still has to work. Search behavior · bounded emergency change A query can become faster while making the product feel broken if people can no longer find the records they need. Before treating exact matching as the answer, I asked how people searched and what information they actually had. I challenged the diagnosis against available evidence and pushed for one bounded emergency change. Query efficiency, findability, and release scope had to be weighed together. Several possible improvements did not justify bundling them into one emergency release. A three-part review of query efficiency, record findability and the scope of one emergency change. See the reasoning and context A faster query is useful only if the workflow still returns the records people need. The search pattern needs evidence before exact matching can be judged as a candidate. One bounded change is easier to test, monitor, and reverse than several simultaneous changes. It kept the emergency change tied to the user's ability to find records and to a testable, reversible release scope.

Small choices. Consequential behavior.