Don't learn frameworks, learn how to solve business problems.

If you've ever wanted to become a data analyst but you weren't sure how to approach it, this post is for you!

Data teams are often run like service organizations: a request goes in, an answer comes out. To stem the ceaseless flow of questions, we do what any reasonable analyst would: we answer questions faster, we build dashboards on dashboards, we push back, and, failing all that, we jump the chasm and try to teach our stakeholders SQL. Yet this particular cocktail of solutions is both all-too-common and all-too-commonly ineffective. The root cause of this chaos: we’ve failed to define best practices around how we should be collaborating around analytics. In this post, I’d like to nail down once and for all what analytics collaboration is and how we should be making it better.

Data analysts analyze data to drive business value. This purpose is often pigeonholed into Supporting The Decision-Making Process, but this isn't quite the entire story. Analysts are experts at not only analyzing but, more importantly, studying, interpreting, and navigating the massive streams of data your company is likely ingesting. The best analysts are not transactional data APIs, taking in requests and returning data, but act as advisors and explorers in the overwhelming, high-opportunity, yet often deceptive world that is data. Analyst work can be bucketed into one of three categories: - Reporting & self-service: creating data products (dashboards or apps) that enable others to directly look at data. - Ad hoc requests: reactively supporting business decisions and problems with data. - Strategic initiatives: proactively finding opportunities in the data. In this post, we'll discuss each of these responsibilities, what they entail, and what qualifies as excellence therein...

When I was a data scientist at Airbnb, I once received an ad-hoc request to identify Olympians that had accounts on Airbnb. No context given, just a colorless request in Slack. After a day of painstakingly scraping the web and munging data in SQL, I dumped the data into a table in our data warehouse, sent it off, then promptly moved onto other work.Months later, I discovered that this work had contributed to the launch of a new business segment: Olympian and Paralympian online experiences. I felt proud that I’d been able to directly contribute to the business in this way, but I was bothered that no one had thought to let me know that the launch had occurred, let alone include me any more deeply in the launch process. I’d never felt more viscerally that my role in the product-building process was that of data vending machine: request in, data out...

Announcing multi-cloud EU data residency support in Hyperquery.

Announcing Hyperquery's take on version history.

It’s finally here. Python ❤️ Hyperquery.

Announcing our first cut of HyperAI, our first experiment into LLM-supported analytics - sign up for private beta access today!

Let's talk about what's been happening in analytics over the last decade, and why modern analytics deserves its own tool.

Last year, Emilie Schario and Taylor Murphy proposed this wonderful idea of “running your data team like a product team”. The key premise of the article was this: product teams have a lot of great practices that data teams would benefit from adopting. But somewhere along the way, we lost sight of this point and happily replaced it with strawmen: maintaining production-grade systems for our data assets, building more data products, or painstakingly defining what production means in service of hardening data contracts. All of these are certainly worth consideration, but they’re concerned more with the proper handling of data and data assets rather than the data teams that actually drive the impact. The central idea here was never to quibble over the definition and boundaries of the “Data Product” or set SLAs for data producers, but rather to compel us to reconsider how data teams operate by using product teams as a model. I’d like to spend some time discussing precisely how to run your data team like a product team.

You need analytics. And while no-code solutions like Google Analytics will get you quite far, around your Series A, you’ll realize there are far too many questions you can’t answer, and you’ll start Googling “how to set up analytics properly” to jerry-rig a solution. You’ll swim through a sea of...

If you’re like me, then you’ve had (many) experiences working with people who aren’t data savvy. This isn’t meant to be judgmental. It’s just a statement of fact.

You’re building an enterprise SaaS company and looking to put together a top-notch sales team. Given the choice between a car salesman and a car mechanic, who would you prefer to add to your team and sell your software?