← All case studies

Discovery & workflow design

Pixability

Adoption looked healthy. Two teams had quietly stopped trusting the data.

Two major client teams had routed around Looker and were collating reports by hand. Following the workaround instead of building another dashboard cut sixteen to twenty hours of manual collation per cycle to thirty minutes of QA, while protecting the insight work that was the actual value.

Service: Fractional Product Leadership

16–20 hrs → 30 min

Manual collation per report cycle, largest teams

48 hours

Intervention that tested the path before scaling

1 hour

Of human insight work deliberately preserved

Selected work from my time as VP of Product at Pixability (2020–2024).

The problem

Pixability had mature data pipelines, reporting infrastructure, and dashboards. Customer-facing teams were still assembling recurring reports for major accounts by hand.

A year after the self-service rollout, most teams were pulling data successfully, but each had built its own weekly report on top of it and the quality varied. Two of the largest client teams had gone further. They had quietly routed around Looker, the source of truth, pulling platform data directly and concluding that internal analytics was wrong. Their job was to explain what had changed and recommend next actions before customer conversations, and the platform was not making that easy, trusted, or obvious.

Adoption, performance, and NPS all looked fine. None of them showed this.

What I did

Treat the workaround as evidence, not user failure

The first move was not to build a dashboard. It was to follow the workaround.

Routing around the platform was a signal that something in the workflow was missing. I reconstructed the job those teams actually had to deliver, then worked back to what the product made hard: reconciling numbers against the platform, knowing where to investigate a discrepancy, and producing something a customer conversation could be built on.

Rebuild the path the teams would trust

I started with the highest-friction, highest-value manual reports and partnered with customer success, ad operations, sales, and analysts to validate what mattered in them. The manual artifact became a unified report format, then an automated starting point, with QA checks and investigation cues for the platform's known reporting quirks.

The argument that moved the teams was not about the tooling. The value they brought was the insights, so that was the part to protect and everything underneath it was mine to automate.

A 48-hour intervention tested that path with one team before anything was built to last.

Get three functions to agree on one artifact

The automation was not the hard part. Getting sales, account management, and ad operations to agree that this was the standard report was, and it took longer than the build. Each function had a different idea of what a report was for and a different account it could not afford to disrupt.

That agreement had to come before the mandate, not after it. A standard imposed on three teams who had not settled what it was for produces compliance and then, six months later, a fresh set of private spreadsheets.

Prove it before scaling it

Scaling a reporting workflow is how a company acquires a new set of custom reporting traps, so five questions had to be answered first: whether it removed meaningful Monday work, whether the output matched what teams needed for customer conversations, whether users could reconcile the numbers and know where to investigate, whether go-to-market teams would align on a standard report instead of bespoke one-offs, and whether it could expand past the first two teams.

Lifecycle ownership is what made it durable. Without a named owner the workflow would have drifted again.

The outcome

On the largest teams, two people were spending sixteen to twenty hours on each report cycle collating data by hand, weekly or biweekly depending on the account. Within the 48-hour intervention most of that was gone: first to about an hour of QA, then to thirty minutes. Both teams came back to the source-of-truth workflow.

What did not get automated matters as much. With collation handled and the easy insights generated automatically, the teams spent their time on the part that was actually worth their salary: an hour of brainstorming what the numbers meant, then one or two people writing it up for the customer. Smaller teams, who had less appetite for that, could take the automated insights directly. The workflow stopped forcing everyone through the same shape.

It was mandated, and the mandate held. Most teams, once they saw the reporting built for the A-tier accounts, abandoned the version they had built themselves rather than defending it. That is the answer to the scalability question, and the two halves are inseparable: the artifact had to be better than what people had already made for themselves, and the functions that would have to live with it had to have agreed on it first. Either half alone produces the reporting mess again.

Teams stopped starting from zero every Monday, reporting QA became more consistent, and go-to-market teams aligned on reports the company could actually support.

The part worth keeping is what it cost to learn. We actively managed this product after launch and a shadow workflow still emerged, because healthy adoption can hide drift at the workflow level. Adoption, performance, and NPS are snapshots; they can all hit their targets while local workarounds grow underneath them. I would now monitor workarounds and workflow-level trust alongside them.

The same question came up again in a confidential insurtech engagement and got a different answer. Operations and sales were pulling from different sources there too, so a source of truth was plainly needed. I proposed standard reports on the strength of this work, and operations pushed back on two grounds, both of them right. Their questions were still moving, so standardizing then would have frozen the wrong ones. And nobody wanted to own a report, which needs a maintainer in a way a dashboard does not.

So the dashboard became the report. We shaped that as the MVP, carrying the answers that were already settled in a surface nobody had to maintain as a document. Data exploration came in phase two, once there was enough evidence of what people actually needed to explore.

What decided the form was not the data. It was how settled the questions were and who was willing to own the answer, which is the same lever as the lifecycle owner above, pointing the other way.

The shape is not specific to one company or one cause. I have found it where the data was not trusted, where it was scattered across sources nobody had reconciled, and where it existed and nobody knew it did. The workaround looks different each time and means the same thing: somebody has written down the requirement, in the only form they had available.

The product was never the chart, the dashboard, or the export. It was the trusted decision workflow that compounds over time.

Have a version of this problem?

Book a Clarity Call