Get in touch

ContactPrivacyTerms

Turn customer evidence into product briefs worth testing.

Briefs written from what customers said, with the sources attached and the open questions still open.

Start with a development reviewHow it works
Brief FJ-214-B01Canvas field jacket · week 1

A field jacket that survives a home wash.

Why
41 “machine washable?” questions and wash-related returns
Target
Machine washable on cold, fit unchanged
Sources
Questions, returns and reviews, linked
Open
Which canvas weight survives a wash?
Not in scope
Waterproof

The brief the product team starts from, with every line traced to what customers said.

Sound familiar?

  • Reviews say one thing and the roadmap says another.
  • The brief says “more durable” and the factory has to guess what that means.
  • The returns that started the idea are in a spreadsheet nobody can find.

A vague brief turns the first sample into a guess. Every wrong guess costs a round, and the weeks that come with it.

What changes.

Evidence
Reviews skimmed, returns forgottenReviews, returns and support grouped by problem, with counts
Targets
“Make it more durable”A target the factory can test, like a home wash on cold
Sources
In the brief writer’s headLinked on every line of the brief
Open questions
Found in the second sample roundListed in the brief, each with an owner

How it works. 5 steps, 4 stages.

  • AI2
  • Rules and automation2
  • Your team1
  • Approval

  1. 1Gather

    1. Rules and automation

      Pull the evidence

      Reviews, returns and support tickets for the product family, with order and variant ids.

      • Shopify
      • Gorgias

  2. 2Group

    1. AI

      Group by problem

      Counts what people asked and why they returned, and keeps their own words.

  3. 3Draft

    1. AI

      Draft the brief

      Target, sources and open questions on one page. Claims you can’t support yet stay out.

    2. Rules and automation

      Number the brief and its sources

      A brief id, links to the evidence, and the product record it belongs to.

      • Techpacker
      • FlexPLM
      • Centric PLM

  4. 4Decide

    1. Your teamApproval

      Choose what to make

      Your product lead sets the target and decides which questions need a test before a sample.

Complaints after launch feed the next brief

What you get. Real work, every week.

Customer questions · field jackets
QuestionAskedIn the brief
Machine washable?41The target
True to size?27Check at fit
Waterproof?19Out of scope

Counted across reviews, returns and support tickets

What customers asked, with the number behind each and where it goes in the brief.

Open questions · FJ-214-B01
  • Which canvas weight survives a wash?Mill and wash lab2 weightsTest first
  • Does the fit change after washing?Patternmaker, at the first sampleWeek 3Check at fit
  • Can we say “machine washable”?Only once the lab report is inHeldNot yet

The questions the brief leaves open, each with who answers it and when.

How you’ll know it’s working.

  1. Days from evidence to an accepted brief

    How long a customer problem waits before anyone can test it.

  2. Clarification requests per brief

    Each question from the factory or the studio is something the brief left out.

  3. Share of briefs with a source on every claim

    A brief nobody can trace is a guess with a template.

Baselines agreed before we build.

Works with what you have.

Commerce

  • Shopify

Support

  • Gorgias

PLM & specs

  • Techpacker
  • FlexPLM
  • Centric PLM
We configure first
Your PLM or tech-pack tool already holds the product record. We start there and connect the evidence to it.
We build when
Reviews, returns and support questions sit in different places and nobody joins them to a product.

What a first build includes.

Built in your accounts, around your team. Scope, fee and baseline agreed before we start.

  1. 1Design
  2. 2Build
  3. 3Run it, or hand it over
Start with a reviewScope this build

We build

  • A weekly evidence feed grouped by problem
  • A brief template with targets, sources and open questions
  • Links from each brief to its product record
  • A shortlist of questions to test before a sample

We start from

  • Reviews, returns and support history
  • Past briefs and sample notes
  • Access to your PLM or tech-pack tool

From your team

Owner
Product director or category GM
Involves
  • Product development
  • Merchandising
  • Customer service
  • Design

Questions teams ask.

Does AI write better briefs?

In a randomized field experiment at Procter & Gamble (Organization Science, 2026), AI raised the quality of concept proposals by about 0.37 standard deviations, though the ideas grew more alike. It measured proposals, not launches. So a person chooses the direction, and we compare against how you write briefs today.

Does this decide what we make?

No. It takes customer evidence as far as a brief and its first test. Range and price decisions stay with merchandising.

Who owns it once it’s running?

You do. It’s built in your accounts, documented, with training for the people who run it. Ownership usually sits with your product director or category GM. We can keep running it with you, or step back.

How do we start?

Usually with a development review: two to four weeks, a fixed fee credited to the build, and a plan that’s yours. If the job is already clear, we can scope the build directly.

Part of your development engine. One of 12 use cases, in 5 parts.

See the whole development engine
  1. Briefs1
  2. Specs & samples4
  3. Suppliers & changes3
  4. Release2
  5. Quality loop2

In briefs

  • Customer briefsYou’re here

Works with

See it at work

Start the next brief from what customers said. Start with a development review.

Start with a development reviewTalk it through first15 minutes

We reply within one business day.