diff --git a/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/README.mdx b/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/README.mdx new file mode 100644 index 0000000..b2ef3bb --- /dev/null +++ b/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/README.mdx @@ -0,0 +1,48 @@ +# Map the Tradeoffs + +👨‍💼 The narrow host-login plan from Exercise 3 solved one problem: returning +hosts can get back to schedules more reliably. But the broader pressure has not +gone away. + +Some people now want a wider accounts system because it sounds more +trustworthy, more professional, and more scalable for repeat usage. Others want +to preserve the product's low-friction advantage and avoid dragging account +complexity into flows that currently work. + +🧝‍♀️ Set the playground to `extra/03.improved-implementation`. Use the planning +artifacts you have already produced as context: + +- +- +- +- + +🐨 Create a dedicated +artifact that compares the competing directions in front of the team. + +At minimum, compare: + +1. The narrow host-focused path +2. A broader account/login expansion for repeat users + +Your map should cover: + +1. The priorities each path is trying to optimize +2. The success criteria each path would claim as justification +3. The likely harms or regression risks each path creates +4. The assumptions or evidence gaps hidden inside each argument +5. The mitigations that could reduce downside, if that path were chosen + +Requirements: + +- Keep the comparison grounded in the app's real flows on `/`, + `/s/{scheduleKey}`, and `/s/{scheduleKey}/{hostKey}`. +- Include finalized-plan rate, create-flow speed, attendee completion, trust, + and implementation/support cost somewhere in your analysis. +- Be explicit about which constraints are truly competing rather than merely + inconvenient. +- Do not collapse everything into one "balanced" answer yet. Surface the + tension first. + +💰 Good tradeoff work starts by making the conflict legible. If both options +sound equally good in your document, you have probably hidden the real cost. diff --git a/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/tradeoff-map.md b/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/tradeoff-map.md new file mode 100644 index 0000000..7ee5bec --- /dev/null +++ b/exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/tradeoff-map.md @@ -0,0 +1,43 @@ +# Tradeoff Map + +This document should make the competing constraints visible before the team +pretends the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: +- Which earlier decision or scope boundary is now under pressure: +- Which user outcomes are most at risk if the team gets this wrong: + +## Option A + +- Path name: +- What this path is trying to optimize: +- Success criteria this path would claim: +- Which flows or routes it touches most: +- Likely harms or regressions it introduces: +- Key assumptions or missing evidence: +- Mitigations if this path is chosen: + +## Option B + +- Path name: +- What this path is trying to optimize: +- Success criteria this path would claim: +- Which flows or routes it touches most: +- Likely harms or regressions it introduces: +- Key assumptions or missing evidence: +- Mitigations if this path is chosen: + +## Constraint collisions + +- Which priorities are directly in tension: +- Which route or workflow feels most fragile under this decision: +- Which costs are immediate versus delayed: +- Which downside is easiest for a team to underestimate: + +## Open questions + +- What evidence would most reduce uncertainty: +- What would make the broader path clearly worth it: +- What would make the narrower path clearly insufficient: diff --git a/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/README.mdx b/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/README.mdx new file mode 100644 index 0000000..f65720c --- /dev/null +++ b/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/README.mdx @@ -0,0 +1,12 @@ +# Map the Tradeoffs + +👨‍💼 Nice work. You made the conflict explicit instead of letting the team talk +about "better trust" and "low friction" as if they were automatically +compatible. + +🦉 This is the judgment move this exercise is training. Strong engineers do not +hide the cost of a more ambitious path, and they do not romanticize simplicity +without naming what it fails to solve. They force both sides of the tradeoff to +be comparable. + +In the next step, you'll stop mapping and start deciding. diff --git a/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/tradeoff-map.md b/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/tradeoff-map.md new file mode 100644 index 0000000..a866781 --- /dev/null +++ b/exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/tradeoff-map.md @@ -0,0 +1,126 @@ +# Tradeoff Map + +This document makes the competing constraints visible before the team pretends +the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: + - The team can now justify a narrow host-login improvement, but stakeholders + are pushing to go further and add broader accounts for repeat users. +- Which earlier decision or scope boundary is now under pressure: + - The exercise 2 decision to avoid a full account system and the exercise 3 + plan to keep login narrowly host-focused. +- Which user outcomes are most at risk if the team gets this wrong: + - Finalized-plan rate + - Create-flow completion speed + - Attendee submission completion + - Host trust that they can reliably get back to the right schedule + +## Option A + +- Path name: + - Stay narrow: host-focused continuity improvement only +- What this path is trying to optimize: + - Better return access for hosts + - Lower risk to the create and attendee flows + - Smaller implementation and support surface area +- Success criteria this path would claim: + - Returning hosts recover schedules more reliably + - Finalized-plan rate holds steady or improves + - Create and attendee completion remain effectively unchanged +- Which flows or routes it touches most: + - `/s/{scheduleKey}/{hostKey}` for host management and claiming + - A host-only login entry point + - Optional post-create continuity prompts on `/` +- Likely harms or regressions it introduces: + - Some repeat users may still feel the product lacks the polish or permanence + of a full account system + - Hosts may still need to understand both host-link and account-based access + - The narrower move may not fully solve long-term repeat-usage expectations +- Key assumptions or missing evidence: + - The real pain is primarily host return access, not universal identity + - Most attendee value still comes from fast, no-account participation + - The product does not yet need cross-schedule history badly enough to justify + broader scope +- Mitigations if this path is chosen: + - Make host-link purpose and claiming behavior clearer in the UI + - Keep login optional and host-only + - Measure host-return success and revisit if the narrow path proves + insufficient + +## Option B + +- Path name: + - Expand to broader repeat-user accounts +- What this path is trying to optimize: + - Stronger sense of trust and permanence + - Easier schedule recovery across multiple visits + - Future optionality for identity-based features +- Success criteria this path would claim: + - More returning users can find schedules without saved links + - Repeat usage feels more durable and professional + - The product gains a clearer long-term identity model +- Which flows or routes it touches most: + - `/` because account creation or login prompts tend to leak into creation + - `/s/{scheduleKey}` because attendee identity expectations become harder to + avoid + - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with + authenticated ownership + - New auth, recovery, and account-management routes +- Likely harms or regressions it introduces: + - Create-flow friction rises as account concepts compete with quick schedule + setup + - Attendee completion may drop if the public flow feels more account-shaped or + less obviously guest-friendly + - Support and implementation cost grow materially because the team now owns + auth, recovery, identity state, and confusion between access paths + - Route purpose becomes easier to blur across public, host-only, and account + surfaces +- Key assumptions or missing evidence: + - More identity always equals more trust in this product category + - Repeat users actually want accounts enough to offset the added friction + - The team can add broader auth without harming mobile-friendly participation + - Future optionality is valuable enough right now to justify present cost +- Mitigations if this path is chosen: + - Keep attendee participation explicitly guest-friendly + - Preserve host-link fallback during rollout + - Gate account prompts away from the first-create and first-respond moments + - Add instrumentation and rollback triggers before broad exposure + +## Constraint collisions + +- Which priorities are directly in tension: + - Host-return reliability and future trust signals versus low-friction create + and attendee completion + - Product permanence versus route clarity and workflow simplicity + - Future optionality versus current implementation and support cost +- Which route or workflow feels most fragile under this decision: + - `/s/{scheduleKey}` is the most fragile because its value comes from being + obviously lightweight and guest-oriented +- Which costs are immediate versus delayed: + - Immediate costs: auth complexity, support burden, route confusion, create + friction + - Delayed benefits: stronger repeat-user continuity and future identity-based + product expansion +- Which downside is easiest for a team to underestimate: + - Leakage of account expectations into flows that currently succeed precisely + because they are simple and no-account + +## Open questions + +- What evidence would most reduce uncertainty: + - How often hosts fail to return without the private host link + - Whether attendee completion drops when identity language is introduced + - Whether repeat users in this social-planning context actually expect account + persistence +- What would make the broader path clearly worth it: + - Repeated evidence that host-return problems materially hurt finalized-plan + rate and cannot be solved by a host-only path + - Clear demand for cross-schedule history or identity-based recovery from a + meaningful share of active users +- What would make the narrower path clearly insufficient: + - Hosts still fail to re-find schedules even after a careful host-only + continuity improvement + - The product proves that repeat-user continuity matters more than + ultra-lightweight first-use participation diff --git a/exercises/04.conflicting-constraints/02.problem.make-the-call/README.mdx b/exercises/04.conflicting-constraints/02.problem.make-the-call/README.mdx new file mode 100644 index 0000000..41ac63a --- /dev/null +++ b/exercises/04.conflicting-constraints/02.problem.make-the-call/README.mdx @@ -0,0 +1,34 @@ +# Make the Call + +👨‍💼 You have mapped the conflict. Now the team needs a decision, not another +round of vague discussion. + +🧝‍♀️ Use your existing to +create a dedicated +artifact. + +This is the moment to choose which tradeoff the team should make now and to +justify it clearly enough that other engineers, product partners, and future +you can understand why. + +Your decision brief should cover: + +1. Which path should ship now +2. Why that tradeoff is correct at the current product stage +3. The success criteria that would prove the decision was right +4. The downside you are knowingly accepting +5. The mitigations required to keep the chosen path safe +6. What stays explicitly deferred and what evidence would reopen it later +7. The rollback boundary if the decision harms the product + +Requirements: + +- Use the competing constraints from your tradeoff map rather than re-framing + the problem from scratch. +- Name the constraint you are prioritizing most and the constraint you are + willing to disappoint. +- Keep the reasoning grounded in the scheduler's real routes and flows. +- Do not defend the decision with vague future optionality alone. + +💰 Tradeoff articulation is not "everyone is right." It is "this cost is worth +paying now, and this other cost is not." diff --git a/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-decision.md b/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-decision.md new file mode 100644 index 0000000..410c63a --- /dev/null +++ b/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-decision.md @@ -0,0 +1,35 @@ +# Tradeoff Decision + +This brief should turn the tradeoff map into a clear recommendation the team can +act on. + +## Decision + +- Which path should ship now: +- Why this is the right tradeoff at the current product stage: +- Which constraint are we prioritizing most: +- Which constraint are we knowingly not maximizing: + +## Success criteria + +- What must improve if this decision is right: +- What must not regress while we pursue it: +- Which indicators or behaviors would give us confidence: + +## Accepted downside + +- What cost are we deliberately accepting: +- Why that cost is preferable to the alternative right now: +- Which users or workflows are least well served by this decision: + +## Mitigations + +- How we reduce the main downside of the chosen path: +- Which guardrails or rollout choices are required: +- What fallback or rollback boundary we need: + +## Deferred path + +- What remains deferred for now: +- What evidence would reopen that path later: +- What would make us regret this decision: diff --git a/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-map.md b/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-map.md new file mode 100644 index 0000000..a866781 --- /dev/null +++ b/exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-map.md @@ -0,0 +1,126 @@ +# Tradeoff Map + +This document makes the competing constraints visible before the team pretends +the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: + - The team can now justify a narrow host-login improvement, but stakeholders + are pushing to go further and add broader accounts for repeat users. +- Which earlier decision or scope boundary is now under pressure: + - The exercise 2 decision to avoid a full account system and the exercise 3 + plan to keep login narrowly host-focused. +- Which user outcomes are most at risk if the team gets this wrong: + - Finalized-plan rate + - Create-flow completion speed + - Attendee submission completion + - Host trust that they can reliably get back to the right schedule + +## Option A + +- Path name: + - Stay narrow: host-focused continuity improvement only +- What this path is trying to optimize: + - Better return access for hosts + - Lower risk to the create and attendee flows + - Smaller implementation and support surface area +- Success criteria this path would claim: + - Returning hosts recover schedules more reliably + - Finalized-plan rate holds steady or improves + - Create and attendee completion remain effectively unchanged +- Which flows or routes it touches most: + - `/s/{scheduleKey}/{hostKey}` for host management and claiming + - A host-only login entry point + - Optional post-create continuity prompts on `/` +- Likely harms or regressions it introduces: + - Some repeat users may still feel the product lacks the polish or permanence + of a full account system + - Hosts may still need to understand both host-link and account-based access + - The narrower move may not fully solve long-term repeat-usage expectations +- Key assumptions or missing evidence: + - The real pain is primarily host return access, not universal identity + - Most attendee value still comes from fast, no-account participation + - The product does not yet need cross-schedule history badly enough to justify + broader scope +- Mitigations if this path is chosen: + - Make host-link purpose and claiming behavior clearer in the UI + - Keep login optional and host-only + - Measure host-return success and revisit if the narrow path proves + insufficient + +## Option B + +- Path name: + - Expand to broader repeat-user accounts +- What this path is trying to optimize: + - Stronger sense of trust and permanence + - Easier schedule recovery across multiple visits + - Future optionality for identity-based features +- Success criteria this path would claim: + - More returning users can find schedules without saved links + - Repeat usage feels more durable and professional + - The product gains a clearer long-term identity model +- Which flows or routes it touches most: + - `/` because account creation or login prompts tend to leak into creation + - `/s/{scheduleKey}` because attendee identity expectations become harder to + avoid + - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with + authenticated ownership + - New auth, recovery, and account-management routes +- Likely harms or regressions it introduces: + - Create-flow friction rises as account concepts compete with quick schedule + setup + - Attendee completion may drop if the public flow feels more account-shaped or + less obviously guest-friendly + - Support and implementation cost grow materially because the team now owns + auth, recovery, identity state, and confusion between access paths + - Route purpose becomes easier to blur across public, host-only, and account + surfaces +- Key assumptions or missing evidence: + - More identity always equals more trust in this product category + - Repeat users actually want accounts enough to offset the added friction + - The team can add broader auth without harming mobile-friendly participation + - Future optionality is valuable enough right now to justify present cost +- Mitigations if this path is chosen: + - Keep attendee participation explicitly guest-friendly + - Preserve host-link fallback during rollout + - Gate account prompts away from the first-create and first-respond moments + - Add instrumentation and rollback triggers before broad exposure + +## Constraint collisions + +- Which priorities are directly in tension: + - Host-return reliability and future trust signals versus low-friction create + and attendee completion + - Product permanence versus route clarity and workflow simplicity + - Future optionality versus current implementation and support cost +- Which route or workflow feels most fragile under this decision: + - `/s/{scheduleKey}` is the most fragile because its value comes from being + obviously lightweight and guest-oriented +- Which costs are immediate versus delayed: + - Immediate costs: auth complexity, support burden, route confusion, create + friction + - Delayed benefits: stronger repeat-user continuity and future identity-based + product expansion +- Which downside is easiest for a team to underestimate: + - Leakage of account expectations into flows that currently succeed precisely + because they are simple and no-account + +## Open questions + +- What evidence would most reduce uncertainty: + - How often hosts fail to return without the private host link + - Whether attendee completion drops when identity language is introduced + - Whether repeat users in this social-planning context actually expect account + persistence +- What would make the broader path clearly worth it: + - Repeated evidence that host-return problems materially hurt finalized-plan + rate and cannot be solved by a host-only path + - Clear demand for cross-schedule history or identity-based recovery from a + meaningful share of active users +- What would make the narrower path clearly insufficient: + - Hosts still fail to re-find schedules even after a careful host-only + continuity improvement + - The product proves that repeat-user continuity matters more than + ultra-lightweight first-use participation diff --git a/exercises/04.conflicting-constraints/02.solution.make-the-call/README.mdx b/exercises/04.conflicting-constraints/02.solution.make-the-call/README.mdx new file mode 100644 index 0000000..a45ce00 --- /dev/null +++ b/exercises/04.conflicting-constraints/02.solution.make-the-call/README.mdx @@ -0,0 +1,12 @@ +# Make the Call + +👨‍💼 Nice work. You chose deliberately instead of letting the team drift toward +the biggest-sounding solution by default. + +🦉 This is where engineering judgment becomes legible. A good decision memo does +not claim the chosen path has no downside. It explains which downside is worth +accepting now, which one is too dangerous, and how the team will know if that +logic stops being true. + +In the next step, you'll pressure-test the decision so it can survive future +pushback instead of collapsing into vague compromise. diff --git a/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-decision.md b/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-decision.md new file mode 100644 index 0000000..e292376 --- /dev/null +++ b/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-decision.md @@ -0,0 +1,80 @@ +# Tradeoff Decision + +This brief turns the tradeoff map into a clear recommendation the team can act +on. + +## Decision + +- Which path should ship now: + - Ship the narrow host-focused continuity path now and keep broader + repeat-user accounts deferred. +- Why this is the right tradeoff at the current product stage: + - The product still wins on low-friction scheduling. The most credible problem + we have is host return reliability, not universal identity. A broader + account move would charge complexity across all major flows before the + product has earned that cost. +- Which constraint are we prioritizing most: + - Protect create-flow speed and attendee completion while improving host + return reliability enough to help finalized-plan rate. +- Which constraint are we knowingly not maximizing: + - We are not maximizing long-term identity optionality or the polish signal of + a full account model yet. + +## Success criteria + +- What must improve if this decision is right: + - Returning hosts re-find and manage schedules more reliably than before. +- What must not regress while we pursue it: + - Schedule creation remains lightweight and skippable past any login prompts. + - Attendee participation on `/s/{scheduleKey}` remains obviously + guest-friendly and fast to complete. + - Finalized-plan rate does not fall because the access model becomes more + confusing. +- Which indicators or behaviors would give us confidence: + - Host-return success rises. + - Claim or login completion for hosts is healthy without displacing host-link + fallback usage. + - Create abandonment and attendee drop-off remain flat. + +## Accepted downside + +- What cost are we deliberately accepting: + - Some repeat users may still feel the product lacks the permanence and + convenience of a broader account system. +- Why that cost is preferable to the alternative right now: + - It is safer to under-build identity than to over-build it into the create + and attendee flows that currently make the product work. +- Which users or workflows are least well served by this decision: + - Power users who want cross-schedule history or universal schedule recovery. + +## Mitigations + +- How we reduce the main downside of the chosen path: + - Improve host-link clarity, make claiming easy, and ensure returning hosts + can get back to the right schedule without generic account chrome. +- Which guardrails or rollout choices are required: + - Keep login optional and host-only. + - Preserve host-link fallback. + - Keep account concepts out of `/s/{scheduleKey}`. + - Make any post-create continuity prompt secondary and easy to dismiss. +- What fallback or rollback boundary we need: + - If create completion, attendee completion, or finalized-plan rate worsens + after rollout, remove the host-login prompt first and fall back to the + host-link model while keeping any claimed ownership data intact. + +## Deferred path + +- What remains deferred for now: + - Participant accounts + - Cross-schedule history for all users + - Broader account-management surfaces + - Identity-based product expansion justified mainly by future optionality +- What evidence would reopen that path later: + - The narrow host path fails to solve return reliability. + - Repeat-user continuity becomes a demonstrated product need across a + meaningful share of usage. + - Broader identity can be introduced without materially harming guest + participation. +- What would make us regret this decision: + - Discovering that the product's next stage depends far more on repeat-user + continuity than on frictionless first-time participation. diff --git a/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-map.md b/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-map.md new file mode 100644 index 0000000..a866781 --- /dev/null +++ b/exercises/04.conflicting-constraints/02.solution.make-the-call/tradeoff-map.md @@ -0,0 +1,126 @@ +# Tradeoff Map + +This document makes the competing constraints visible before the team pretends +the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: + - The team can now justify a narrow host-login improvement, but stakeholders + are pushing to go further and add broader accounts for repeat users. +- Which earlier decision or scope boundary is now under pressure: + - The exercise 2 decision to avoid a full account system and the exercise 3 + plan to keep login narrowly host-focused. +- Which user outcomes are most at risk if the team gets this wrong: + - Finalized-plan rate + - Create-flow completion speed + - Attendee submission completion + - Host trust that they can reliably get back to the right schedule + +## Option A + +- Path name: + - Stay narrow: host-focused continuity improvement only +- What this path is trying to optimize: + - Better return access for hosts + - Lower risk to the create and attendee flows + - Smaller implementation and support surface area +- Success criteria this path would claim: + - Returning hosts recover schedules more reliably + - Finalized-plan rate holds steady or improves + - Create and attendee completion remain effectively unchanged +- Which flows or routes it touches most: + - `/s/{scheduleKey}/{hostKey}` for host management and claiming + - A host-only login entry point + - Optional post-create continuity prompts on `/` +- Likely harms or regressions it introduces: + - Some repeat users may still feel the product lacks the polish or permanence + of a full account system + - Hosts may still need to understand both host-link and account-based access + - The narrower move may not fully solve long-term repeat-usage expectations +- Key assumptions or missing evidence: + - The real pain is primarily host return access, not universal identity + - Most attendee value still comes from fast, no-account participation + - The product does not yet need cross-schedule history badly enough to justify + broader scope +- Mitigations if this path is chosen: + - Make host-link purpose and claiming behavior clearer in the UI + - Keep login optional and host-only + - Measure host-return success and revisit if the narrow path proves + insufficient + +## Option B + +- Path name: + - Expand to broader repeat-user accounts +- What this path is trying to optimize: + - Stronger sense of trust and permanence + - Easier schedule recovery across multiple visits + - Future optionality for identity-based features +- Success criteria this path would claim: + - More returning users can find schedules without saved links + - Repeat usage feels more durable and professional + - The product gains a clearer long-term identity model +- Which flows or routes it touches most: + - `/` because account creation or login prompts tend to leak into creation + - `/s/{scheduleKey}` because attendee identity expectations become harder to + avoid + - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with + authenticated ownership + - New auth, recovery, and account-management routes +- Likely harms or regressions it introduces: + - Create-flow friction rises as account concepts compete with quick schedule + setup + - Attendee completion may drop if the public flow feels more account-shaped or + less obviously guest-friendly + - Support and implementation cost grow materially because the team now owns + auth, recovery, identity state, and confusion between access paths + - Route purpose becomes easier to blur across public, host-only, and account + surfaces +- Key assumptions or missing evidence: + - More identity always equals more trust in this product category + - Repeat users actually want accounts enough to offset the added friction + - The team can add broader auth without harming mobile-friendly participation + - Future optionality is valuable enough right now to justify present cost +- Mitigations if this path is chosen: + - Keep attendee participation explicitly guest-friendly + - Preserve host-link fallback during rollout + - Gate account prompts away from the first-create and first-respond moments + - Add instrumentation and rollback triggers before broad exposure + +## Constraint collisions + +- Which priorities are directly in tension: + - Host-return reliability and future trust signals versus low-friction create + and attendee completion + - Product permanence versus route clarity and workflow simplicity + - Future optionality versus current implementation and support cost +- Which route or workflow feels most fragile under this decision: + - `/s/{scheduleKey}` is the most fragile because its value comes from being + obviously lightweight and guest-oriented +- Which costs are immediate versus delayed: + - Immediate costs: auth complexity, support burden, route confusion, create + friction + - Delayed benefits: stronger repeat-user continuity and future identity-based + product expansion +- Which downside is easiest for a team to underestimate: + - Leakage of account expectations into flows that currently succeed precisely + because they are simple and no-account + +## Open questions + +- What evidence would most reduce uncertainty: + - How often hosts fail to return without the private host link + - Whether attendee completion drops when identity language is introduced + - Whether repeat users in this social-planning context actually expect account + persistence +- What would make the broader path clearly worth it: + - Repeated evidence that host-return problems materially hurt finalized-plan + rate and cannot be solved by a host-only path + - Clear demand for cross-schedule history or identity-based recovery from a + meaningful share of active users +- What would make the narrower path clearly insufficient: + - Hosts still fail to re-find schedules even after a careful host-only + continuity improvement + - The product proves that repeat-user continuity matters more than + ultra-lightweight first-use participation diff --git a/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/README.mdx b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/README.mdx new file mode 100644 index 0000000..0f38a6a --- /dev/null +++ b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/README.mdx @@ -0,0 +1,36 @@ +# Pressure-Test the Decision + +👨‍💼 The real test of a tradeoff is whether it survives pressure after the +meeting. Stakeholders will keep asking why the team is not simply doing the +bigger thing now. + +🧝‍♀️ Use your existing + +- +- + +to create a dedicated +artifact. + +This review should pressure-test the decision you just made. Treat it like a +future-facing note to the team explaining how the chosen path could still fail, +what protections it needs, and what evidence would force a revisit. + +Your review should cover: + +1. The main ways the chosen tradeoff could still hurt the product +2. The signals that would tell you the team picked the wrong side of the + constraint +3. The mitigations or rollout conditions that are non-negotiable +4. What would trigger a revision, narrowing, or rollback +5. What future evidence would justify reopening the deferred path + +Requirements: + +- Keep the pressure test anchored in the real user flows and route boundaries. +- Name at least one failure mode for create, attendee response, and host return. +- Be explicit about what you would change first if the decision starts going bad. +- Do not restate the decision memo. Stress it until you can see where it breaks. + +💰 Judgment gets better when decisions can survive contact with future evidence, +not just the confidence of the person who wrote the first brief. diff --git a/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-decision.md b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-decision.md new file mode 100644 index 0000000..e292376 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-decision.md @@ -0,0 +1,80 @@ +# Tradeoff Decision + +This brief turns the tradeoff map into a clear recommendation the team can act +on. + +## Decision + +- Which path should ship now: + - Ship the narrow host-focused continuity path now and keep broader + repeat-user accounts deferred. +- Why this is the right tradeoff at the current product stage: + - The product still wins on low-friction scheduling. The most credible problem + we have is host return reliability, not universal identity. A broader + account move would charge complexity across all major flows before the + product has earned that cost. +- Which constraint are we prioritizing most: + - Protect create-flow speed and attendee completion while improving host + return reliability enough to help finalized-plan rate. +- Which constraint are we knowingly not maximizing: + - We are not maximizing long-term identity optionality or the polish signal of + a full account model yet. + +## Success criteria + +- What must improve if this decision is right: + - Returning hosts re-find and manage schedules more reliably than before. +- What must not regress while we pursue it: + - Schedule creation remains lightweight and skippable past any login prompts. + - Attendee participation on `/s/{scheduleKey}` remains obviously + guest-friendly and fast to complete. + - Finalized-plan rate does not fall because the access model becomes more + confusing. +- Which indicators or behaviors would give us confidence: + - Host-return success rises. + - Claim or login completion for hosts is healthy without displacing host-link + fallback usage. + - Create abandonment and attendee drop-off remain flat. + +## Accepted downside + +- What cost are we deliberately accepting: + - Some repeat users may still feel the product lacks the permanence and + convenience of a broader account system. +- Why that cost is preferable to the alternative right now: + - It is safer to under-build identity than to over-build it into the create + and attendee flows that currently make the product work. +- Which users or workflows are least well served by this decision: + - Power users who want cross-schedule history or universal schedule recovery. + +## Mitigations + +- How we reduce the main downside of the chosen path: + - Improve host-link clarity, make claiming easy, and ensure returning hosts + can get back to the right schedule without generic account chrome. +- Which guardrails or rollout choices are required: + - Keep login optional and host-only. + - Preserve host-link fallback. + - Keep account concepts out of `/s/{scheduleKey}`. + - Make any post-create continuity prompt secondary and easy to dismiss. +- What fallback or rollback boundary we need: + - If create completion, attendee completion, or finalized-plan rate worsens + after rollout, remove the host-login prompt first and fall back to the + host-link model while keeping any claimed ownership data intact. + +## Deferred path + +- What remains deferred for now: + - Participant accounts + - Cross-schedule history for all users + - Broader account-management surfaces + - Identity-based product expansion justified mainly by future optionality +- What evidence would reopen that path later: + - The narrow host path fails to solve return reliability. + - Repeat-user continuity becomes a demonstrated product need across a + meaningful share of usage. + - Broader identity can be introduced without materially harming guest + participation. +- What would make us regret this decision: + - Discovering that the product's next stage depends far more on repeat-user + continuity than on frictionless first-time participation. diff --git a/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-map.md b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-map.md new file mode 100644 index 0000000..a866781 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-map.md @@ -0,0 +1,126 @@ +# Tradeoff Map + +This document makes the competing constraints visible before the team pretends +the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: + - The team can now justify a narrow host-login improvement, but stakeholders + are pushing to go further and add broader accounts for repeat users. +- Which earlier decision or scope boundary is now under pressure: + - The exercise 2 decision to avoid a full account system and the exercise 3 + plan to keep login narrowly host-focused. +- Which user outcomes are most at risk if the team gets this wrong: + - Finalized-plan rate + - Create-flow completion speed + - Attendee submission completion + - Host trust that they can reliably get back to the right schedule + +## Option A + +- Path name: + - Stay narrow: host-focused continuity improvement only +- What this path is trying to optimize: + - Better return access for hosts + - Lower risk to the create and attendee flows + - Smaller implementation and support surface area +- Success criteria this path would claim: + - Returning hosts recover schedules more reliably + - Finalized-plan rate holds steady or improves + - Create and attendee completion remain effectively unchanged +- Which flows or routes it touches most: + - `/s/{scheduleKey}/{hostKey}` for host management and claiming + - A host-only login entry point + - Optional post-create continuity prompts on `/` +- Likely harms or regressions it introduces: + - Some repeat users may still feel the product lacks the polish or permanence + of a full account system + - Hosts may still need to understand both host-link and account-based access + - The narrower move may not fully solve long-term repeat-usage expectations +- Key assumptions or missing evidence: + - The real pain is primarily host return access, not universal identity + - Most attendee value still comes from fast, no-account participation + - The product does not yet need cross-schedule history badly enough to justify + broader scope +- Mitigations if this path is chosen: + - Make host-link purpose and claiming behavior clearer in the UI + - Keep login optional and host-only + - Measure host-return success and revisit if the narrow path proves + insufficient + +## Option B + +- Path name: + - Expand to broader repeat-user accounts +- What this path is trying to optimize: + - Stronger sense of trust and permanence + - Easier schedule recovery across multiple visits + - Future optionality for identity-based features +- Success criteria this path would claim: + - More returning users can find schedules without saved links + - Repeat usage feels more durable and professional + - The product gains a clearer long-term identity model +- Which flows or routes it touches most: + - `/` because account creation or login prompts tend to leak into creation + - `/s/{scheduleKey}` because attendee identity expectations become harder to + avoid + - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with + authenticated ownership + - New auth, recovery, and account-management routes +- Likely harms or regressions it introduces: + - Create-flow friction rises as account concepts compete with quick schedule + setup + - Attendee completion may drop if the public flow feels more account-shaped or + less obviously guest-friendly + - Support and implementation cost grow materially because the team now owns + auth, recovery, identity state, and confusion between access paths + - Route purpose becomes easier to blur across public, host-only, and account + surfaces +- Key assumptions or missing evidence: + - More identity always equals more trust in this product category + - Repeat users actually want accounts enough to offset the added friction + - The team can add broader auth without harming mobile-friendly participation + - Future optionality is valuable enough right now to justify present cost +- Mitigations if this path is chosen: + - Keep attendee participation explicitly guest-friendly + - Preserve host-link fallback during rollout + - Gate account prompts away from the first-create and first-respond moments + - Add instrumentation and rollback triggers before broad exposure + +## Constraint collisions + +- Which priorities are directly in tension: + - Host-return reliability and future trust signals versus low-friction create + and attendee completion + - Product permanence versus route clarity and workflow simplicity + - Future optionality versus current implementation and support cost +- Which route or workflow feels most fragile under this decision: + - `/s/{scheduleKey}` is the most fragile because its value comes from being + obviously lightweight and guest-oriented +- Which costs are immediate versus delayed: + - Immediate costs: auth complexity, support burden, route confusion, create + friction + - Delayed benefits: stronger repeat-user continuity and future identity-based + product expansion +- Which downside is easiest for a team to underestimate: + - Leakage of account expectations into flows that currently succeed precisely + because they are simple and no-account + +## Open questions + +- What evidence would most reduce uncertainty: + - How often hosts fail to return without the private host link + - Whether attendee completion drops when identity language is introduced + - Whether repeat users in this social-planning context actually expect account + persistence +- What would make the broader path clearly worth it: + - Repeated evidence that host-return problems materially hurt finalized-plan + rate and cannot be solved by a host-only path + - Clear demand for cross-schedule history or identity-based recovery from a + meaningful share of active users +- What would make the narrower path clearly insufficient: + - Hosts still fail to re-find schedules even after a careful host-only + continuity improvement + - The product proves that repeat-user continuity matters more than + ultra-lightweight first-use participation diff --git a/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-review.md b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-review.md new file mode 100644 index 0000000..04256d1 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.problem.pressure-test-the-decision/tradeoff-review.md @@ -0,0 +1,34 @@ +# Tradeoff Review + +This review should pressure-test the chosen tradeoff and define how the team +would respond if the decision starts failing in practice. + +## Failure modes + +- How could the chosen path still hurt schedule creation: +- How could the chosen path still hurt attendee participation: +- How could the chosen path still hurt host return or finalization: + +## Signals to watch + +- What would tell us we picked the wrong side of the tradeoff: +- Which behavioral or product signals matter most: +- Which signal would make you worry first: + +## Required protections + +- Which mitigations are non-negotiable for the chosen path: +- What rollout conditions or guardrails must be present: +- What must stay unchanged to protect user trust: + +## Revision and rollback + +- What would you narrow or change first if things go badly: +- What is the rollback boundary: +- What would stay worth keeping even if the rollout underperforms: + +## Revisit triggers + +- What future evidence would justify reopening the deferred path: +- What would have to become true for the bigger option to be the better + tradeoff: diff --git a/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/README.mdx b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/README.mdx new file mode 100644 index 0000000..b34322e --- /dev/null +++ b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/README.mdx @@ -0,0 +1,11 @@ +# Pressure-Test the Decision + +👨‍💼 Nice work. You did not stop at "we made a call." You defined how the team +would know whether that call was still protecting the product. + +🦉 This is what separates judgment from taste. Good engineers do not just pick a +direction; they specify the conditions under which they would narrow, revise, +or reverse it. + +The exercise is complete once the tradeoff, its risks, and its revision +boundary are all explicit. diff --git a/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-decision.md b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-decision.md new file mode 100644 index 0000000..e292376 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-decision.md @@ -0,0 +1,80 @@ +# Tradeoff Decision + +This brief turns the tradeoff map into a clear recommendation the team can act +on. + +## Decision + +- Which path should ship now: + - Ship the narrow host-focused continuity path now and keep broader + repeat-user accounts deferred. +- Why this is the right tradeoff at the current product stage: + - The product still wins on low-friction scheduling. The most credible problem + we have is host return reliability, not universal identity. A broader + account move would charge complexity across all major flows before the + product has earned that cost. +- Which constraint are we prioritizing most: + - Protect create-flow speed and attendee completion while improving host + return reliability enough to help finalized-plan rate. +- Which constraint are we knowingly not maximizing: + - We are not maximizing long-term identity optionality or the polish signal of + a full account model yet. + +## Success criteria + +- What must improve if this decision is right: + - Returning hosts re-find and manage schedules more reliably than before. +- What must not regress while we pursue it: + - Schedule creation remains lightweight and skippable past any login prompts. + - Attendee participation on `/s/{scheduleKey}` remains obviously + guest-friendly and fast to complete. + - Finalized-plan rate does not fall because the access model becomes more + confusing. +- Which indicators or behaviors would give us confidence: + - Host-return success rises. + - Claim or login completion for hosts is healthy without displacing host-link + fallback usage. + - Create abandonment and attendee drop-off remain flat. + +## Accepted downside + +- What cost are we deliberately accepting: + - Some repeat users may still feel the product lacks the permanence and + convenience of a broader account system. +- Why that cost is preferable to the alternative right now: + - It is safer to under-build identity than to over-build it into the create + and attendee flows that currently make the product work. +- Which users or workflows are least well served by this decision: + - Power users who want cross-schedule history or universal schedule recovery. + +## Mitigations + +- How we reduce the main downside of the chosen path: + - Improve host-link clarity, make claiming easy, and ensure returning hosts + can get back to the right schedule without generic account chrome. +- Which guardrails or rollout choices are required: + - Keep login optional and host-only. + - Preserve host-link fallback. + - Keep account concepts out of `/s/{scheduleKey}`. + - Make any post-create continuity prompt secondary and easy to dismiss. +- What fallback or rollback boundary we need: + - If create completion, attendee completion, or finalized-plan rate worsens + after rollout, remove the host-login prompt first and fall back to the + host-link model while keeping any claimed ownership data intact. + +## Deferred path + +- What remains deferred for now: + - Participant accounts + - Cross-schedule history for all users + - Broader account-management surfaces + - Identity-based product expansion justified mainly by future optionality +- What evidence would reopen that path later: + - The narrow host path fails to solve return reliability. + - Repeat-user continuity becomes a demonstrated product need across a + meaningful share of usage. + - Broader identity can be introduced without materially harming guest + participation. +- What would make us regret this decision: + - Discovering that the product's next stage depends far more on repeat-user + continuity than on frictionless first-time participation. diff --git a/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-map.md b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-map.md new file mode 100644 index 0000000..a866781 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-map.md @@ -0,0 +1,126 @@ +# Tradeoff Map + +This document makes the competing constraints visible before the team pretends +the decision is obvious. + +## Decision context + +- What new pressure or request is creating this conflict: + - The team can now justify a narrow host-login improvement, but stakeholders + are pushing to go further and add broader accounts for repeat users. +- Which earlier decision or scope boundary is now under pressure: + - The exercise 2 decision to avoid a full account system and the exercise 3 + plan to keep login narrowly host-focused. +- Which user outcomes are most at risk if the team gets this wrong: + - Finalized-plan rate + - Create-flow completion speed + - Attendee submission completion + - Host trust that they can reliably get back to the right schedule + +## Option A + +- Path name: + - Stay narrow: host-focused continuity improvement only +- What this path is trying to optimize: + - Better return access for hosts + - Lower risk to the create and attendee flows + - Smaller implementation and support surface area +- Success criteria this path would claim: + - Returning hosts recover schedules more reliably + - Finalized-plan rate holds steady or improves + - Create and attendee completion remain effectively unchanged +- Which flows or routes it touches most: + - `/s/{scheduleKey}/{hostKey}` for host management and claiming + - A host-only login entry point + - Optional post-create continuity prompts on `/` +- Likely harms or regressions it introduces: + - Some repeat users may still feel the product lacks the polish or permanence + of a full account system + - Hosts may still need to understand both host-link and account-based access + - The narrower move may not fully solve long-term repeat-usage expectations +- Key assumptions or missing evidence: + - The real pain is primarily host return access, not universal identity + - Most attendee value still comes from fast, no-account participation + - The product does not yet need cross-schedule history badly enough to justify + broader scope +- Mitigations if this path is chosen: + - Make host-link purpose and claiming behavior clearer in the UI + - Keep login optional and host-only + - Measure host-return success and revisit if the narrow path proves + insufficient + +## Option B + +- Path name: + - Expand to broader repeat-user accounts +- What this path is trying to optimize: + - Stronger sense of trust and permanence + - Easier schedule recovery across multiple visits + - Future optionality for identity-based features +- Success criteria this path would claim: + - More returning users can find schedules without saved links + - Repeat usage feels more durable and professional + - The product gains a clearer long-term identity model +- Which flows or routes it touches most: + - `/` because account creation or login prompts tend to leak into creation + - `/s/{scheduleKey}` because attendee identity expectations become harder to + avoid + - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with + authenticated ownership + - New auth, recovery, and account-management routes +- Likely harms or regressions it introduces: + - Create-flow friction rises as account concepts compete with quick schedule + setup + - Attendee completion may drop if the public flow feels more account-shaped or + less obviously guest-friendly + - Support and implementation cost grow materially because the team now owns + auth, recovery, identity state, and confusion between access paths + - Route purpose becomes easier to blur across public, host-only, and account + surfaces +- Key assumptions or missing evidence: + - More identity always equals more trust in this product category + - Repeat users actually want accounts enough to offset the added friction + - The team can add broader auth without harming mobile-friendly participation + - Future optionality is valuable enough right now to justify present cost +- Mitigations if this path is chosen: + - Keep attendee participation explicitly guest-friendly + - Preserve host-link fallback during rollout + - Gate account prompts away from the first-create and first-respond moments + - Add instrumentation and rollback triggers before broad exposure + +## Constraint collisions + +- Which priorities are directly in tension: + - Host-return reliability and future trust signals versus low-friction create + and attendee completion + - Product permanence versus route clarity and workflow simplicity + - Future optionality versus current implementation and support cost +- Which route or workflow feels most fragile under this decision: + - `/s/{scheduleKey}` is the most fragile because its value comes from being + obviously lightweight and guest-oriented +- Which costs are immediate versus delayed: + - Immediate costs: auth complexity, support burden, route confusion, create + friction + - Delayed benefits: stronger repeat-user continuity and future identity-based + product expansion +- Which downside is easiest for a team to underestimate: + - Leakage of account expectations into flows that currently succeed precisely + because they are simple and no-account + +## Open questions + +- What evidence would most reduce uncertainty: + - How often hosts fail to return without the private host link + - Whether attendee completion drops when identity language is introduced + - Whether repeat users in this social-planning context actually expect account + persistence +- What would make the broader path clearly worth it: + - Repeated evidence that host-return problems materially hurt finalized-plan + rate and cannot be solved by a host-only path + - Clear demand for cross-schedule history or identity-based recovery from a + meaningful share of active users +- What would make the narrower path clearly insufficient: + - Hosts still fail to re-find schedules even after a careful host-only + continuity improvement + - The product proves that repeat-user continuity matters more than + ultra-lightweight first-use participation diff --git a/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-review.md b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-review.md new file mode 100644 index 0000000..3161476 --- /dev/null +++ b/exercises/04.conflicting-constraints/03.solution.pressure-test-the-decision/tradeoff-review.md @@ -0,0 +1,75 @@ +# Tradeoff Review + +This review pressure-tests the chosen tradeoff and defines how the team would +respond if the decision starts failing in practice. + +## Failure modes + +- How could the chosen path still hurt schedule creation: + - Even a host-only continuity prompt could slow the post-create moment if it + competes with the more important "share this schedule" success state. +- How could the chosen path still hurt attendee participation: + - Identity language could leak into `/s/{scheduleKey}` through copy, chrome, + or navigation and make the flow feel less obviously guest-friendly. +- How could the chosen path still hurt host return or finalization: + - Hosts could become confused about whether they should use the host link, the + claimed schedule path, or both, which would weaken the reliability gains the + change was meant to create. + +## Signals to watch + +- What would tell us we picked the wrong side of the tradeoff: + - Host return still underperforms while complexity and support cost rise + anyway. +- Which behavioral or product signals matter most: + - Create completion rate + - Attendee submission completion + - Host-return success + - Finalized-plan rate + - Support questions about host-link versus login confusion +- Which signal would make you worry first: + - Any sign that attendee completion drops or that public responders start + asking whether they need accounts. + +## Required protections + +- Which mitigations are non-negotiable for the chosen path: + - Login remains optional and host-only. + - Host-link fallback stays valid. + - `/s/{scheduleKey}` remains free of ownership and account language. + - Route purpose stays crisp across `/`, `/s/{scheduleKey}`, and + `/s/{scheduleKey}/{hostKey}`. +- What rollout conditions or guardrails must be present: + - Instrumentation must be in place before exposure grows. + - The post-create continuity prompt must be secondary and dismissible. + - Failed auth must preserve context rather than trapping the host in generic + account flows. +- What must stay unchanged to protect user trust: + - Fast schedule creation + - Lightweight guest participation + - Trustworthy finalization and timezone clarity + +## Revision and rollback + +- What would you narrow or change first if things go badly: + - Remove or hide the post-create prompt first, then simplify the login entry + point if hosts still get lost. +- What is the rollback boundary: + - If the rollout causes a meaningful decline in create completion, attendee + completion, or finalized-plan rate, revert back to the host-link-first + access model while preserving any safely claimed ownership data. +- What would stay worth keeping even if the rollout underperforms: + - Clearer host-link language and any product copy improvements that help hosts + understand return access without adding friction elsewhere. + +## Revisit triggers + +- What future evidence would justify reopening the deferred path: + - A strong repeat-user pattern emerges where cross-schedule history or account + recovery materially improves product outcomes. + - The narrow host path proves too limited despite strong execution. +- What would have to become true for the bigger option to be the better + tradeoff: + - Identity continuity would need to become central to product value rather + than a secondary trust or convenience improvement, and the team would need a + credible way to add it without degrading guest participation. diff --git a/exercises/04.conflicting-constraints/FINISHED.mdx b/exercises/04.conflicting-constraints/FINISHED.mdx new file mode 100644 index 0000000..8753156 --- /dev/null +++ b/exercises/04.conflicting-constraints/FINISHED.mdx @@ -0,0 +1,29 @@ +# Conflicting Constraints + +Great work finishing Exercise 4. + +Before moving on, complete this reflection as a required output. + +## Required reflection outputs + +1. **Constraint collision** + - Which two priorities felt most genuinely in conflict? + - Which cost was easiest to underestimate at first? + +2. **Tradeoff decision** + - Which path did you choose and why was it the right choice now? + - Which valuable outcome did you knowingly leave under-optimized? + +3. **Success criteria** + - What signals would make you feel confident the decision was correct? + - Which signal would make you revisit the decision first? + +4. **Mitigation and rollback** + - What protections were non-negotiable for the chosen path? + - What would you narrow, revise, or roll back first if the tradeoff started + harming the product? + +5. **Future revisit** + - What new evidence would justify reopening the deferred option? + - What did this exercise teach you about making tradeoffs legible instead of + pretending they are not there? diff --git a/exercises/04.conflicting-constraints/README.mdx b/exercises/04.conflicting-constraints/README.mdx new file mode 100644 index 0000000..d94d6b0 --- /dev/null +++ b/exercises/04.conflicting-constraints/README.mdx @@ -0,0 +1,37 @@ +# Conflicting Constraints + +In this exercise, you're the engineer stuck between two reasonable but +competing product instincts. + +The scheduling app now has a plausible narrow path for improving host return +access. That should make the next decision easier, but it rarely does. +Stakeholders want the product to feel more trustworthy, more durable, and more +professional for repeat usage. At the same time, the product still wins because +it is fast to start, easy to share, and lightweight for infrequent users. + +That is the tension: the same change can improve one outcome while quietly +harming another. + +Your job is to make that conflict explicit instead of hand-waving it away. +You'll identify the competing goals, define what success means for each, +forecast what could get worse, and defend a specific tradeoff with clear +mitigations and rollback boundaries. + +You'll move through a practical decision sequence: + +1. Map the competing constraints and what each path optimizes +2. Make a clear tradeoff decision with explicit success criteria +3. Pressure-test the decision by defining mitigation and rollback boundaries + +By the end, you should be able to explain: + +- which priorities are genuinely in conflict rather than merely inconvenient +- which product quality signals matter most when those priorities collide +- why the chosen tradeoff is reasonable now, not just eventually +- what evidence would justify revisiting the decision later + + + A strong result is not "we found the perfect answer." It is "we made the + conflict legible, chose deliberately, and documented how we would know if the + decision stopped being the right one." +