Intelligence Sprint Design artefacts
Insight brief template
The single most important artefact in the Intelligence Sprint. Without it, week 2 produces inconsistent submissions that product management cannot evaluate. With it, every engineering insight arrives in a format that is immediately legible to a commercial audience.
How to use
Send this template to all participating teams at the week 1 kick-off. They complete and submit it by the end of week 2. The same template is used by product management to score and rank briefs in week 4. The four sections are non-negotiable — incomplete submissions are returned, not scored.
The design principle behind the template
The four sections are ordered deliberately. Context before observation. Observation before implication. Implication before ask. This forces engineers to translate technical knowledge into commercial language in the right sequence — not to lead with the technical detail that product management can't evaluate, but to start with the programme context that makes the observation immediately legible.
Intelligence Sprint — Insight Brief
Week 2 submission
Section 1 — Programme context
Required
Which engineering programme, platform, or supplier relationship does this insight connect to? Name it specifically — not a general area but a live, active context your team is working in right now.
Section 2 — Technical observation
Required
What have you observed that others haven't acted on? Be specific. Name the system, the behaviour, the measurement, or the pattern. Avoid jargon where possible — write it as if explaining to a product manager who understands automotive but not your specific domain.
Section 3 — Commercial or regulatory implication
Required
What does this observation mean commercially, competitively, or from a regulatory standpoint? Who is affected — a customer, a regulator, a procurement decision, a product roadmap? Quantify where possible. This is the section that makes your brief actionable for product management.
Section 4 — Supporting data
Required from week 3
What data supports your observation? This can be test results, validation logs, supplier scorecards, JIRA data, ASPICE compliance records, or any structured data your team already has access to. In week 3 you'll receive a one-page job aid showing three specific views that help translate this data into a commercial argument.
Section 5 — What a good outcome looks like
Optional but scored
If product management acts on this insight, what changes? What decision gets made differently? What gets added to the roadmap, the test protocol, the supplier brief, or the regulatory submission? One or two sentences. This is not a solution proposal — it is a description of the decision you want to enable.
Team name
Submission date
All required sections must be complete before submission is accepted
How product management scores submissions
Strong submission — scores high
✓Anchored to a named, live programme
✓Technical observation is specific and measurable
✓Commercial implication names a real impact
✓At least one data reference from a real source
✓Outcome description enables a specific decision
Weak submission — returned for revision
✗General area rather than named programme
✗Technical observation without a measurement
✗Implication uses vague language: "could affect"
✗No data — only the engineer's opinion
✗Outcome is a solution proposal, not a decision
Baseline questions — engineering version
Three questions administered before week 1 begins. Repeated after week 4. Without them the case study has no proof of change. These are different from the Revenue Cup baseline — they are written specifically for an engineering mindset and an engineering-to-commercial translation gap.
How to use
Add to the week 1 kick-off email. Same questions in the week 4 review day follow-up. The delta between baseline and final is your primary case study metric. Question 3 is open text only — the answers are your most powerful testimonial material.
1
Commercial translation confidence
Asked: Before week 1 · Repeated: After week 4
On a scale of 1–5, how confident are you that you could explain the commercial or regulatory implication of a technical observation you made this week — in a way that a product manager could act on?
1 — Not at all
2 — Slightly
3 — Somewhat
4 — Quite confident
5 — Very confident
What this measures: The engineering-to-commercial translation gap — the primary skill gap the Sprint addresses. Target delta: +1.5 after the programme. Below +0.5 means the insight brief template or the week 3 job aid needs redesigning.
2
Belief that insights reach product management
Asked: Before week 1 · Repeated: After week 4
On a scale of 1–5, how much do you believe that a technical observation from your team would be seriously considered by product management and potentially acted on?
1 — Not at all
2 — Unlikely
3 — Possibly
4 — Probably
5 — Definitely
What this measures: Environment and motivation gap — whether engineers believe the channel now exists. The most important baseline question. If this doesn't shift after four weeks the sponsor's signal at the review day wasn't strong enough — or the PM didn't visibly engage with the submitted briefs.
3
Last time a technical observation led to a commercial decision
Asked: Before week 1 only — open text
When was the last time a technical observation you made in your work led to a change in a commercial or product decision? Describe what happened in one or two sentences. If you can't think of an example, say so.
What this measures: Baseline state of the intelligence pathway. If most engineers answer "I can't think of an example" — that is your most powerful case study opening line. If several have examples, those examples become your benchmark for what the Sprint is designed to replicate systematically. Either answer is valuable. This is also your most powerful testimonial field.
Day-30 measurement — what to compare
Q1
Commercial translation confidence — baseline vs week 4. Target delta: +1.5
Q2
Belief insights reach PM — baseline vs week 4. Target delta: +1.0
Q3
Pre-programme stories — used as case study opening, not delta measurement