Product Delivery Process

Witboost uses a release-cadenced, team-involved, and quality-first development process to turn product opportunities into stable releases.

Principles

When priorities conflict, we apply these principles in order:

1. Security: we do not knowingly ship unacceptable security risks.
2. Customer attention: customer-impacting issues receive prompt attention, clear communication, and appropriate prioritization.
3. Quality: acceptance criteria, testing, documentation, and release checks are part of delivery, not optional follow-up work.
4. Delivery: we maintain a predictable cadence and deliver the highest-value scope that meets the first three principles.

We reduce or defer scope rather than compromise security or quality.

Cadence

Witboost targets a stable release every 8 weeks and organizes execution in 2-week sprints.

• Weeks 1-6 combine delivery for the current release with discovery and technical refinement for future work.
• Weeks 7-8 are the release freeze, focused on quality assurance, regression testing, defect resolution, documentation, and release preparation.
• Week 8 includes planning for the next release, using current QA outcomes, customer needs, priorities, and realistic team capacity.

Release scope is a commitment to outcomes, not a reason to ship unfinished work. When work no longer fits, the team makes an explicit rescoping decision.

From Idea to Release

1. Discovery and Product Design: the Product Owner, Delivery Lead, Product Designer, and relevant specialists clarify the problem, target users, desired outcome, scope, and acceptance criteria. Wireframes or early prototypes are created when useful.
2. Technical refinement: a Feature Owner defines the high-level solution, delivery milestones, dependencies, risks, and milestone estimates. Technical investigations are time-boxed.
3. Release planning: ready delivery slices are prioritized against customer value, security, quality, technical health, and available capacity.
4. Software Delivery: developers implement small, reviewable Stories. Code, tests, configuration, and documentation follow the same Definition of Done.
5. Feature QA and release freeze: the team validates acceptance criteria, integrations, regression coverage, documentation, security, and release readiness. Critical and high-severity defects block release.
6. Release Management and learning: the release is demonstrated to interested stakeholders, shipped with the required notes and guidance, and followed by continuous improvement.

Scope and Tracking

The process uses a simple hierarchy:

Feature → Delivery Slice → Milestone → Stories and Tasks

• A Feature represents a long-lived product outcome.
• A Delivery Slice is a releasable portion of a Feature and is represented by one delivery-level record in the work-tracking system.
• A Milestone is an independently valuable, estimable, and deferrable part of a Delivery Slice.
• Stories and Tasks describe the implementation work needed to complete a Milestone.

Product intent and material scope decisions remain visible even when delivery spans multiple releases.

Responsibilities

• The Product Owner owns product direction, scope, and prioritization.
• The Delivery Lead coordinates discovery, capacity, planning, and delivery decisions.
• The Feature Owner owns the technical shape and correctness of a delivery slice through release readiness.
• The Product Designer contributes from discovery through design QA, supporting prototypes, refinement, implementation, and experience quality.
• Developers own implementation and task-level quality through the Software Development workflow.
• QA, Security, Support, and Release leads provide specialist controls and coordinate their respective processes.

AI-assisted tools may help create designs, plans, Stories, and code, but their output is never authoritative. People remain accountable for correctness, review, security, testing, and delivery decisions.

Planning Beyond Features

Every sprint reserves visible capacity for bugs and technical debt. Feature Owners and Product Area Leads prioritize these items with the Delivery Lead and delivery team.

Large technical-debt, reliability, or improvement proposals that compete with feature capacity are surfaced to the Product Owner before release planning. Customer-driven improvements that meet the dedicated criteria may use the Forward-Deployed Engineering process.

Ceremonies

Meetings are decision-oriented. Status that does not need discussion is shared asynchronously, and material decisions are recorded in the relevant product or delivery artifact.