I like the problems that don't come with instructions.

• Fix the economics before chasing growth. Selling more would only have grown the losses.
• Make it work for everyone. Designers needed the pay to be worth their time, customers needed the same quality, and the business needed customers to keep buying.
• Start narrow. One simple product, one market, a few hand-picked designers, and the first jobs reviewed by hand.

The pilot exposed a gap: if a designer dropped a job, there was no way to reassign it. We fixed that before scaling. As we expanded in stages, we also learned the pay worked for simple designs but not complex ones, which led to pricing by complexity.

• Better unit economics: loss per design down 77%.
• Growth without headcount: most demand served by freelancers, so growth was no longer tied to fixed headcount.

Marketplace operations, design operations, support, customer experience, engineering, product, and other teams across the domain.

• I treated discoverability as the upstream constraint, ahead of conversion.
• I looked for moments in the shopping journey where the service was genuinely relevant.
• Those pages belonged to other teams. I negotiated experiments with shared metrics and guardrails, so testing was a yes for both sides.

The placements we tested grew visibility and orders. Next, I turned to the brief customers filled in before a designer started.

Our first redesign tested well with users but lost in the live test. Instead of shipping it, we asked why. We had removed the moment when people check their answers and feel confident before paying. We added a review step and clearer pricing, and tested again.

Traffic grew 2,000% from one tested placement, and order volume grew 50%. Brief completion then rose from about 6% to about 13%. Several changes went in together, so no single one gets the credit.

Funnel diagnosis, experimentation, cross-team influence, customer research.

• Judge the experiment on the outcome the service exists for, not the step it changed.
• When the local win and the downstream result disagreed, roll it back rather than keep the better-looking number.
• Find out why before trying again.

We reviewed sessions and spoke to customers who had finished the brief but didn't go on. Some had completed it in a minute or two with barely any edits. They told us they still wanted to decide the colour, style and direction themselves.

The AI hadn't necessarily been wrong. It had taken away decisions people wanted to make, so the brief was easy to finish without reflecting what they actually wanted.

We rolled the experience back. We then explored a different direction: a conversation that asks clarifying questions, the way a good designer would, rather than automating the creative work.

AI product judgement, guardrail metrics, customer research, intellectual honesty.

• Where to start: schedule delay, because schedule data was standardised and had historical outcomes to learn from. Broader risk was exciting, but every company recorded it differently.
• Who for: project leaders who needed visibility across projects, before specialist schedulers who needed far deeper tools.
• When: early access, rather than months of discussing a product customers couldn't use yet.

I turned an expansive AI vision into a focused first product, working with data science, engineering, UX and sales. A probability of delay isn't useful unless people can see what's driving it, so we focused on making predictions understandable.

The product launched with early customers. I supported customer conversations and trained Sales to explain probabilistic predictions honestly, limits included.

Zero-to-one discovery, ML product strategy, narrowing ambiguity, go-to-market.