Resource-Time Compression

Activate when: user says 'this will take years', 'we need to build this from scratch', 'we don't have the resources to move faster', 'how do we compress our timeline', 'competitors are already ahead and we can't catch up sequentially', or when a goal is achievable but the default sequential plan is too slow for the market window. Do NOT activate when: the bottleneck is a genuine sequential dependency that cannot be parallelized (e.g., regulatory approval must precede launch); or when required external resources do not yet exist and the problem requires first-principles innovation rather than resource configuration.

Overview

Most plans estimate how long each step takes and add them up — producing a multi-year sequential path that reflects a solo, resource-constrained default. Resource-time compression redesigns that path: access capabilities that already exist rather than building them, run steps in parallel, and skip steps entirely using the right partners, capital, talent, or platforms. Arriving 3 years earlier than competitors is not merely a 3-year advantage — earlier arrival compounds through faster learning, stronger network effects, and earlier monetization.

Cross-skill composition: Use AFTER gap analysis. Use WITH [shi-momentum] (borrowing momentum phase). Use BEFORE [okr-goal-setting] — set goals after mapping what resources can realistically be assembled.

---

When to Use

Use when: default sequential path is too slow for the competitive window; competitors are ahead and sequential catch-up produces permanent second place; capability gaps would take 2+ years to build internally but external providers have them; capital available and the question is where to deploy it for time compression.

When NOT to use: bottleneck is a genuine sequential dependency that cannot be parallelized; required external resources do not yet exist; organization lacks bandwidth to integrate multiple external resources; "compression" is cover for a non-strategic acquisition or partnership.

---

Coaching Novices (Adaptive Front Door)

• Engine mode: concrete case → run The Process directly.
• Coach mode: user equates speed with effort or has no concrete case → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. What it is: "Resource-time compression redesigns the path to a goal using resources you don't have to build — arriving 2-3 years earlier than the default plan."
2. Check fit: "Is there a goal mapped as a multi-year plan, with competitive pressure making the timeline too slow?" — If yes: applies.
3. Elicit real case: "What are the 3 longest steps? For each: is there anyone who already has that capability?" > [WAIT — do not advance until user responds]
4. Run The Process one step at a time starting with Step 1 — Default Path Mapping. > [WAIT — do not advance until user responds]
5. Name the payoff: "Every year of earlier arrival compounds — market position, learning, and revenue against competitors still on the default path." > [WAIT — do not advance until user responds]

---

The Process

Step 1 — Default Path Mapping: List every major step, its estimated duration, and its dependencies. Gate: each step must have a specific duration and an identifiable resource making it take that long.

Step 2 — Bottleneck Identification: Identify the 2-3 steps most constraining the total timeline: longest steps, most downstream dependencies, or on the critical path. Gate: draw the critical path explicitly before selecting bottlenecks.

Step 3 — Resource Discovery: For each bottleneck — who already has this capability? Check: Partners, Acquisitions, Platforms, Capital, Networks. For each candidate: Does it exist? Can it be accessed in timeframe? What is the access cost? What step does it compress? Gate: only include resources genuinely accessible in the relevant timeframe.

Step 4 — Path Redesign: Which steps now run in parallel? Which are eliminated? Which shrink because the resource provides infrastructure? Gate: the new path must be a genuinely different configuration, not the old path with optimistic numbers.

Step 5 — Compression Quantification: Calculate new vs. default timeline, time saved, and value of earlier arrival (revenue + market position + learning advantage, order-of-magnitude). Gate: if compression value < access cost, find cheaper resources or accept the default path.

Step 6 — Integration Risk Assessment: For each compression resource — what is the risk that integrating it creates more delay than it saves? Stop-rule: If required resources cannot be acquired within your timeframe, compress from what IS available. A 40% compression using real resources beats a 70% compression plan that cannot be executed.

Output: Time-Compressed Path Map — Goal · Default Path table (steps/duration/dependencies/bottleneck?) · Critical path bottlenecks · Resource Discovery table (bottleneck/type/resource/exists?/accessible?/cost/months saved) · Compressed Path table · Compression Value (time saved, value of earlier arrival, access cost, net) · Integration Risk Flags.

→ Method in Action: Edison's Menlo Park Laboratory (1876–1882)

---

Time Compression Packs

• Pack A — Tech Startup: Platform substitution (AWS, Stripe, Twilio) eliminates 12-36 months of infrastructure. Acqui-hire compresses team capability gaps from 18-36 months to 3-6 months. Trap: over-investing in proprietary infrastructure before validating the product hypothesis.
• Pack B — Enterprise: Capital + infrastructure but lacks entrepreneurial operating model — joint ventures, innovation labs co-located with startups, minority investments are the toolkit. Failure mode: launching compression mechanisms without a specific critical-path bottleneck mapped to each.
• Pack C — Individual / Founder: Compression through deliberate network construction — mentors and collaborators who already solved the problem you're about to spend 2 years on. Trap: confusing access (a meeting) with integration (consistently translating their knowledge into your capability).

→ Primary sources: references/sources.md

---

Applying It Well

1. Start with the default path — without a baseline you cannot quantify compression or find true bottlenecks.
2. Compress the critical path only — 80% of effort on the 2-3 bottleneck steps; ignore non-critical-path steps.
3. Distinguish access from integration — a signed agreement is access; compression happens when capability is actively deployed into your workflow.
4. Quantify the access cost — compression is only justified when time-value saved exceeds access cost. Design integration points explicitly before starting parallel tracks; more resources requires more management overhead.

---

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake move	Reality
[D] "We need to build this ourselves to understand it"	Understanding and having are different. A structured partnership provides operational understanding without building from scratch.
[D] "No partner has exactly what we need"	80% accessed externally + 20% built internally is usually faster than 100% built internally.
[D] "A partnership will take longer than just doing it ourselves"	Partnership setup: 1-3 months. Internal development of the same capability: 18-36 months. Do the math.
[D] "We'll lose IP if we work with partners"	IP risk is a negotiation problem, not a binary. Structured IP agreements are standard.
[D] "Our competitive advantage requires owning this capability"	The question is access, not ownership. Exclusive licensing and acquisition are valid forms of access.
[D] "We're moving fast enough already"	Fast enough relative to what — last year, or the competitive window?
[D] "Adding more resources will make things complicated"	Complexity is a management challenge, not a compression argument. Calculate value vs. integration overhead.
→ Add [O] entries here after each real use — paste the actual failure pattern	What went wrong and why

---

Red Flags

• Every step mapped as sequential when multiple could start simultaneously — planning default masquerading as necessity
• Compression resources announced but no specific critical-path step mapped to them — access without integration
• Compressed timeline set before resource configuration was designed — commitments without a mechanism
• Bottleneck analysis optimized the easiest-to-compress steps rather than the actual critical path
• Value of earlier arrival never calculated — compression has not been economically justified

Verification

• Default path mapped with specific duration estimates for each step?
• 2-3 critical-path bottlenecks identified (not just the easiest to compress)?
• For each bottleneck: external resource identified that exists and can be accessed in timeframe?
• Compressed path drawn explicitly showing parallel steps and eliminations?
• Access cost compared to value of time saved — net positive?
• Integration risks designed for before starting parallel tracks?
• Compressed path relies on currently existing resources only?

---

Part of deciqAI Knowledge Skills — 163 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/skills/resource-time-compression?utm_source=clawhub&utm_medium=marketplace&utm_campaign=knowledge-skills&utm_content=resource-time-compression · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.