Companion shapes the live goal
Companion is the live work surface: it asks for context, turns the goal into a proposed path, and keeps assumptions visible beside the chat.
Choose a concrete case
Choose the kind of work you want to see.
These are examples of one learning workspace, not separate tools. The domain changes, but the structure stays the same: start in chat, keep the plan beside the session, open the path in Dashboard, and return with review evidence.
01
Learn roadmap prioritization enough to defend tradeoffs
A product lead needs tradeoff language that survives pushback.
The path starts from user outcome and request-to-bet translation, then trains opportunity cost before evidence quality and stakeholder defense.
Primary chat Start from the real goal
You
I want to learn roadmap prioritization, especially opportunity cost.
Myelin
What tradeoff are you trying to explain or defend?
You
I need to defend why one roadmap bet goes first without sounding like I am dismissing the other request.
Myelin
Then this pass should focus on translating requests into bets, naming the opportunity cost, and setting the signal that would reopen the decision.
Product lead
Different chats stay tied to the same path.
The follow-up conversations change with the work, but they do not create a new blank thread.
Supporting chat
A stakeholder asks for the skipped feature.
The work stays grounded in the kind of conversation a product lead actually has to survive.
You
I want to learn prioritization frameworks that help me explain roadmap decisions.
Myelin
Which roadmap decision do you need to explain?
You
Sales is pushing for an admin export. We chose onboarding activation first, but I need to defend the tradeoff clearly.
Myelin
Then the useful slice is not a whole framework catalog. Name the user outcome behind each request, the shared constraint, the cost of delaying each bet, and what evidence would change the order.
The path trains the language of tradeoffs, not a generic prioritization formula.
Supporting chat
Evidence is mixed after discovery.
The next pass can keep ambiguity in view instead of pretending prioritization is just confidence theater.
You
I want to learn how to judge evidence quality for roadmap prioritization.
Myelin
What evidence conflict are you trying to resolve?
You
Discovery says onboarding is painful, but support keeps escalating export requests. I am not sure what evidence is enough.
Myelin
Then focus on frequency, severity, revenue exposure, reversibility, and whether the signal actually compares the two bets.
Review can bring the learner back to the exact judgment gap: confusing loud requests with better bets.
Plan beside chat
The prioritization request becomes a path of judgment skills.
Companion keeps the learning goal, chosen bet, delayed bet, constraint, and revisit trigger visible before the path becomes the work.
02
Companion draft
Backtrack from a roadmap defense
Companion keeps the product learning goal narrow: chosen bet, delayed bet, constraint, and revisit trigger.
Goal shaping Companion
Dashboard and return
Dashboard keeps the tradeoff spine visible.
The larger view shows how opportunity cost sits between request framing, evidence quality, stakeholder defense, and review evidence: due concepts, confidence, struggle signals, and weak judgment steps.
03
Dashboard path
Make the tradeoff spine visible
Dashboard shows opportunity cost between framing and later judgment concepts.
Visible path Dashboard
04
Review evidence
Return to the actual tradeoff gap
Review shows the due opportunity-cost step, confidence, and struggle signals so the next pass repairs the exact tradeoff gap.
Review Dashboard
Learn roadmap prioritization enough to defend tradeoffs
Product goal. Tradeoff path. Defensible return point.
The example starts with a broad request to learn prioritization, uses the roadmap context to narrow the path, and keeps the actual tradeoff gap ready for another pass.
The learning record stays tied to the product decision the product lead needs to defend; it is not trying to manage the roadmap itself.
01
Learn how to read a P&L for commercial decisions
A commercial leader needs a decision lens, not accounting trivia.
The path starts from revenue quality, opens gross margin as the first profit checkpoint, and only then moves into contribution, discounting, hiring, and growth spend.
Primary chat Start from the real goal
You
I want to learn how to read a P&L, especially gross margin.
Myelin
What do you need it for: reporting numbers, challenging a decision, or running a commercial review?
You
I need to challenge pricing, discounting, and sales hiring without pretending revenue growth is enough.
Myelin
Then we should not start with a finance glossary. This path should focus on revenue quality, gross margin, contribution margin, discount impact, and the hiring decisions those concepts unlock.
Commercial director
Different chats stay tied to the same path.
The follow-up conversations change with the work, but they do not create a new blank thread.
Supporting chat
A discount request lands from sales.
The session can stay close to a real commercial decision instead of drifting into abstract accounting.
You
I want to learn how discounts affect gross margin.
Myelin
What discount decision are you trying to make right now?
You
An enterprise deal needs a 20% discount to close. I need to know whether that is smart or just panic.
Myelin
Then connect price, direct cost, gross margin, implementation load, and payback before deciding whether the discount protects or damages the segment.
The path turns a discount argument into the finance concepts needed to inspect it.
Supporting chat
A hiring plan needs a margin check.
The next conversation can use the same path to reason about sales capacity and contribution.
You
I want to learn contribution margin for sales hiring decisions.
Myelin
What hiring decision are you pressure-testing?
You
We want two more AEs next quarter. Revenue capacity goes up, but I do not know how to pressure-test the plan.
Myelin
Start with ramp time, quota capacity, gross margin, and contribution after sales cost. The hiring question becomes a margin and timing question.
Review can keep the exact commercial reflex visible: revenue is not the same as useful profit.
Plan beside chat
The broad P&L request becomes an inspectable path.
Companion keeps the learning goal, commercial context, proposed order, and assumptions visible before the path is accepted.
02
Companion draft
Shape the goal into an inspectable path
Companion turns the broad P&L learning request into a path with visible assumptions and a current focus.
Goal shaping Companion
Dashboard and return
Dashboard keeps the commercial decision path visible.
The larger view shows why gross margin appears now, what it depends on, what it unlocks, and the review evidence: due concepts, confidence, struggle signals, and weak spots to revisit.
03
Dashboard path
Show the decision graph
Dashboard shows gross margin in context: what it depends on, what it unlocks, and what is still blocked.
Visible path Dashboard
04
Review evidence
Return to the weak commercial reflex
Review shows due concepts, confidence, and struggle signals so the next pass repairs the exact revenue-first mistake.
Review Dashboard
Learn how to read a P&L for commercial decisions
Commercial goal. Finance path. Reviewable decisions.
The example starts with a broad request to learn P&L, uses the commercial context to narrow the path, and keeps the weak decision reflex ready for the next pass.
The learning record stays tied to the commercial decision, not to a CRM or a generic finance syllabus.
01
Learn caching enough to make an app faster without stale data bugs
A developer needs the layer that prevents fast wrong data.
The path starts from the slow read and cacheable boundary, then trains cache keys before TTL, invalidation, stale-while-revalidate, and tests.
Primary chat Start from the real goal
You
I want to learn caching, especially cache keys.
Myelin
What are you trying to make faster, and what would be bad if the cache were wrong?
You
I want the dashboard to feel fast, but I keep worrying that cached task counts will be wrong after edits.
Myelin
Then we should not start with Redis or a global TTL. The path should start with cacheable boundaries and key scope, then move to TTL, invalidation, stale UI, and tests.
Software engineer
Different chats stay tied to the same path.
The follow-up conversations change with the work, but they do not create a new blank thread.
Supporting chat
The slow endpoint has too many meanings.
The session can stay close to the implementation pressure instead of opening a broad caching course.
You
I want to learn how to design cache keys.
Myelin
What data are you trying to cache?
You
The task list endpoint is slow, but it changes by workspace, assignee, filters, sort, and page.
Myelin
That means the useful learning target is key scope. The key must describe the data slice before any cache store or TTL choice can be safe.
The path keeps performance tied to correctness instead of jumping straight to infrastructure.
Supporting chat
The cache gets fast and wrong.
A later pass can focus on the failure mode that actually scares the developer.
You
I want to learn cache invalidation without getting lost in distributed systems theory.
Myelin
What stale-data failure are you trying to prevent?
You
After editing a task, counts update in one panel but stay old in another. That is the bug I want to avoid.
Myelin
Then the relevant concepts are invalidation surface and stale-while-revalidate UI: what changes, which keys are affected, and what the user sees while data refreshes.
Review can return to stale-data risk, not generic caching trivia.
Plan beside chat
The caching request becomes a learning path.
Companion keeps the caching learning goal tied to one slow dashboard, one stale-data failure mode, and the order needed to avoid fast wrong data.
02
Companion draft
Shape the learning request into a path
Companion keeps the caching request tied to one slow dashboard and one stale-data failure mode.
Goal shaping Companion
Dashboard and return
Dashboard keeps correctness in the performance path.
The larger view shows why cache keys come before TTL, invalidation, stale-while-revalidate, and tests, then keeps review evidence for the stale-data risk.
03
Dashboard path
Show cache keys in the dependency chain
Dashboard shows why key scope comes before TTL, invalidation, and stale-while-revalidate UI.
Visible path Dashboard
04
Review evidence
Return to stale-data risk
Review shows due concepts, confidence, and struggle signals tied to the stale-data mistake the developer needs to revisit.
Review Dashboard
Learn caching enough to make an app faster without stale data bugs
Software goal. Performance path. Stale-data review.
The example starts with a broad request to learn caching, uses the app-speed context to narrow the path, and keeps the risky correctness gap ready for another pass.
The learning record stays tied to the app behavior the developer is trying to improve, not to code completion or generic courseware.