Task Assistant — decision brief
Inspect fictional tasks and review changes to their status or owner. This demo follows predefined browser rules; it has no AI model or Asana connection.
The product choice: Keep a person in control of every proposed task change. Try the sample · Follow the walkthrough.
Experience and decision
My product and program work has involved coordinating cross-functional teams, clarifying ownership and making changes understandable to the people responsible for delivery. This is a separate fictional portfolio exercise; its records, rules and results do not reproduce an employer system.
Decision to challenge: Would a reviewed conversation help a delivery lead more than direct task controls? The extra confirmation is useful only if it reduces wrong-task changes without making routine coordination harder.
A rules-based browser demo for inspecting fictional tasks and reviewing updates. It uses predefined request patterns, with no AI model, server backend, or Asana integration.
User and problem
A fictional Northstar product, delivery, or program lead needs a quick way to inspect work and prepare a routine update without losing sight of the task record. The product question is whether everyday-language requests can reduce coordination friction while keeping the affected task and change boundary understandable.
Product choice
The prototype pairs a constrained local workspace guide with visible task cards. It can answer grounded questions and prepare supported status and owner changes. A task card also lets a person add or edit a blocker reason through the same reviewed flow; the guide points reason-editing requests to that control rather than guessing the reason. Each task, reset, Undo, and bulk update becomes a preview with readable task titles and before-and-after values. NTH-104 makes the choice concrete: “Mark Finalize onboarding checklist as done” prepares In progress → Complete; it changes only after confirmation.
Cost and boundary
Confirmation adds an interaction to routine updates, ambiguity prompts can interrupt a request, and deterministic handling supports a limited phrase set. The sample does not edit due dates or connect to Asana, an API, an external model, or customer data. Browser-local persistence and reviewed recovery demonstrate a boundary, not a shared audit history, permissions, or durable operations.
Evidence and next investment
Technical checks establish that documented local flows ran; they do not establish human trust, usability, demand, model quality, or business impact. No participant study has occurred. The next investment is a five-participant comparison with each person’s current task workflow. Expand only if participants independently identify the affected task, distinguish a proposal from a confirmed update, and recover a deliberate change without a critical action-boundary error. The walkthrough, PRD, decisions, and validation plan make that product case reviewable.
Before connecting a real task system or model, compare the reviewed conversation with the existing direct controls. The opportunity is less coordination effort; the cost is clarification and confirmation on each change. If people complete routine updates just as well with the cards, keep the direct workflow and reduce conversational scope. A future model would need separate checks for wrong-task proposals, ambiguous language, permission boundaries and the cost of human review; this deterministic sample establishes none of those production capabilities.
My role as Product Manager
I defined the problem, prioritization and scope, workflows, fictional sample data, acceptance criteria, and evaluation plan. AI tools assisted with implementation and verification; I do not claim manual authorship of the application code.