Compass

Act 1 — How Compass started

Compass began as a CEO experiment. Frustrated by how long it took to get answers to basic business questions, our CEO vibe coded a prototype over a weekend and started using it himself. He showed it to a data analyst, then the CTO and Head of Product. The reaction was immediate: this should exist.

I had experience working across design and front-end and prototyping so they asked me to join the experiment. and see if we could.

When I joined, Compass was functional but hard to use. The core problem was the data management experience — the place where users connected and configured their data sources. The steps were unclear and the order was wrong. Alongside the team, I redesigned it from scratch — working directly with Claude to move fast — clarifying the steps and making the structure legible. Onboarding was still happening in Slack at this point, but this was the moment it started to feel like an actual product, not just a Slack integration.

This was also the first time I was using AI to write code I couldn't have written manually. By July 2025 I'd used Claude and ChatGPT extensively for design work, but Compass was where I crossed into using AI to push production-level code alongside our CEO and CTO. We were building an AI product while learning in real time what AI-assisted development actually meant. That context shaped everything about how we worked.

Act 2 — Learning what Slack could and couldn't do

Our CEO wanted Compass to be Slack-native and Slack only. The instinct made sense: that's where work happens, that's where the magic felt most natural. So we tried to make it work.

We used Slack Connect instead of building a full marketplace app, which let us move fast without going through Slack's approval process before we'd validated the idea. But Slack Connect introduced its own complexity. Every organization has different permissions for adding external apps and channels. What worked in one environment broke in another. We were creating ten to fifteen test Slack orgs a day trying to recreate the different configurations we were encountering.

The governance model made it harder. The original design had two channels — one for chatting with Compass, one for admins to manage context and approve data requests via GitHub PRs. The idea was sound: keep humans in control of what Compass knew and how it responded. But in practice it meant users had to onboard in one channel, then move to another before they ever saw Compass work. The a-ha moment was buried too deep. And managing two channels felt like overhead nobody wanted.

The onboarding flow was also fragmented. Users were bouncing between a sign-up page, email, Slack, a data connection page, and back to Slack. The experience was confusing and disjointed.

After months of testing we made two calls:

Onboarding had to move out of Slack. The web was the right place for setup, data connection, and configuration. Slack was the right place for conversation.

Admin and governance had to move out of Slack too. One linear flow — sign up, confirm email, connect data, then enter Slack — replaced the fragmented multi-surface experience. Context management and governance moved into a web UI with a proper audit trail and clear ownership.

The product got simpler. The constraints had forced better decisions. This allowed us to better focus on the different surface areas of Compass - Slack for conversation and the web for management. It also opened the door for a more robust product that wasn't confined to Slack.

From there things moved quickly. We shipped a full web-based admin UI — giving data teams a single place to manage connections, channels, users, governance, and billing. We launched to alpha users, iterated through beta, and hit GA in under six months. Compass debuted at #3 on Product Hunt.

Act 3 — Seeing what the numbers were saying

After GA, we begin expanded the capabilities of Compass , with a playground for testing prompt accuracy and a full browser-based experience that made Compass accessible entirely outside of Slack.

Since the beginning, we had a hunch that Compass alongside the power of Dagster+ would add an immense amount of value for existing Dagster users. Our team had been working on a prototype to integrate Dagter+ into Compass. But we weren't sure how it would be recieved. We had been treating Compass like a separate product with a very different audience. We thought it would be a hard sell to get existing users to adopt something new, even if it was better. We thought we'd have to convince them with marketing, sales, and education. We started beta testing the Dagter+ integration with a small group of users. Then something unexpected happened. Adoption was immediate. 18 out of 24 teams activated Compass within 36 hours of being told about it. They didn't evaluate it. They didn't need convincing. They just turned it on.

That was the moment it clicked.

We had spent months trying to figure out who Compass was for — sales leaders, RevOps teams, business users, data analysts. We kept expanding the target and diluting the message. Compass was for everyone, which meant it was for no one. Meanwhile the users who were actually adopting and staying were almost entirely existing Dagster+ customers.

The reason wasn't the product. It was trust. Dagster+ users already trusted the platform. They didn't need to evaluate whether Compass was safe or reliable — they assumed it was, because Dagster had already earned that. We were treating Compass like a brand new product with no credibility in the market, when we actually had years of trust already built.

Since the beginning of Compass, I had been working at the intersection of product, brand, and go-to-market. I brought a proposal to leadership: let's stop fragmenting the two products and lean into what was already working. Dagster is the platform. Compass expands the reach. Whatever the entry point — Dagster+, Compass, or open source — you're in the Dagster ecosystem.

On the Dagster+ side, we had been struggling to see how Compass fit into Dagter+. Should Compass power all AI features? Should it be in the Dagster+ product at all? The proposal reframed Compass not as a standalone analytics tool but as the conversational intelligence layer of the Dagster platform. Dagter+ is already intelligent - we didn't need a new product to add those capabilties. Compass would live inside Dagster+ as the conversational layer — not bolted on, not opt-in, just there — while also remaining available as a standalone product for teams that needed it outside the platform.

Leadership approved the direction. We've begun work on an updated brand system, the product architecture, and the go-to-market strategy all now reflect a single coherent story.

Reflection

Compass changed how I think about how teams can build products.

Not universally — context matters. But on a tiger team moving at this speed, the medium stopped mattering. I've always designed in code — that's not new. What changed was the ceiling. I was pushing production-level code I couldn't have written by hand. Our back-end engineers were building front-end prototypes alongside their architecture work. The distance between an idea and a working thing collapsed for everyone on the team, not just me. We moved faster together because the walls between roles got more permeable.

What I learned is that the most valuable thing I brought wasn't a specific skillset. It was the clarity to figure out what the team needed and the range to go do it — whether that was systems thinking, brand strategy, or shipping a docs site in 24 hours.

AI didn't replace design thinking. It let us act on it faster.