Module 6 · Lesson 18
Product and data
Take a product question from raw data to charts, a daily routine, a spec, designs and a prototype with a small team of role Bots.
Before this module
Day 1
Day 1, last build block. It was the messiest stretch of the day.
The shared screen froze, one Bot could not reach the repositories and another failed to note the event date. They still moved forward: the landing page was storing signups and sending confirmations, one Bot found the best street corners for handing out flyers and another pulled together twenty-odd caterers with phone numbers.
Keep reading
Halfway through they changed plan. The first pop-up went from restaurant to art exhibition, and the first thing they did was tell the coordinating Bot so the rest would stop working on the old idea.
In parallel, other sessions showed teams that have been running for a while: a product one that goes from a data question to a prototype, a founder one that preps calls and watches competitors. The real cases in this course come from there.
Day 1 · 5:39:38Change of plan: from restaurant to art exhibition
Day 2
Day 2, between blocks. The studio handed over to people already working this way outside a demo.
The owner of a coffee shop with its own roastery has a chief of staff Bot wired to the till. From his phone he asks it what they were selling two years ago, and he sent it a photo of the menu to see which products barely moved.
Keep reading
A creator who makes a living from videos about AI told two stories. He photographed the things he no longer used and let his Bot look up recent prices, post the listings and answer buyers: that is how he sold a console and a laptop. Another Bot went through twelve months of electricity bills and found him a plan a thousand dollars a year cheaper.
Matt summed it up: personal problems look a lot like company ones. Haggling at a flea market is the same as negotiating with a supplier. The real cases in this module come from there.
Day 3
Day 3, midday. Two talks showed teams that have been running for a while outside a demo.
The marketing operations one described a Bot that built an internal app for salespeople to review their leads, and that stopped to ask which fields should change before writing any code. The answer forced her to sharpen her own idea.
Keep reading
The post-sales one gave six concrete uses: the morning status board, call prep fifteen minutes ahead, the follow-up desk, the promise keeper, the ask watch and the account reset. All real, none invented.
This module's cases come from there.
Contents3
- Ask a data Bot a question and get numbers and charts you can check
- Chain a finding into a spec, designs and a prototype through role Bots
- Decide where a person must review before the work moves on
Slow handoffs between data and product
Product work moves in slow handoffs. Someone asks a question, an analyst writes a query, a product manager turns the answer into a spec, a designer mocks it up, and an engineer builds a prototype. Each step waits for a person to be free.
You already know the pieces from earlier lessons: one Bot An AI teammate with a name, a job and its own conversation. It works on a computer in the cloud, even when you're away. See in the glossary → per role (lesson 11), Bots handing work to each other (lesson 12), Routine Work a Bot does on its own, on a schedule or when something happens in another tool. See in the glossary → (lesson 10) and Cloud agent A Cursor coding agent that works on its own computer on a copy of the code and returns the change for review. See in the glossary → for code (lesson 15). This lesson puts them together on one real product loop. You'll see where the Bots save days and where you still need to look carefully.
A relay race between Bots
A product team of Bots works like a relay race. Each Bot owns one stage, receives the previous result and passes something reviewable to the next. You stay in the conversation as the person who asks the question, checks each hand-off and decides whether the work moves on.
The roles
In the livestream demo for product managers, the team had four Bots with names and jobs:
- Ashley, data science. Connected to the data warehouse (the central database where a company keeps its business data), it writes and runs queries and answers with numbers and charts. A query is a precise question written in a language the database understands.
- PM Pete, product. It turns a finding into a PRD (product requirements document), a spec that lists what to build, with P0 items (top priority) and P1 items (next priority).
- Pixel, design. It produces design options using the company's design system, the shared set of colors, fonts and components.
- Emily, engineering lead. It splits the spec into tasks for engineer Bots, who launch cloud agents to build prototypes.
The closest official use case is Product Performance in Use cases. It describes a Bot that owns performance investigations "with evidence", returns screenshots and direct links, and separates facts from hypotheses.
Why the artifacts matter more than the chat
Every stage should end in something you can open and check: a chart, a spreadsheet, a spec, a design, a Pull request A proposed change to the code, packaged so someone can review it before it's accepted. See in the glossary →. The Files and results page recommends asking for results that separate facts found in source systems from assumptions, completed actions and open questions. With that split, you can review a data answer in two minutes instead of redoing the analysis.
Where humans still review
The Bots can run the whole loop, but three points deserve your eyes:
- The numbers. Memory is not a source of truth. For decisions, ask the Bot to reopen the current data and show the query.
- The spec. It sets what gets built. Read it, comment on it and correct it before any design work starts.
- The choice between designs, and the merge. Picking a direction and shipping code are product decisions.
Set up the relay stage by stage
- Connect the data source to your data Bot. Use a Connector A ready-made link between a Bot and a service such as Slack, Notion or GitHub. In the app they appear as Plugins. See in the glossary → from Settings → Plugins if one exists. If not, sign in to the tool yourself in the Bot's browser (lesson 09). Start with read-only access, so the Bot can look but not change anything.
- Put the boundaries in the Bot's description. Read-only queries, always show the query, never change dashboards or alerts.
- Ask a narrow question and ask for charts. The first time, check the numbers against a source you trust.
- Turn a useful answer into a routine. Confirm which Bot owns it, the schedule and time zone, and what should happen if the data is missing.
- Hand a finding to the product Bot. Reply to the message that contains it and mention that Bot with
@. - Review the spec before asking for designs. Edit or comment until the P0 items are right.
- Ask for designs for each P0 and choose one yourself.
- Send the chosen design to the engineering Bot and ask for a prototype with screenshots or a video as proof (lesson 16).
Fly Low Airlines, from question to prototype
This is the Fly Low Airlines demo from the livestream, a fictional airline set up for the session.
Day 1 · 6:10:24Asking the data Bot about yesterday's ticket sales
The demo started with a plain question to Ashley:
How many people purchased tickets yesterday on mobile versus web?Ashley queried the warehouse and answered: about 1,400 tickets, 58% on web and 42% on mobile. The next message asked how many families were flying and to "help us visualize these with charts". Ashley returned charts by traveler type (solo, couple, family, group), with families at 25%.
Then the team made it recurring:
Send me this as an update every morning at 6 a.m.If you copy this, add the parts the docs ask a routine to define:
Every day at 6:00 AM Pacific time, send me yesterday's ticket purchases by platform and by traveler type, with charts and the query you used. If the data for yesterday is not available yet, say so instead of using older data.Next, the team opened a mobile purchase funnel Ashley had built earlier. A funnel shows how many people reach each step of a purchase, and where they drop out. They replied to it:
Looks like a big fall-off when people are choosing seats on mobile. Work with @PM Pete to generate a product spec to optimize our mobile funnel.Day 1 · 6:15:28The data Bot corrects the humans
Ashley didn't go along with the humans' reading. The biggest drop was between search and fare selection, not at seat selection, and it told Pete so. Pete wrote a PRD in Notion with P0 and P1 requirements, including a redesign of fare results on mobile and faster fare comparison.
The team said you can also leave comments on the Notion or Google Docs page and tag the Bot to revise the spec. This isn't in the docs yet. If it doesn't work for you, paste your comments into the conversation instead.
Next, the team asked Pete to pass the PRD to Emily, and asked Pixel for designs for each P0.
Day 1 · 6:21:39Voting on Pixel's two designs
Pixel delivered options A and B. The audience picked A, and the design went to Emily. Emily split the P0s into scoped tasks for its engineer Bots. One of them, Nova, launched a cloud agent and kept watch over it. The final prototype wasn't shown in the session.
Charts without the query
- Trusting a chart without the query. A wrong join (the way two tables are combined) or date filter looks just as convincing as a right one. Fix: ask for the query and the source link with every number, and spot-check the first answers.
- Letting your hypothesis steer the analysis. The Bot may confirm what you said instead of what the data shows. Fix: ask the data Bot to check your reading, as Ashley did with the seat-selection guess.
- Scheduling a report with no missing-data rule. The routine posts old numbers as if they were current. Fix: state what the Bot should do when the source is empty or stale.
- Skipping the spec review. Designs and prototypes pile up on top of a wrong requirement. Fix: review the P0 list before any design work starts.
- Asking the data Bot to change things. A dashboard, alert or production setting gets modified during an "investigation". Fix: keep the data Bot read-only and put changes behind approval.
Every stage ends in something you can check
- A product team of Bots is a relay: data, spec, design, prototype, with each stage ending in something you can check.
- With every data answer, ask for the query, source links and a split between facts and assumptions.
- Turn a useful question into a routine only after you define the schedule, the time zone and what happens when data is missing.
- Review the numbers, the spec and the design choice yourself before the work moves on.
- Reply to the specific message when you hand a finding to another Bot, so the context travels with it.