2026-02-18

The 4-Hour ML PM: How Sarah Shipped a Forecast Without a Data Team

It was 2 PM on a Tuesday in August. Sarah, a Technical PM at AudioPhile, a boutique headphone brand, had a problem.

The CEO wanted a Q4 sales forecast to lock in inventory orders. The stakes were high: order too little, and they sell out before Christmas. Order too much, and they burn cash on warehousing.

Sarah checked the Data Science team's Jira board. Fully booked until November.

She opened a terminal. She wasn't an ML Engineer, but she had Gaslamp.

The Prompt

She didn't ask for code. She asked for direction.

/gaslamp I need to create a time series forecasting model, for a 
e-commerce site like ebay to predict seasonal sales for headphones, 
what should I do firstly

A standard AI coding assistant would have spit out a generic PyTorch LSTM script. Gaslamp didn't.

Phase 1: The Interview (Stopping the Wrong Build)

Gaslamp paused. It acted less like a tool and more like a Principal Engineer.

[Gaslamp] Hold on. Before we talk models, we need to define the risk profile.

  1. Inventory Risk: If we predict 1000 and sell 500, we lose cash. (Cost of Over-prediction).
  2. Revenue Risk: If we predict 500 and demand is 1000, we lose sales. (Cost of Under-prediction).

For Q4, which is worse?

Sarah realized she hadn't thought about the penalty function. She replied: "We need to avoid stockouts. Under-prediction is the killer."

Gaslamp updated its internal context.

[Gaslamp] Understood. We will optimize for MAPE (Mean Absolute Percentage Error) but penalize under-forecasting.

Artifact Created: project_brief.md

Phase 2: The Asset Hunter (Finding the Data)

Then came the blocker. Sarah didn't have historical sales data handy—it was locked in a legacy ERP system she couldn't access.

Standard AI would have stalled here: "Please provide a CSV."

Gaslamp pivoted.

[Gaslamp] Data Strategy Strategy: Since we don't have internal sales figures yet, we can use Google Trends as a high-fidelity proxy for demand.

Search volume for "Noise Cancelling Headphones" correlates 0.85 with actual sales.

Action: Generating download_data.py using pytrends API...

Within minutes, Gaslamp had scraped 5 years of weekly search volume. It didn't just ask for data; it found it.

Artifact Created: data_strategy.md

Phase 3: The Architect (Right Tool, Right Size)

With 260 weeks of data (5 years x 52 weeks), Sarah felt ambitious. She'd read about Llama-3 and Transformers on Twitter.

[Sarah] Should we use a Transformer or a Time-Series Foundation Model for this?

Gaslamp pushed back.

[Gaslamp] I advise against that.

You only have 260 data points. A Deep Learning model (Transformer) will likely overfit and hallucinate patterns.

Recommendation:

  1. Prophet: To capture the strong yearly seasonality (Christmas spikes).
  2. LightGBM: To capture short-term trends.

Artifact Created: training_config.yaml

It prevented "Resume-Driven Development" and enforced engineering discipline.

Phase 4: The Vibe Check (The Result)

Sarah typed gaslamp run. The fan on her MacBook Air spun up. Four minutes later, the results were in.

[Gaslamp] Evaluation Report:

  • Baseline (Naïve): "Same sales as last year" → 25% Error.
  • Gaslamp Model: Prophet + LightGBM → 14% Error.

Verdict: PASS. The model is 11 percentage points better than the baseline.

Artifact Created: eval_report.md

The Outcome

Sarah walked into the CEO's office at 6 PM. She didn't just have a number; she had a signed-off engineering artifact.

She showed the eval_report.md, tracing the decision from the Inventory Risk definition to the Google Trends proxy validation. The CEO signed the purchase order.

Sarah shipped a production-grade ML forecast in 4 hours, without writing a single line of PyTorch herself. She simply managed the decisions, and let Gaslamp handle the execution.

That is the power of a Principal Collaborator.


> Note: While this story is based on a real customer use case, the names of the company, brand, and individuals have been changed to protect privacy.