Trajectory and Second-Order Implications Lens
Judge an early product by its direction and downstream consequences
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 94%
The lens evaluates an emerging product on two levels: what it can reliably do now and what direction its existence reveals. First, inspect the minimal capability and acknowledge its limitations without treating them as permanent. Next, infer why the company released it and what strategic destination the release supports. Then project plausible improvements over a defined horizon and identify second-order effects on workflows, buyers, users, and business models. The output is not blind optimism; it is a structured decision about whether to experiment, monitor, prepare, or ignore. This approach is particularly useful for AI launches, where an unreliable demonstration may still reveal that a broad class of computer-based work is becoming automatable.
Origin
Extracted from Marketing Against The Grain
Core principles
- 01Treat a minimal release as evidence of strategic direction
- 02Separate current limitations from the likely destination
- 03Look beyond the immediate use case to downstream changes
- 04Estimate what repeated capability improvements will make possible
How to run it
- 1
Observe the demonstrated capability
Describe what the product actually does without inflating the demonstration into a mature solution.
Pro tip Separate the core capability from launch-video polish and marketing claims.
Watch out Do not assume a controlled demo represents production reliability.
- 2
Record present constraints
List practical boundaries such as context windows, data access, operating time, accuracy, and required supervision.
Pro tip Distinguish architectural constraints from limitations likely to improve with iteration.
Watch out Do not ignore constraints merely because the long-term direction looks promising.
- 3
Infer the strategic direction
Ask why the company released this particular minimal capability and what larger product destination it advances.
Pro tip Use the company's customers, revenue mix, integrations, and prior launches as supporting evidence.
Watch out Avoid treating every experimental feature as a guaranteed roadmap commitment.
- 4
Project capability progression
Estimate what the system could do if reliability, context, personalization, and access improve over the next two to three years.
Pro tip Project incremental improvements rather than science-fiction leaps.
Watch out State the time horizon and assumptions explicitly.
- 5
Map second-order effects
Identify how the projected capability could change workflows, software interfaces, purchasing, employment, compliance, and competition.
Pro tip Ask who becomes the buyer or user when machines can operate software for people.
Watch out Do not stop at the first obvious consumer use case.
- 6
Choose a response
Decide whether to test the technology, build around it, prepare for disruption, or monitor specific milestones.
Pro tip Prefer small experiments that produce direct evidence.
Watch out Do not make irreversible bets solely from a directional signal.
In the wild
A product team sees an agent that can operate a browser for only 15 minutes and occasionally becomes distracted. Instead of dismissing it, the team identifies the strategic direction: assistants that observe and execute computer workflows. It projects improvements in duration, memory, and reliability, then tests one low-risk internal administrative process while monitoring accuracy.
→ The team gains practical experience early without depending on an immature system for critical work.
A SaaS company observes agents transferring information between spreadsheets, CRMs, and forms. It maps the second-order implication that users may increasingly interact through assistants rather than directly through software interfaces. The company prioritizes APIs, machine-readable documentation, permissions, and auditable actions alongside its human-facing interface.
→ The product remains usable when software consumption shifts from human clicks toward machine execution.
Common mistakes
Judging only the current demo
Rejecting an early release solely because it is unreliable obscures the direction in which the underlying capability is moving.
Confusing direction with certainty
A strategic signal supports preparation and experimentation, not an assumption that every projected outcome will occur.
Stopping at first-order use cases
Looking only at immediate conveniences misses changes to buyers, interfaces, workflows, and business models.
Is it for you?
Best for
It is best for founders, marketers, investors, and product leaders evaluating early releases in fast-moving markets.
Not ideal for
It is not ideal when a decision depends exclusively on the product's current production reliability.
From the transcript
“what people are failing to do is look at it and say this is a step towards the path this company is going down and…”
“they're not releasing toys they're releasing things that are directionally uh where they want to go”
“anything on a computer screen for the most part or a laptop will probably be automatable in the next two to three years”
From the episode
Claude's HUGE Double Update: Computer Control + Sonnet 3.5 (New)