The entire team has to be part of the milestone from start to end (UX, PDs, Content Writer, Dev, PM, BA if needed, etc.)
The weekly sprint meeting is a must! It shouldn’t be technical. It is for - Alignment. Visibility. Togetherness. Execution. Discussions. Q&A.
Every person in the team has to do a demo in the weekly meeting. EVThe weekly meeting is also about setting goals (not tasks, goals!) for each week for each team member, and then go over them the next week.

The Milestone doc is a contract between the management and the team.
The Release Method provides more ownership, accountability and independence to the teams - descoping, moving resources internally, not doing tasks which are not the highlight.
However, any changes in the contract require the milestone owner to make sure company management is aligned.
Changes to scope caused by delays or other reasons should be a “heavy weapon”. Before reaching it, red flags should have been raised so that the company management can prepare for what’s coming (descoping, dropping tasks) and perhaps provide guidance or other solutions (deflecting resources company-wide, getting construction support, offering a shortcut).
If there are recurring delays (or the milestone contract needs to be altered due to other reasons), milestone owner should immediately schedule a meeting with company management to review the status and discuss the milestone future.

A milestone might start with a vague definition of a product and with no UX. In such cases everyone starts together. The entire team can have a fast ‘tractor blitz’ on the first 1-2 days of sprint 1, to brainstorm together.
Changes can be done at any phase of the milestone, even 2 hours before the final release
Good product and execution must involve the team and stakeholders in an iterative process. We want to avoid waterfall processes (product, then UX, then Dev) that create over planning & long releases. Iterative work enables team members to have high engagement, innovation and fast decision-making.

Less than 6 weeks is usually not enough to create something with value to users.
More than 12 weeks is too much of development time to maintain an effective feedback loop.

Deadlines are the best tool for phasing & prioritizing
Deadlines create the necessary sense of urgency (not “emergency”)
Deadlines push the team to achieve more business value faster
Deadlines allow other teams to depend on you properly
Deadlines keep the momentum going
Deadlines keep the team focused on what’s important

Why we don’t compromise on Quality? we know we have market fit, and we need to ensure we deliver quality products.
Quality of our Products: Poor quality hurts our brand.
Quality of development: anything around system design. Our users may not feel it when using our products, but in the long run, this hurts our ability to deliver fast, top quality products.