Illustrative business work sample

Product launch readiness

A launch date is a commitment. Is the product ready?

Illustrative task created for this portfolio with AI assistance. The scenario and data are fictional; the worked response demonstrates the proposed approach. Independent scoring is pending.

Assignment

Act as the product lead for a fictional B2B reporting service. Recommend broad launch, a limited pilot, or delay. Produce a decision memo of up to 800 words, a launch-gate checklist with owners and dates, and a risk register. Use only the supplied packet; label assumptions. Planning horizon: day 0 through day 30.

Reference packet

P1 · Demand

12 pilot customers; 8 completed onboarding, 3 stalled at data import, 1 has not started. Six of the eight onboarded customers used the core report weekly over the last four weeks. No willingness-to-pay study is available.

P2 · Quality

Two open release blockers: a cross-account export authorization defect (5 engineering days) and intermittent billing reconciliation failure (3 days). Independent QA requires 2 additional days after both fixes. No security sign-off exists.

P3 · Capacity

Before the day-10 announced launch: 10 engineering person-days and 2 QA person-days available. CSV import improvements require 4 engineering days; a requested dashboard enhancement requires 3. Support can onboard 4 customers per week.

P4 · Commitments

Sales has promised 10 new customer starts at launch. A controlled pilot may start only after both blockers pass QA. The launch owner can renegotiate timing; no contractual penalties are specified.

Illustrative reference response

Delay the day-10 broad launch. Spend 8 engineering days on the two blockers and reserve 2 engineering days for remediation; allocate the 2 QA days to independent retests. Capacity arithmetic alone does not prove the sequence fits the calendar, so confirm assigned staff and QA scheduling on day 0. Do not expose any new pilot account until authorization and billing checks pass. Offer at most 4 starts in the first cleared week, then 4 and 2 in subsequent weeks. Ask sales to reset all 10 commitments before day 2. Defer the dashboard and schedule import work in a later capacity window. At day 10, the product lead and QA owner jointly review evidence; unresolved blockers mean continued delay. At day 30, review activation, weekly core-report use, import failures and support burden before expanding. Six of 12 invited customers show weekly use (50%); six of 8 onboarded customers do so (75%). Neither is proof of paid demand.

Launch-gate checklist

• Day 0 — engineering lead: assign the two fixes and confirm the calendar with QA.
• Day 2 — commercial lead: reset all 10 customer commitments to the capacity-limited schedule.
• Day 10 — QA owner: retain authorization-isolation tests and billing reconciliation results; both must pass.
• Day 10 — product lead: approve a capped pilot only after QA evidence and support staffing are confirmed.
• Day 30 — product and commercial leads: review adoption, import friction and willingness-to-pay evidence before expansion.

Risk register

• Account-data exposure: engineering lead; no new exposure until authorization retests pass.
• Billing error: engineering and QA leads; reconcile representative billing cases before release.
• Overcommitted onboarding: commercial and support leads; cap starts at four per week and reset expectations.
• Weak demand evidence: product lead; gather paid conversion evidence rather than treating usage as demand.
• Schedule slip: product lead; keep the decision conditional on evidence, not the announced date.

Downside check

If both fixes take 50% longer, engineering demand becomes 12 days before remediation, exceeding the 10-day capacity. Replan the date; do not silently spend the reserve twice.

How to score a submission

Score each dimension from 0 to 4: 0 absent or materially wrong; 1 major corrections needed; 2 partly usable with substantive gaps; 3 meets the brief with minor omissions; 4 fully supported and decision-ready. Weighted total = sum of (dimension score ÷ 4 × weight). The weights total 100.

Proposed acceptance: at least 80/100, no dimension below 2, and no critical failure. These thresholds are proposed for this exercise. Preserve dimension-level reasons and evidence citations; a total alone is insufficient.

Critical-failure rule

Any recommendation to expose new accounts before the authorization blocker passes QA, or fabricated test evidence, makes the submission not acceptable regardless of total.

Calibration example

A polished launch memo that recommends 10 day-10 starts despite the support ceiling fails the capacity criterion. A memo that approves launch with the authorization defect open also triggers the critical-failure rule.

Run and review consistently

Give each candidate the same assignment and reference packet; withhold the worked response and scoring notes. Retain the prompt, model/version or author identifier, date, tool access, elapsed time and unedited output. Anonymize and randomize outputs before comparison. Ask reviewers to score independently, cite evidence, and record disagreements and confidence before adjudication. Do not publish an expert preference result until a qualified human has actually reviewed the outputs.

Download all task packets and rubrics (JSON) · All three work samples