The questions every team asks in the first month, and the stances the method takes on each.

Isn’t it a lot of writing overhead?

Writing isn’t overhead — it redistributes it. The method doesn’t add work; it moves time out of one-off meetings, emails, chat messages, ticket and epic comments, and the flutter of post-its and retrospectives, and into two central documents: the Initiative DocumentInitiative DocumentThe PR/FAQ-shaped document where an initiative's context lives — customer, solution, plan, business case, and success metrics. and the Daily Check-inDaily Check-inA 15-minute daily ritual where the team surfaces reality and unknowns rather than reporting status..

Teams that make the switch report the same pattern: fewer meetings, fewer chat messages, fewer ticket comments, and faster resolution of the small bumps that used to spawn a thread.

Look at where the time was already going:

• The Initiative Document replaces the effort already spent on initial wireframes, validations, alignment meetings, epic-writing, forming a team, setting goals, and weekly roadmap or sprint planning — tasks normally scattered across people and teams. Centralising them in one document makes the process more efficient, not less.
• The Daily Check-in is simply a documented log of the ad-hoc meetings that otherwise happen, undocumented, throughout the day.

So the writing isn’t a new tax. It’s the same work, captured once, in a place the whole team can read — instead of re-explained three times across three channels.

How do we speed up by making things smaller?

By planning at three granularities at once: the ApproachThe ApproachThe multi-week narrative roadmap — titled weekly outcomes ("The one where…"), each with a demo, planned backwards from success. (6–12 weeks with weekly titles), the Week Plan (this week’s detail plus a rolling roadmap), and the daily TFOThings to Figure OutEach person's one thing to figure out today, framed as a Why/How/What/When question that resolves into a Lesson Learned.. This is team play, not one person translating big goals into small tickets. Smaller items mean faster alignment through more frequent feedback, and faster learning because smaller batches expose flaws sooner. It works because every team member can see how their daily TFO connects all the way back to the Initiative Document.

How does the method empower teams?

Empowerment here is structural, not cultural — it doesn’t depend on everyone being nice. Knowledge gaps get bridged by the Initiative Document. Communication imbalances get fixed by the BoardProduct BoardTwo or more stakeholders who see the team's weekly demo and coach it — the human in the loop, with no single lead. Meeting’s equal split between team presentation and board discussion. End-to-end teams share context daily in the Check-in. Lessons Learned create a documented, low-stakes way to voice concerns. Teams arrive at the Product Board prepared and equal — not as supplicants reacting to top-down edicts.

What about managing bugs?

Bug triage is art, not science, and it needs seniority. There are three legitimate reasons to pick up a bug: urgency (real customer impact), efficiency (an engineer is already in that area), and boy-scouting (an engineer wants to fix what’s bothering them). All three must be allowed. Urgency is a call for a senior engineer and the responsible person on a weekly cadence with rotating duties. Efficiency is a senior engineer’s call during Week Planning. Boy-scouting is the engineer’s own choice, flagged in the Check-in so the team can challenge it if needed. The non-negotiable: senior engineers who know the system deeply.

Can we skip the Check-in after Week Planning?

No. They have different purposes. Week Planning specifies outcomes and distribution for the week. The Daily Check-in surfaces daily blockers, lessons, and focus. Blending them overextends the meeting and muddies both.

How does Dual Track Agile fit in?

Naturally. Discovery is “done” when you’ve answered the four risks, and those four are the key Uncertainties that take an Initiative Document from draft to ready:

• Desirability — will customers use or buy it?
• Usability — can they figure out how to use it?
• Feasibility — can we actually build it?
• Viability — does it work for our business?

Resolving those four is early Discovery. From there, running the initiative weekly with Daily Check-ins and Board Meetings is iterative Discovery and Delivery together. The uncertainties in the Approach are the ongoing Discovery questions; assigning each one to a specific week is what makes Discovery and Delivery run in parallel rather than as two separate phases.

How does it fit with OKRs?

The Initiative title is your Objective — make it inspirational. The success metrics from the Initiative Document are your Key Results. The narrative in the initiative supplies the context around the OKR.