Charters and Templates

How to Write a Six-Week Pilot Charter for a Consumer App Voice Feature

By the Vantage Pilot editors / Oct 28, 2026 / 4 min read

Short answer. A six-week voice feature pilot needs one user problem, one limited feature, a defined test audience and measurable success and kill criteria. The charter should specify what the team will build, what evidence it must collect each week and who will make the final ship, change or stop decision.

Key points

Start with a user problem, not a preferred AI capability.
Keep the pilot to one voice interaction and one primary use case.
Set engineering, privacy and operating-cost boundaries before development.
Choose measurable success and kill criteria before the first user session.

Start with a problem the voice feature can solve

A voice feature can sound compelling in a product presentation and still solve no meaningful user problem. The charter must begin with a specific behavior that users already attempt. For example, a meal-planning app might let users add ingredients by speaking instead of typing. The hypothesis could be: users who prepare a shopping list while cooking will complete ingredient entry more easily through short voice interactions.

Turn that hypothesis into a measurable prediction. For example: at least 60 percent of eligible pilot participants will successfully add three or more ingredients using voice during their first week. This is a proposed decision threshold, not an industry benchmark. The team should choose a threshold that makes the feature worth maintaining and that can be observed during the pilot.

Target user and context of use.
Current behavior or problem.
Proposed voice interaction.
Expected improvement.
Evidence that would support the hypothesis.

Define the six-week scope

A pilot charter needs a hard boundary between the feature under evaluation and the product work that can wait. For the shopping-list example, the pilot might include speech capture, transcription, ingredient confirmation and list insertion. It might exclude hands-free navigation, multiple languages, background listening, voice-based recommendations and conversational meal planning.

The distinction matters because AI feature development can expand quickly. Each additional capability introduces more states, failure modes and evaluation requirements. A six-week pilot should answer one primary question. If a feature requires a complete redesign of the app, extensive new infrastructure or several dependent AI capabilities, reduce the scope before approving the experiment.

Included: one voice input flow.
Included: confirmation and correction.
Excluded: continuous listening.
Excluded: unrelated conversational features.
Excluded: full production rollout.

Build the charter around six weeks

The schedule should assign each week a deliverable and a decision. Week one covers the hypothesis, baseline, audience, technical feasibility and risk review. Week two produces a narrow prototype and a small evaluation set. Week three focuses on integration and instrumentation. Week four introduces the feature to a limited group. Week five examines actual usage, errors and operating costs. Week six closes the evidence review and records the decision.

Avoid treating the six weeks as six equal periods of coding. A team that postpones measurement until the final week may discover that essential events were never recorded. Instrumentation, error classification and privacy requirements belong in the initial plan. The charter should also identify an owner for each deliverable and reserve time for unexpected integration problems.

Week 1: charter, baseline and risk boundaries.
Week 2: prototype and evaluation cases.
Week 3: integration and instrumentation.
Week 4: limited audience release.
Week 5: usage and quality evaluation.
Week 6: decision and recommendation.

Choose success criteria that reflect user value

A voice feature needs more than a transcription accuracy target. A technically accurate transcript does not establish that users can complete their task. Measure the complete interaction: successful capture, correct transcription, successful confirmation and completion of the intended action. For example, a task success rate of 80 percent could be a proposed minimum for a shopping-list pilot, provided the team defines exactly what counts as a successful task.

Pair that primary measure with a small number of supporting indicators. These might include correction rate, abandonment rate, median task completion time, repeat usage and cost per successful interaction. Compare results with the existing text-entry experience where possible. Keep the measurement plan realistic: a small team should be able to explain every metric and identify where its data comes from.

Primary: successful completion of the voice task.
Quality: transcription and correction rates.
Behavior: repeat usage and abandonment.
Efficiency: time to complete the task.
Economics: cost per successful interaction.

Set operating limits and decision ownership

The charter must specify who can access pilot data, how voice recordings and transcripts are handled, which external services process them and how long relevant data is retained. These requirements depend on the product, user population, service providers and applicable region. The responsible privacy or security professional should determine the appropriate requirements before user access begins. A voice feature also needs a clear failure state, such as an option to correct the transcript or return to typing.

Assign a decision owner before the pilot starts. The owner should have authority to recommend shipping, extending with a narrower hypothesis, changing the feature or stopping it. Set the operating limits in advance. For example, the team might pause the pilot if variable AI costs exceed an agreed weekly budget or if a critical data-handling issue appears. The final decision should include evidence, unresolved risks and the next authorized action.

Name one accountable decision owner.
Define the pilot audience and access limits.
Document data handling and retention requirements.
Set an operating-cost ceiling.
Specify the conditions requiring an immediate pause.

Copy-ready pilot charter

A useful charter fits on one working page, with supporting technical and privacy details attached where necessary. The following structure gives stakeholders enough information to understand the experiment without turning the approval process into a full product specification.

For example, a proposed charter might identify the shopping-list voice flow as the feature, 100 eligible participants as the intended audience, 80 percent task completion as the primary success threshold and six weeks as the experiment period. Those numbers are planning choices. The team must justify them against its expected traffic, available recruitment capacity and product economics before approval.

Problem: What user task is currently difficult?
Hypothesis: What measurable improvement is expected?
Scope: What is included and explicitly excluded?
Audience: Who can access the pilot?
Schedule: What is delivered each week?
Success and kill criteria: What determines the outcome?
Owner and budget: Who decides and what is the spending limit?

Questions readers ask

How many users should a voice feature pilot include?

The required audience depends on expected usage, recruitment capacity and the decision being made. Estimate the number of completed tasks needed to evaluate the primary metric, then account for participants who may never activate the feature.

Should the pilot use a production AI model?

Use a model and integration representative of the intended product experience when practical. A prototype can establish workflow feasibility, but results from a materially different model or architecture may not transfer to production.

What belongs outside a six-week pilot?

Large-scale infrastructure changes, broad feature expansion and permanent operational commitments should usually remain outside the initial scope unless one is essential to evaluating the central hypothesis.

Who approves the final decision?

The accountable product decision owner should consolidate input from engineering, design, data, privacy and business stakeholders. Each specialist retains responsibility for decisions within their professional remit.