Innovation in Name Only.

A major adult beverage brand wasn't asking whether it was growing. It was asking whether it was shrinking more slowly than the year before. In an industry where total volume has declined for years running, the operative metric is year-over-year performance compared to year-over-year performance. Not "did we sell more?" but "did we decline less?"

That context frames everything about the urgency this team felt, the structure they built, and why a twelve-week engagement with two people ended up changing how they wrote software, delivered data, and measured outcomes.

THE PROBLEM

The client had done something reasonable given the pressure they were under. Frustrated with the pace of their IT organization, they got executive buy-in to stand up a tiger team. A dedicated analytics group, carved out of traditional IT structure, given autonomy to move fast and use new tools. Out with Teradata and SAP Business Objects. In with Google BigQuery. No more waiting on IT. No more bureaucratic overhead. Just a small, empowered team with a mandate to find opportunities across marketing spend, product launches, and distribution.

The team was staffed thoughtfully: a project manager, a data scientist, two Tableau developers, and an offshore ETL development and testing team using Talend.

Six months in, the same complaints that had driven the creation of this team were back. Business stakeholders weren't using the Tableau dashboards. They were asking for data exports to do their own analysis in Excel. New requests were taking weeks to deliver.

The tiger team had changed the tools. They hadn't changed the habits.

WHAT WE FOUND

We came in for a six-week assessment. Two people: an engagement lead and an analytics engineer. Our approach was simple: see the work, not just hear about it.

We shadowed internal team meetings, sat in on stakeholder requirements sessions, and interviewed both technical and business stakeholders. Then we did one simulated build exercise. We took a requirement from business ask to delivered dashboard. Not asking what the process was. Living it.

The simulated exercise is where the real picture emerged.

We were paired with a sales support team responsible for working with distributors to increase product placement across bars and venues. They wanted a tool to help sales reps have more productive conversations with bar owners. The pilot market was San Diego. Five sales reps. More than 200 physical venues.

We wrote SQL directly in BigQuery, ran venue classification algorithms, and pulled in Foursquare and Yelp data to model traffic patterns, peak hours, and venue type. The output was genuinely useful. We could tell a sales rep: this bar over-indexes on male customers, underperforms on Tuesdays and Wednesdays, and doesn't carry Blue Moon. Blue Moon, as a brand, skews heavily female in its consumer base. The brand's own sales data confirms it. If a venue is under-indexing on female traffic and not carrying the product most likely to bring them in, the recommendation is not a guess. It is the data pointing at an obvious gap. A Blue Moon happy hour special targets the demographic, lifts mid-week traffic, and gets a new tap handle. The pitch writes itself.

“If a venue is under-indexing on female traffic and not carrying the product most likely to bring them in, the recommendation is not a guess. It is the data pointing at an obvious gap.”

That took three days to build. Business stakeholders were immediately bought in.

Then we entered the formal delivery process.

Because we had the full business logic written and validated in BigQuery SQL, we expected to move fast. Instead, we were required to translate that SQL into Excel mapping documents, hand them to the offshore Talend team, and wait for them to rebuild the same logic in GUI-based ETL flows.

One sprint to translate. Numbers came back wrong. Another sprint to reconcile. Still broken. What took us three days took six weeks inside their process. A team handed explicit autonomy to move faster was still operating like the organization they had separated from. Innovation was in name only.

The tooling issue was separate but equally clear. Tableau is a capable analytics platform. It is not a field sales tool. The San Diego reps were young, working off iPads, visiting venues on foot. Optimizing a Tableau dashboard for iPad resolution and touch input is not trivial. So reps weren't using the dashboards. They were opening them on laptops, screenshotting filtered views, and pasting the screenshots into PowerPoints to carry into meetings.

That is not a workflow improvement. It is additional work.

Reps disengaged from the data entirely, and that perception spread. The data tools were seen as complex, added friction to an already busy job, and weren't worth the effort. The analysis was good. The delivery was wrong. And wrong delivery makes good analysis invisible.

WHAT WE BUILT

The ETL process was the first thing we pushed back on. The goal of IT governance isn't the GUI. It's auditability, reproducibility, and code review. We proposed keeping the business logic in SQL, committed to Git, with Talend serving as the orchestrator rather than the authoring environment. Same governance requirements. No new tooling. The offshore team didn't need to retranslate anything; they needed to stop transcribing.

The result: the team went from delivering one use case per three sprints to three or four use cases per sprint. Roughly a 10x change in throughput.

The delivery fix was simpler. Sales reps lived in Salesforce. Every scheduled visit, every account note, every commission record ran through it. So we embedded the Tableau dashboards into a Salesforce Lightning page. The analysis didn't change. The data didn't change. It was now inside the tool reps were already opening every morning.

At the end of the engagement, we used Salesforce activity data to build a sales leaderboard and measure dashboard usage. We then compared quota performance across reps who were using the embedded tools against those who weren't. Reps using the tools exceeded their quota by roughly 20% more than peers who weren't.

That gave the business an internal proof point. Not just that the tools were built and adopted. That using them changed outcomes.

OUTCOMES

The San Diego pilot produced a 10% increase in on-premise sales across the 200-plus venues in the market following full rollout.

That number didn't stop the industry's broader decline. It wasn't supposed to. The goal was to slow the bleeding in one market, put data in the hands of people positioned to act on it, and prove the model. San Diego did that. Subsequent markets launched with meaningfully better adoption because the process and delivery changes were already in place before they went live.

WHAT THIS MEANS FOR OTHERS

Three things surfaced in this engagement that show up repeatedly across organizations trying to move faster with data.

Structural autonomy is not the same as process autonomy. This team had the authority to use different tools, but they did not question the processes governing how they built with those tools. Calling something a sandbox doesn't make it one. The real work of moving fast is examining the internal habits that slow you down, not just swapping the infrastructure they sit on.

Data is only useful where people already are. The analysis was correct. It was also invisible because it required extra steps to reach. Embedding it in Salesforce didn't change the analysis. It changed whether anyone saw it. Delivery is not a last-mile problem. It is part of the product.

A tool that discourages use is worse than no tool. When the dashboards became a burden, reps disengaged from data entirely. That perception is hard to reverse. The long-term willingness of an organization to trust data in its decisions is built or eroded one delivery experience at a time.