Lessons I carry from project to project.

On one engagement I ran four different ad funnels, changing one variable each time. Each test taught something, but slowly, because nobody could tell which leads turned into sales.

One week of proper event tracking taught more than all those months of changes. The answer was not in the ads. Demand was in one part of the city and the stock was in another.

Since then I treat measurement as a first step, not a follow-up task. If a team cannot see the result of a change, it is guessing, however good the change looks.

Paid traffic sent to a broken catalog does not test the catalog. It multiplies the problem and makes it more expensive.

The unglamorous work came first: rebuild the product data, then automate the repetitive parts so the team could move fast without cutting corners. Growth came after, and it was easier to read because the base was clean.

A website can be a weak store and an excellent discovery engine at the same time. Forcing the original model would have kept the weak part.

Repositioning it, from a store to a catalog that opens a consultation, solved a pricing problem at the root and let the site do the job the data said it did best.

When one item in a sprint carries most of the uncertainty, I do not plan around it as if it were known. I give it a short technical spike first.

The spike costs days. Discovering the same thing halfway through a sprint costs the sprint. The same goes for vendors: if a provider cannot do the one thing that matters, it becomes a fallback, not the plan.