Not for the demo — a leadership working doc

Team Recovery Plan: Monday Decision and Demo Recovery

New team: three developers (one senior, two junior), a new architect, PM, UX/UI, product person, and team lead. There is no agreed product direction — UX has raised concerns, and engineering is building without a settled outcome. A demo is next week. The Product Director owns the product decision; the VP Engineering is the sponsor.

Overall progress 0 / 0 done (0%)

Objective

Move the team through four stages: product decision → scope translation → technical feasibility → team commitment. The goal is one credible, thin end-to-end demo — not broad feature coverage.

Current status

Use this section to separate what has actually been completed from what still depends on tomorrow's product decision and team meetings.

Completed

Still open

What you need to do tomorrow

Your job is to force clarity and convert it into execution. Do not solve the product narrative privately; make the Product Director's decision explicit and operational.

Leadership actions

Website finalization

Leadership issues being addressed

This is not simply an execution problem. It is a leadership-system problem: product direction exists at the Product Director level but is not being consistently converted into clear, actionable scope for UX and engineering.

Product leadership gap

The product person does not currently appear to be providing enough day-to-day direction for the team. The Product Director owns the decision, but the translation layer is weak or unclear.

Product/UX misalignment

UX is complaining about the lack of direction, which signals that product intent and user experience are not currently aligned in a form the team can execute.

Execution under ambiguity

Developers are still building despite not knowing clearly what to build — wasted effort, hidden assumptions, and risk of a late demo failure.

Cross-functional accountability

Roles are present, but decision rights and translation responsibilities are not operating clearly enough across product, UX, architecture, PM, and engineering.

Your leadership challenge

You own technical and process decisions, but you should not quietly take ownership of the product narrative. Your job is to make the operating gap visible, stop the team from building against ambiguity, convene the right decision-makers, and enforce the product decision once it exists.

Leadership stance — self-check

Can this group make one credible product decision, translate it into a thin demo scope, and resolve ambiguity quickly enough to execute next week? The real leadership question

Before Monday

One-page factual brief

Temporarily pause work that is not clearly connected to the demo. Existing work may be inspected, but do not expand scope before the product decision.

Artifacts to prepare

Monday schedule

Morning

VP Engineering + Product Director

Attendees: VP Engineering, Product Director

The Product Director owns the product decision. The VP helps remove organizational ambiguity and ensure the decision is respected.

Required outcomes

Written summary before the afternoon meeting

Do not treat a vague statement such as "we are aligned" as sufficient.

Late morning · 30–45 min

Preparation

Attendee: Team lead
Afternoon · 60–75 min

Product alignment and scope meeting

Attendees: Team lead, Product Director, Product person, UX/UI, PM, Architect, Senior developer

Do not include both junior developers in this unresolved product discussion — they need clarity, not exposure to the debate.

We have a demo next week and the team has been building without a sufficiently explicit product outcome. I want us to leave today with one committed narrative, a thin end-to-end scope, explicit exclusions, and clear ownership for translating product decisions into work. Opening line

Agenda

Recommended split: Product Director — product direction and final priority · Product person — requirements, priorities, communication · UX — user flow and interaction design · Architect — technical approach and risk · PM — schedule, dependencies, escalation tracking · Team lead — operating discipline and execution focus.

Required output

Late afternoon · 60–90 min

Scope breakdown and execution planning

Attendees: Team lead, Product person, UX/UI, PM, Architect, Senior developer

Product Director may attend the first 10 minutes if needed, but is not required for routine breakdown.

End of day · 30 min

Full-team reset

Attendees: Everyone — team lead, three developers, architect, PM, UX/UI, product person (Product Director may join briefly, not required)
We now have a committed demo scope. From this point until the demo, work outside that scope is paused unless explicitly approved. We are optimizing for one credible end-to-end story, not broad feature coverage.

Cover

Ask

Tuesday–Friday

Recurring daily cadence, Tuesday through Thursday: a 15-minute morning execution check with the full delivery team (product and UX included when active design decisions exist) — each person answers what demo slice they advanced, what's blocked, what decision is needed, and what will be visibly demonstrable by end of day. This is not a generic status meeting: the PM tracks commitments, the team lead removes organizational/process blockers, the product person resolves product questions, the architect resolves technical direction. A 15–20 minute daily product/UX/engineering resolution slot (product person, UX, senior developer or architect, team lead only if escalation is needed) resolves only questions affecting the committed flow — no new backlog. A 15-minute end-of-day checkpoint (team lead, PM, architect, senior developer, product person) asks whether something demonstrable was produced, whether scope held, the biggest current risk, and what to cut before tomorrow. If behind, cut scope immediately rather than adding hours or people.

Tuesday

Morning execution check

Daily resolution slot

End-of-day checkpoint

Wednesday

Morning execution check

Daily resolution slot

First internal demo · 30–45 min · full team

End-of-day checkpoint

Thursday

Morning execution check

Daily resolution slot

Stabilization and narrative rehearsal · 30 min

Attendees: Team lead, PM, Product person, UX, Architect, Senior developer, developers as needed

Decide:

Fallback materials prepared

End-of-day checkpoint

Friday — full rehearsal

Attendees: Entire team, plus one or two people unfamiliar with the work if possible
Duration: 45–60 min

Afterward, ask:

Role accountability

RoleAccountability
Product DirectorFinal product narrative, priority, and scope
Product personConverts decisions into clear requirements and communicates them
UX/UIUser flow, interaction design, and experience coherence
ArchitectTechnical feasibility, risks, and trade-offs
Senior developerImplementation approach and engineering coordination
Junior developersExecute assigned vertical slices and surface blockers early
PMSchedule, dependencies, decision log, and escalation tracking
Team leadFocus, working agreements, blocker removal, and accountability

If Monday fails

If the VP and Product Director do not produce a clear decision, do not hold a vague alignment meeting and send the team back to work. Say:

We still do not have an executable product decision. I recommend we either name an interim product decision-maker today or explicitly narrow the demo to the smallest validated flow. Continuing with broad development is not a responsible option.

The team should not continue building against unresolved product ambiguity.

Progress is saved locally in this browser only.