While many are debating the merit of replacing human jobs with AI, the reality of competing in the rapidly evolving 2026 business landscape requires a new approach to organizational design.

The machines now make business decisions faster than humans can react. Campaign planning migrated from months to minutes. A/B tests went from weeks to minutes. The observe-orient-decide-act (OODA) loop once spanned quarters. Now it spans hours. Competitors who automated their decision layer are running fifty iterations before the creative meeting starts. They are testing offers the team has not conceived yet. They compound advantage because they are skipping the human interrupt entirely.

This is not theoretical. The technology debate is over. We are talking tactics now. Models like Opus 4.6 scoring this high on the METR benchmark running in a proper enterprise harness has irreversibly changed how revenue organizations scale.

Better models are not the bottleneck. They work now if the data infrastructure is ready to receive them. That readiness is the gap. A few well-crafted Claude Code sessions can stand up automated decisioning systems that compound daily. That gap does not close. Any leader who has not personally automated a decision-making function in the last month is making decisions with a stale map.

The constraint is no longer capital. It is no longer raw talent. It is implementation speed. In 2026, the separation between companies will not be who has the biggest GTM team. It will be who figured out how to decouple revenue from headcount entirely. Who built autonomous systems that observe market conditions, orient to customer signals, and execute bidding and routing decisions without waiting for human judgment to catch up.

A headcount-first GTM strategy is not “inefficient”. It is not “slow”. It is an existential liability.

The companies that figure this out will not just grow faster. They will grow cheaper. Decoupling revenue from headcount is not optimization. It’s structural. The Burn Multiple compresses. The Rule of 40 stops being a ceiling and starts being a floor. That is the prize.

The company structures and leaders that got us here are not equipped to build autonomous revenue systems. The reason is not talent. It’s incentive. The organizational structure is optimized to do the opposite of what needs to happen.

Marketers are rewarded for managing teams, negotiating vendor contracts, and shipping quarterly initiatives. They are not rewarded for building invisible infrastructure. Measurement systems do not look like wins. Data architecture does not ship to customer-facing channels. So it gets pushed back, indefinitely. Meanwhile, vendors show up with tools that promise “AI-powered marketing” and get funded because they are visible, shippable, and create the impression of modernization.

Ground truth about profitable customers is distributed across systems that were never designed to agree. It sits in the CRM, the billing system, the ad platforms, and three analytics tools that contradict each other. Nobody stitches it together. Integration work is invisible. Invisible work dies. So GTM teams are making seven-figure decisions with 30% visibility. Seventy percent of signup attribution traces to untracked channels. And that is exactly why the headcount model persists: when nobody can see, companies need people to guess.

This is not a technology problem. It is a prioritization problem. And it is structural. And the champion for it will not come from inside the existing departments.

Mastery of the old game actively prevents seeing the new one. The marketer’s entire career was built on managing headcount and channels. Architecting systems was always someone else’s job. Almost overnight, the majority of marketing spend has become a systems architecture problem. An AI decisioning system cannot optimize for a metric nobody trusts being computed in real time.

The inversion is simple: automation thrives on measurement and feedback loops. Most companies will spend 2026 buying AI copywriters, ad designers, and email optimizers. UI layers painting over plumbing filled with skeletons. They will celebrate 15% productivity gains and assume they are keeping pace. They are not. The gap is not closing. It is widening. The companies that do the hard work of connecting the data layer will discover something entirely different: modern AI, given a clear optimization target and a harness to work from, does not improve the old game. It dissolves it entirely. Those companies will operate at a fundamentally different velocity.

Here is what that velocity looks like. Two companies. Same market. Same keywords. Titan runs paid acquisition the standard way. Smart team. Weekly optimization. On Tuesday they spot a high-converting keyword cluster. They adjust bids, reallocate budget, push new creatives. Changes go live Thursday.

By Thursday, the battle was already over.

Phantom has a stateful revenue machine. It spotted those keywords six days ago. Tested them. Found the adjacent long-tails, the misspellings, the question variants, the comparison terms that convert at half the cost. Positions Titan cannot see from their tooling. By the time Titan adjusts on Thursday, Phantom has already harvested the cheapest inventory, driven up the auction price on the terms Titan just found, and moved to the next cluster. Titan bids up. Phantom is gone. Titan finds another pocket. Phantom was there first. Every time Titan reacts, the machine has already priced them out and relocated to cheaper ground. Titan is not behind by a few days. They are structurally more expensive on every keyword, every impression, every conversion. Worse, they are blind to it. Their CAC is permanently higher. Titan’s data was accurate. Its decisions were rational. It never saw the gap because Phantom got inside its OODA loop. That gap compounds daily.

This is not science fiction. It is operational reality today. The difference is not the model. It is what surrounds it.

Most companies chasing AI in 2026 are stacking elaborate instructions, chaining prompts, fighting the model into rigid behavior. This is a dead end. Prompts break on every model upgrade. They have no memory. They cannot learn or grow. The shift is from prompt engineering to stateful machine engineering.

The principle is counterintuitive: stop telling the intelligence what not to do. Build a bounded environment and unleash it. The more clever the box, the more powerful the intelligence becomes. The box holds. The intelligence compounds. The system learns. That architecture has a specific shape, and it applies everywhere a human currently stares at a dashboard (the “state”) and makes a judgment call.

The stateful machine has four components. The next piece goes deep on all of them.

In 12 to 18 months, these architectures will be a feature inside every major ad platform. Not a competitive advantage. Not a moat. A checkbox. But the ones who upgrade their architecture internally today will maintain a strong advantage thanks to cumulative learnings of their state machine.

The speed of movement becomes the moat. Early movers acquire customers at 30-40% lower CAC. They bid higher on only valuable inventory. They hit 6-month payback while competitors still report 12. They have eaten the competitors margins and current best practices won’t even detect it. The differential becomes permanent.

The revenue organization of tomorrow is small. One architect, workers managing guardrails and an exception handler. Not thirty. Not a department. A tight system.

Given sufficiently advanced intelligence, the future belongs to measurement architects and target function designers. The ones with the most taste win.

The default heuristic is that human judgement is necessary. The companies that disprove that first are not getting a head start, they are filling the only seats left when the music stops.

I am writing the next piece now. If there is a specific part of this architecture you want me to go deeper on, let me know.

LLM’s are over hyped and unable to deliver business value

It's a refrain I've heard echoed through posts and articles a lot lately. But here’s the thing, I’m watching from the front row as generative AI (AI) deliver scalable value and I feel like I’m just getting started. Even if LLM intelligence stopped progressing today, it looks to me like we have years of clever implementation and integration work that would create massive value throughout every department in a business. So why the disconnect?

The truth is, many people seem to be expecting AI to act like a seasoned professionals, even up to executives, solving problems accurately with minimal input. But here's a secret: even the best human executives need months of context to succeed. AI is no different.

If you're struggling to envision or implement valuable AI projects, it's time to turn the mirror on your own processes. Are they truly coherent? Do they make sense? Because AI projects thrive on logically coherent business processes. Ideally mapped out with which steps AI can automate.

In my experience, few companies have quality context written down in a way that AI can reliably automate. So, let's explore how AI isn't just a tool, but a mirror reflecting the clarity (or lack thereof) in business processes.

Looking In the Mirror

Enter the "GenAI Mirror" concept. Like a high-definition mirror in a brightly lit room, AI exposes every flaw and strength in your business processes. It's ruthlessly honest, reflecting back exactly what you feed it. When training workers on processes it’s common for gaps and incoherence to be brushed over with a few quick chat questions/answers in their first couple weeks. AI automations are less forgiving.

Ironically, this makes AI an invaluable diagnostic tool for business health. If you're getting subpar results from your AI initiatives, it's likely not a failure of the technology, but a reflection of unclear or inconsistent processes within your organization.

Think of it this way: If you asked a new hire to complete a task without any onboarding or documentation, would you blame them for poor performance? Of course not. The same principle applies to AI.

To better understand where AI fits in your organization's journey, let's revisit the Data & Analytics Maturity Model. A robust AI automation project will require a data-driven feedback loop placing it above reliable dashboards and metrics. So the program looking to deliver value with AI will at a minimum likely need clear processes, instrumented tracking systems, data processing capabilities, and reliable metrics/dashboards.

The GenAI Readiness Checklist

So an AI project readiness checklist would look something like this:

1. Process mapping: Create clear, detailed maps of your business processes. This is both your program architecture to determine where AI can be leveraged as well as the design document for input/output conditions.

2. Context compilation: Build a comprehensive "business collateral repository" that explains your company's operations, culture, and goals.

3. Data accessibility: Ensure your data is clean, centralized, and easily accessible to your AI tools.

4. Metric definition: Clearly define your KPIs and success metrics. This is the target function AI will use to optimize your business.

5. Experiment design: Set up a framework for testing and iterating on AI implementations.

Remember, if you look around your organization and don’t see exactly where AI can provide value, it's probably reflecting a lack of clarity in your processes. The good news? This reflection is your roadmap to improvement.

Start with process clarity. Document, refine, and optimize. Feed your AI tools with high-quality information and watch them become invaluable partners in your business operations.

The future belongs to AI-ready organizations. Those who can clearly articulate their processes, goals, and metrics will find in AI not just a tool, but a transformative force multiplier.

Are you ready to look in the mirror?

Subscribe now

Have any thoughts or feedback? Find me on LinkedIn!

Part #2: Identify Users Early, Often and Consistently

The significance of assigning to each user a unique company-wide user ID cannot be overstated. It allows a company (and AI systems) to quickly and accurately link and migrate users from one system to another. This allows user records to be connected and analyzed through their entire lifecycle at a company rather than in third party data silos of individual applications.

If a user's journey across multiple systems through the acquisition and support funnel cannot be seamlessly tied together, it results in gaps in analyses and integrations. Those gaps will lead to incorrect conversion rates and inaccurate insights that lead the business to focus on the wrong thing—with confidence! All because users changed computers, browsers, email addresses, or just got lost in business systems along the way. This issue can be avoided with relative ease and cost-effectiveness if addressed early in a startup's lifecycle, making the unification of user IDs a part of the company’s culture.

User identity resolution refers to the process of connecting a user's identity across multiple systems and tracking their activities over time. If the frontline systems that run the business don’t have consistent user identity information then connecting the profile of the user from one system to another can become impossible. If user profiles can’t be consistently built across many systems then the user journey is broken and the startup can’t troubleshoot bottlenecks and become more efficient. In the era of generative AI driving down the costs of ad hoc analyses this will become a competitive disadvantage for companies that don’t implement a universal user ID. Automatic analyses will suffer the same disconnects leading to incorrect yet confident answers.

High-quality user identity processes serve as a significant force multiplier for all data and analytics projects within a company. It builds momentum for a business that compounds over time in agility and data quality. The divide between startups that have clean user identity implemented and those that don’t is subtle but pervasive. The gap is measured in higher headcount for system administrators and data engineers than otherwise needed. This means more engineering effort is going to maintenance over time rather than delivering net new projects.

💡 This image is a simplification but effectively illustrates the escalating cost of connecting systems over time and how a small investment in maintaining a universal ID for the business yields compounding benefits over time.

One of the most effective ways to enable user identity resolution is by creating a universal user ID. This unique identifier can link all user-related data across various platforms and touch points.

To accomplish this, a company needs to create a persistent identifier that will be unique to each user across all systems (even if they have multiple email addresses). The ID needs to be static and never change for the lifetime (and resurrection) of the user.

Establishing a Universal User ID

The universal user ID should be stored in a lightweight company wide user database that can be easily accessed through an API endpoint that can create/retrieve a user ID at any time. The goal of the service is to generate and resolve user IDs as far up the acquisition funnel as possible for new users (often before CRMs or product signups are involved).

There are many ways to create and track user IDs across the lifetime of a user that vary based on the size and type of company. I’ll show one example of a custom built solution to illustrate how it works on a public website (which is one place many user journeys get lost due to lack of robust identification).

Universal User ID Endpoint for Website Form Submissions

When a new user is detected by the endpoint, a new user ID is created, stored and returned to the page for submission with the form. Future requests to the service for the same user will return the existing user ID.

The most important part is that the signup/form submission event must be submitted with both the email address and user_id data present to keep all downstream systems in sync.

In this case, the API endpoint is called directly from the website/app as a client side action. Alternatively some behavioral data collection vendors can enrich the sign up/form submission event with the user ID after submission and before passing it along to the destination system.

The same API endpoint should be connected to frontline systems like CRMs and support software to populate the universal user ID as a field on newly created user records in those systems as well. This way as new users are collected across many systems there is a central source of truth for user IDs which can be referenced by all systems within the company.

💡 If the company has a SaaS product then the product database itself can be used for this purpose if it can be extended to create/store users who have not signed up for the product yet but have identified themselves through web forms, support channels, sales processes, etc.

A Note on Email Addresses as Universal IDs

Email addresses are often chosen by startups for this purpose only to be abandoned later down the road, so I would like to save everyone some time here. Do not use email addresses as universal IDs. There are several reasons:

1. Email addresses are considered PII which leads to greater regulatory scrutiny for every single system they are stored in. Have one system where PII can’t be stored? Now it’s disconnected from everything else and a universal ID will need to be created to join the two. And we’re right back where we started, but it’s a couple years later and now the cost of implementing a universal ID is 10x to 100x more expensive and painful.

2. People may change their email addresses over time, leading to multiple email addresses associated with the same user. This results in data fragmentation and difficulty in accurately linking user data across different systems. This may seem minor at first but quickly grows into long discrepancy research projects where analysts and engineers spend days or weeks chasing down apparitions which produces no forward momentum for a business. And the goal of this project is to maintain agility and value creation for the business over time.

3. Users often have multiple email addresses (at least personal and company) and will often interact with some products using both email addresses at different times. This also leads to the user journey being fragmented. Better to allow multiple email addresses to be linked to a single user account as is often seen in late stage products for this exact reason.

Have any thoughts or feedback? Find me on LinkedIn!

A competitive advantage emerges when everyone is able to ask the question but you are the sole possessor of the answer.

I want to start with two ideas that have fundamentally changed the way I think about the future of data team value creation & strategy:

1. Generative AI has forever changed the data & analytics landscape. Clever analysis & growth strategies are becoming commoditized and freely available and will continue to do so at a rapid pace. [1] [2]

2. The business value and benefits derived from generative AI will be concentrated among companies that establish and manage proprietary data sets, which can be analyzed for distinct insights that provide a competitive edge.

Building Proprietary Data Sets

Leveraging AI on top of proprietary data sets has gotten a lot of attention in the past few months and the most common examples given are pharmaceutical companies sitting on a treasure trove of private research data. What I think has been glossed over is the fact that every company can (and needs to) produce their own proprietary data set. For many non-research based businesses (especially SaaS and E-commerce) this means collecting customer behavioral data. In the past this required extra engineering investment and was reserved for later stage companies. However, the newer tools that are available make it a time saving project as the company grows and has to integrate/replace CRM’s, billing systems, communication platforms, etc that all get to share the benefit of first party data collection platform in place with pre-built connectors for all the common tools.

Behavioral data is the key to unlocking the most valuable analyses and models that companies can build including:

• Acquisition funnel efficiency bottleneck analysis

• Paid conversion drivers/correlations

• Customer retention drivers/correlations

The cost of running and iterating on these analyses has significantly decreased due to generative AI tools, such as code interpreter, with more advancements expected shortly. Tracking the right things at a company has always been incredibly valuable, yet it is a rarely discussed topic, often relegated to product and engineering managers.

Historically lessons around missing behavioral data were learned slowly over time by founders asking hard questions but not being able to find answers. I would argue that the next batch of companies will need to learn these lessons earlier to stay competitive. The importance of having a data tracking strategy is becoming elevated to the level of existential imperative for companies today.

I’d like to offer a series of tips to speed up this process, embed best practices into the company’s DNA and put it on a path to data and AI success.

Part 1: Implement First Party Event Collection on Websites and Products the Company Owns

You'll never recover the behavioral data you forgot to collect.

Customer behavioral data is unique among the many types of data a company can generate.

• CRM’s with missing customer information can be filled in with Clearbit/Zoominfo or surveys if the right properties were never collected

• Billing/accounting systems can be audited and inferred based on transaction history at a later date

• Support tickets can be re-tagged and cataloged for analysis at any time

But behavioral data that wasn’t collected can’t be recovered at a later point in time. It's a combination of the exact interaction of market forces and the company's product-market fit at that point in time and won’t be repeated. The value of behavioral data also increases over time, as having a more extensive historical record enables a company to more easily forecast and proactively respond to recurring user trends, such as seasonality.

Companies lacking these frameworks will face difficulties in implementing high-precision growth strategies like:

• Product-Led Growth

• Conversion Rate Optimization

• Growth Engineering

On the surface, these organizations may initially appear similar to those with extensive behavioral data catalogs. However, over time, their paths will diverge as the compounded exponential benefits of small behavioral wins accumulate and positively impact the latter group.

By utilizing tools commonly known as Customer Data Platforms (CDP’s), such as Rudderstack or Snowplow, companies can collect, clean, enrich, and store highly detailed data on user interactions. This information aids in making informed decisions, optimizing user experiences, and driving growth. A significant advantage of this project is that, once the tracking SDKs are installed on the website and product, no additional SDKs are needed for future tool or system integrations. Instead, teams can connect to the CDP and access the existing data stream for shared, consistent data, saving more time as the company expands.

Benefits to Implementing First-Party Event Tracking

• Ownership of data: Collecting first-party data allows for full control and ownership, preventing vendor lock-in, enabling switches between analytics platforms (Amplitude/Mixpanel), and maintaining greater negotiating power with third-party vendors.

• Simplicity of upgrading data stack: Once events are being cleanly generated in a single CDP type system adding new analytics, customer facing, or AI systems on top of a company’s data is greatly simplified. Usually as easy as flipping a switch and letting events flow in or even better, connecting to the data warehouse that holds months or years worth of historical data that can all be processed as well. If this isn't in place, the business will have to start from scratch with each new system added.

• Data accuracy: First-party data is more accurate, as it is collected directly from users' interactions with the website and product. This reduces the risk of relying on potentially outdated or incomplete third-party data.

• Personalization: First-party event tracking enables companies to create personalized user experiences by understanding individual preferences and behaviors across all platforms rather than a single collection vendor. This leads to increased user engagement, conversion rates, and customer loyalty.

Implementing Behavioral Event Collection

Some examples of platforms to check out would be Rudderstack, Snowplow, mParticle, Segment, and Tealium. Each offers different levels of free, open-source, and hosted solutions. Some use a warehouse first approach (my favorite) and others offer data redundancy and backup on their side. Some are better for B2C/E-commerce, while others are suited for B2B/SaaS. Here are some steps to get started:

• Integrate the platform's SDK into the website and/or product to start collecting data on user form submissions, logins, and pageviews.

• Set up a data pipeline to send the collected data to the data warehouse, where it can be stored and analyzed.

• Monitor, analyze, and upgrade the tracking setup to ensure it’s capturing the right data and the company is making the most of it.

The time it takes to implement first-party event tracking varies depending on a company's size, technical expertise, and the complexity of its website or product. Companies shouldn’t try to “boil the ocean” here and can start with just the identify and pageview methods.

For small startups, it should only take a few days, while larger companies may require a few weeks to set up and refine their event tracking infrastructure. The key is to start as early as possible to ensure valuable data is captured from the outset, building a solid foundation for the company's data-driven future.

Additional Tips:

• Relying solely on Google Analytics for website data collection is not recommended due to its limitations in data sharing and user identification. These constraints impede high resolution behavioral data usage because it is harder to get the data out and join it to other systems. While easy to use and beneficial when set up correctly, should serve as just one element of a larger website data collection strategy.

• Don’t install or use third party vendor specific tracking SDK’s on the company’s website or apps. Instead utilize a direct CDP or warehouse connection for sending data to vendors. This prevents vendor lock in and allows the company to clean/process their own data before sending it off. There are a couple exceptions here where third party scripts perform functions that raw data sharing can’t, but this should be used sparingly to keep the company agile.

• As a startup scales and is ready to invest (time) in improving data quality, Google Server Side Tag Manager is also an exciting technology that offers a rich set of data collection techniques that prevents a lot of the client side tracking data loss that is common.

Check out part 2 on user identification now! Have any thoughts or feedback? Find me on LinkedIn!

Subscribe now

This choice will have a significant impact on the team's ability to deliver value over time. Today I’m going to explore what qualities I believe a startup should look for in a data team leader and common misconceptions to avoid.

What To Look For When Founding a Data Team

The success of a data program depends on a founding team member's ability to analyze the company's objectives, plans, and operations to determine the most appropriate data tooling and procurement, hiring plans, data collection methods, and data warehouse setup. Although data scientists and analysts play a crucial role in a company's data program, they may not possess the necessary skills to establish a fully functional data organization from system architecture to impact. Therefore, during the hiring process, candidates should be asked to present their vision for a full data platform and hiring strategy tailored to the company's specific needs. If they are unable to present a clear and concise plan for utilizing the latest tools and why they selected them, it is a red flag that they may not be a suitable fit for the position.

The ideal leader has a T-shaped skillset with broad experience working across many business units and deep experience in data analytics and infrastructure. Each department/function in a company has very different data needs, to highlight a few:

• Marketing - Attribution, identity resolution, web analytics

• Finance - ARR/LTV & monthly snapshotting

• Sales - Pipeline generation, management, snapshotting

• Operations - Help center, support desk, chat

• Product - Activation, monetization, retention, behavioral event instrumentation

These needs all require different tooling for instrumentation, collection and analysis and the leader should ideally be familiar with each. Over indexing on the depth of analytics experience and ignoring cross-discipline experience, the leader will likely have blindspots related to one or several areas of the business where they will be unable to communicate or plan effectively with stakeholders at a startup’s pace. It is a bonus if the leader has seen a data stack implemented multiple times at different size companies as there are many pitfalls that can be avoided by having seen data needs evolve at various scales.

What qualities should they have?

There are a number of qualities that I have seen be successful when hiring data leaders (and data team members):

• Optimism: This is by the far the most important one. With startup data, often everything is be broken, mis-instrumented, inaccurate, and unreliable. Their job is going to be to wake up every day and tackle cross functional/team data issues to provide internal users with high quality data. If they’re not optimistic, they will struggle to maintain the sense of urgency to raise the program to success.

• Adaptability: Startup data and systems are going to change on a daily basis and the data infrastructure is going to need to change with it, rapidly. Hiring a highly structured data team leader may sound attractive but if they don’t architect for rapid change they will always be playing catch up. In addition to that, the data tooling landscape is growing exponentially with vast numbers of new companies making 0 to 1 technology changes that redefine the industry every year. Missing or ignoring these shifts will cost you extra headcount and cause you to fall behind competitors who can move rapidly.

• Technical Aptitude: Data team members must absolutely have a strong technical background in data analytics, architecture and/or data science. They should have an understanding of data modeling methodologies, data warehousing, data system design and visualization platforms.

• Business Acumen: Having a good understanding of the business and industry (or ability to pick it up quickly) will be critical to them driving impact. They should be able to identify the business problems and opportunities that can be addressed through data analytics. Hiring a data specialist with no experience in the business’s field will definitely slow down time to value from data.

• Confidence and Candor: Building a robust and scalable data architecture requires standing up for solid data engineering principles and being able to defend high ROI system spend. If the data leader is unwilling to hold or defend unpopular opinions and instead agree with every business decision they will architect the business’s data strategy into a corner from which it may never escape (think layers upon layers of current state business logic only living in the data warehouse with no historical logs). In my experience, businesses will always push data teams to take on responsibilities that don’t fit their tooling or experience because they can do it “faster” than other teams. Those ad hoc projects come at a huge price when viewed as technical debt over time.

• Owner Mindset: The data team will be building their own mini-startup inside your startup complete with system infrastructure, personnel, and outputting data products. They should be excited about the prospect of fully owning the process and being responsible for the outcomes even when they are difficult and cross functional.

Common Misconceptions

Let’s also look at a couple common misconceptions I’ve seen in startups just getting beginning their data journey.

Misconception #1: Hiring for Experience

Having worked in data and business intelligence for 15 years I believe I safely land in this category and I honestly see a lot of my experience as more of a liability than an asset these days. The rate at which ideas become obsolete has increased and new paradigms cause long held best practices to become obsolete. Some examples are cloud data warehousing, dbt, and generative AI. All of which should change the way data strategists build and plan for long term success.

There are of course some skills that have proved to be robust like SQL, having a data modeling methodology, and collaborating with stakeholders to frame great questions. At the current pace of change of tooling and techniques in the data industry today I spend an equal part of my time unlearning old habits as I do relying on my experience to solve new challenges.

The way that data practitioners strategize and execute depends on their current skillset and what they believe is possible. If I was still relying on techniques from even 5 years ago I would be costing the business a lot of lost time and extra headcount to accomplish what can now be done in a fraction of the time thanks to recent innovations in tooling & techniques (many of which are the purpose of this newsletter!)

Misconception #2: Hiring Data Scientists or Analysts First

Many startups prioritize hiring employees who can "create data products" rather than laying down a foundation for doing successful data work. This is because they want to quickly benefit from the work of those employees without realizing that scientists and analysts require several key technologies and data structures in place to do their work effectively. Typically, this involves starting their data journey by hiring an experienced data scientist and expecting them to quickly create machine learning models to deliver value. This approach causes a number of early setbacks and points of friction.

1. One data scientist who is equipped with high-functioning data architecture can produce better quality and quantity of data products than a whole team of data scientists who start with no infrastructure.

2. Data scientists are high-cost, high-ROI specialists who require reliable data architecture, advanced tools, and resources that many startups lack. Upon onboarding, they often have to spend several months educating the organization on the importance of building a data team while struggling to deliver projects with up-to-date value from static CSV files.

3. Data scientists and analysts often lack the skills, but more importantly the incentive to build scalable data warehouse infrastructure. Instead, they will be more likely to spend months building workable solutions that aren’t intended to scale or improve with time. This means each data project takes the same or longer than the one before it did. Having a strong data and analytics engineering pod in place will ensure that all the work that goes into processing data for data science projects is stored in the data warehouse and easily re-usable for other teams and projects in the future.

4. Data scientists are often not data engineers, data pipeline architects, or data team managers. This means that in the beginning they will need to heavily rely on IT and engineering resources from elsewhere in the business to get their basic data needs met. When they do extract data from systems and load it into data science tools they will likely not prioritize building a foundational ELT pipeline for the future. Their incentive is to build the fastest solution they can to one problem after another rather than hiring roles who can deliver strategic, scalable impact.

Hiring Plan

Each data team will need to be crafted to the organization they are a part of but I can offer a generic order of operations for hiring. If the business knows they will need at least 3 people on the data team in the next couple years I would highly recommend starting with data engineering. This is often overlooked since this data team member often does not turn out visible data products, yet they are the most important foundation for the team. Only after an engineer has been in place for a few weeks would I want to land the first lead analyst to begin building out the baseline reporting. All these roles are quite flexible though and need to be tailored to the exact scenario since many data practitioners have overlapping skills that blur into more than one of these categories. For example, an analytics engineer can certainly be hired earlier if they are also able to flex into doing generating reports and analyses which many can. This hiring plan lays the foundation for being able to deliver on ambitious data projects in months rather than years. They build out a high functioning data warehouse that can scale with the business rather than building ad hoc data flows for specific problems that take longer over time rather than getting faster and faster.

Have any thoughts or feedback? Find me on LinkedIn!

This week we’re going to get tactical for a minute on something that a lot of startups leaders have asked about, data activation for Product-Led Growth (PLG). PLG and its counterpart, Product-Led Sales (PLS), are driving a new generation of rapidly expanding startups. These PLG companies enjoy lower overall acquisition costs, providing them with greater operating leverage to accelerate their growth. While there are numerous guides and articles on PLG product strategy, sales strategy, and metrics to track, a successful PLG strategy requires a robust data activation strategy that is less often talked about.

PLG falls short if startups fail to get data in the hands of sales and marketers to personalize messaging/outreach and build audiences around:

• Who has signed up for the product?

• What are their persona traits?

• What features have they used? How often?

• How many users have they invited?

• Have they reached the Aha! moment?

Without easily accessible, high-resolution usage data for go-to-market teams, PLG becomes merely a lead signup flow with potentially high volume but low conversion rates due to inadequate personalization. Fortunately, tools like Fivetran, Snowflake, and Census can deliver this data to go-to-market teams in a cost-effective, scalable manner that evolves with your business.

This article demonstrates how non-engineers can quickly and affordably set up these tools to send customer signups from the product to Salesforce, enabling a sales team. Additionally, it shows how to create a common PLG indicator, "number of users created per account," which requires SQL expertise. This indicator serves as a straightforward example of many other product signals that can be configured once the data stack is connected. This article is a high-level outline to show the strategy involved in connecting product data to a sales team. Each product has easy to follow documentation for all the technical steps of each connector but if you give it a try and feel like a technical walkthrough of setting up these systems would be helpful let me know and I can publish one.

Note: these products are just examples, there are alternatives to each but these all have free trials, low price monthly credit card plans with no contract and are easy to setup and highly scalable so I am comfortable recommending them for most use cases a startup or scaleup would have for years to come. In my experience, for startups that have their API keys/logins handy this can all be setup in as little as 2 hours but the first time through will likely be more like 6-12 hours. I don’t have a financial affiliation to any of these products other than that I use them myself and love the highly agile capabilities they offer my team.

Setup the Warehouse

Data warehouses are excellent at processing and distributing high quality data they are an absolute must for startups looking to scalably use behavioral customer data to drive business operations. To learn more about this check out my previous post on the topic!

The first step is to setup a warehouse to easily store data of any kind. As intimidating as this sounds it takes only 3 minutes on Snowflake and you’re ready to go. To run a daily batch sync of common product data for most startups under 10,000 customers will be under $150/mo in compute costs to get started and you can use a credit card with no large contract or sales process.

1. Create an account

That’s it… just create the account and a data warehouse is ready. It will only spend credits when a warehouse is actively processing a query and auto-suspend is enabled by default so no need to worry.

Load the Data

The next step is to load raw customer and usage data that the startup already has in it’s product database. ELT (short for extract, load, transform) providers like Fivetran and Airbyte make this incredibly easy with nearly zero maintenance.

They have prebuilt, no-code connectors to extract data from all common databases like PostgreSQL, MySQL, and SQL Server. They take only minutes to setup and flawlessly migrate and mirror data in the data warehouse.

1. Create an account

2. Connect to the Snowflake data destination

3. Connect to the product database source

4. Create a sync to send product data to Snowflake (at a minimum, select the users table for this example)

In addition to being able to load data directly from the product database they also have connectors to easily pull in data from hundreds of other systems like HubSpot, Salesforce, Iterable, Zendesk, Quickbooks or wherever else useful customer data lives. These and event streaming data will be topics in future posts on data activation!

Activate the Data

Sending Users to Salesforce

Now this is the fun part. Historically data was locked up inside the product database and the only way to get it in the hands of sales and marketers was through complex, hard to maintain custom integrations and webhooks that required engineers to build. But now that the data is in a modern warehouse it can be easily activated and sent and maintained in frontline systems that power the business by non-engineers.

Data activation providers (also known as reverse ETL since they extract data back out of the warehouse) like Census and Hightouch will connect directly to your data warehouse and handle the transfer of data to frontline systems like Salesforce, Google Ads, Iterable and Zendesk with no-code required. Just pick the fields from the product data in Snowflake and send it directly to Salesforce, in this case we’ll create or update new lead records with the data needed for sales to be successful.

1. Create an account

2. Connect the Snowflake data source

3. Connect the Salesforce data destination

4. Select the users table as a data model

5. Create a sync from the users table to the Salesforce lead (or contact) object and map the fields to send

This pipeline will automatically send all new users created in the product to Salesforce. No complex triggers in the product, no engineers, just field mapping.

Sending the Number of Users per Account to Salesforce

1. Create a new data model (SQL) to calculate the number of users per customer account (include the user email or id if that is stored in Salesforce)

2. Create a new field in Salesforce for number of users (on the contact, lead, or opportunity object the team uses)

3. Create a sync from the new data model to Salesforce with the owner email address as the identifier

4. Map the number of users metric to the new field in Salesforce

Done! The user count will now automatically update in Salesforce (or any other system you set up a sync for) moving forward. Now customers’ product behavior can be directly used to trigger alerts or actions directly n Salesforce. In the future we’ll dive into an even more powerful data activation strategy for PLG/PLS on how to instrument great streaming event data directly from the product.

As always, I'm eager to hear your thoughts and feedback on this topic!

Subscribe now

Working in data is no longer just about analytics, dashboards, and data science. Modern data teams are capable of being a critical driver of growth thanks to scalable data warehouses and force multipliers like dbt, Census and Hightouch. The data stored in a warehouse traditionally used for dashboarding and analyses can now directly enable business growth strategies some of which include:

• Product-Led Growth/Sales

• Customer Email/Lifecycle Personalization & Targeting

• First Party Marketing Attribution & Conversion Valuation Feedback

• Customer Blended Enrichment & Identity

• Product Growth & Experimentation

• Proprietary LLM/GPT Experiences

But these projects can only be achieved if a data team is willing to take some risks outside their zone of control to become the source of truth not just for analysis but also for operational data flows like customer profiles, behavioral/usage data and website interactions for the business. By upgrading their processes and successfully tackling high value data projects that drive growth, a data team can earn a voice at the leadership table and directly influence the company's strategy.

Having that influence is how data teams can work more closely with business systems to integrate definitions and produce higher quality data. Data teams are going to be asked to tie it all together whether it is integrated or not! So by taking on responsibilities historically not attributed to data teams they can become a core business partner to many teams/systems and influence how they are built and leveraged (if they’re the source of high quality inbound data they get to shape how it is stored and used!). Through this partnership (consistent) higher quality data is produced and collected from frontline systems to enable more data flywheels to be created and enable organizational learning. Starting early on this path may require more work from the data team initially, but it will ultimately lead to greater rewards as the company's central data hub shifts from a complicated network of data flows to the data warehouse

Some of data teams will think this isn’t their job but I disagree. The goal of working with data is to continually be improving the quality and depth of analysis and tooling. In order to continue growing quality analyses and data products, it is the job of the data team to support a data driven transformation across the company. That process starts with business leaders and systems that power the organization. Expecting these data sources to provide better data over time without exchanging something of value is highly unlikely in a business climate of high productivity & efficiency for all teams. To explain why we need to start with leadership, let’s take a look at my own spin on the data science hierarchy of needs.

When I first came across the data science hierarchy of needs framework I loved its simplicity. Unfortunately it was built with inward looking data team blinders on. Starting with data collection, instrumentation and logging is never the first conversation I’ve had with an organization beginning a data journey. Don’t get me wrong, I would love to start there!

However, the data science hierarchy of needs omits the important principle that data is collected from systems & processes that are designed by people to accomplish a goal. In my experience the goal has never accidentally included “building a data driven organization”. The data collected from an inconsistent, intermittently followed system is likely to do more harm than good. Inconsistent processes cannot be used for experimentation or machine learning and therefore prevent the data team from ever answering questions around why things happen, they will always be left in the realm of descriptive analytics around what is happening. So whether a successful data team wants to get involved with data feeding in and out of business systems is a foregone conclusion in my mind. If the data team has to be involved then I recommend being fully involved. This creates a trade where data practices are being followed by stakeholder systems in exchange for clean, enriched customer data flowing back to those systems from elsewhere in the business. Everyone benefits but someone has to be willing to take the first step and cut the Gordian Knot of systems and data teams have the best tooling today!

A data team’s ability to execute and deliver wins at an organization depends not only on their own internal capabilities but also on the quality of their data they receive from other teams. If leadership (company or department level) isn’t willing to partner on system improvements then it is the data team’s responsibility to drive that change by building a vision for increasing revenue or reducing costs through directly enabling the business with the data they have. There are numerous projects that can achieve these outcomes that we’ll dive into in future posts!

Extra Note: The maturity model likely won’t progress equally across the business. Each department must work their way up the steps in the model so the data team should look around and find the most data driven leaders to partner with on their goals first to pave the way. It’s entirely possible that one department may be fully leveraging prescriptive ML insights while another isn’t actively logging activities or events for descriptive reporting. If one or more departments are highly resistant to making data driven improvements then your time may be better spent focusing on those who are ready to work directly with data. Over time as the innovators bring better and better reports with metrics trending in the right direction to leadership meetings the laggards will get the memo 😉.

• Company A: Has a first party collected, central repository of cross joined data across all their services

• Company B: Relies on third party data collection and reporting through siloed apps

Company A will be able to wield custom tailored insights, recommendations, and warnings from the multitude of AI plugins, packages, and tooling available today. Company B will be left with siloed, third party reporting that misses out on the most important insights and can’t connect the data directly to AI platforms in a meaningful way. Luckily, becoming company A is easier and faster than ever for startups and growth stage companies today.

Data has become the next competitive frontier for every company whether they are aware of it or not. Over the past decade the data landscape has witnessed an explosion in strategies, tools, and techniques. Many growing companies view this space as the arena of larger, established companies who have large data teams filled with expensive data scientists. With the development of the modern data stack the capabilities historically reserved for the fortune 500 are within reach of any organization. It is now possible to have a data warehouse with data from the most critical billing, support, and CRM tools up and accessible to anyone who knows SQL in just a few hours.

Here are the pain points that indicate that a warehouse first data strategy will unlock the next level of growth by improving the customers’ experience and systems agility:

1. Spending a lot of time generating ARR/Revenue reports with low confidence that it captures an accurate view of the business that is a sign that the company has outgrown automatic reporting and need to start catering automated reports to actual business needs.

2. The company's CRM holds partial user data for some contacts and customers, and it is unable to track the user journey of anonymous users. This limitation can make it challenging to create accurate and insightful target audiences for communication purposes. Believing that a CRM can serve as a data warehouse is an illusion that can quickly become a hindrance to growth strategies due to space, cost, reporting, and compute restraints that can set the company back by several quarters. The reason for this is that CRM tools are not designed to handle or integrate with the vast amount of event stream data that modern companies generate, which is essential for building precise reports.

3. If the company is slow at or not able to answer questions using more than one data source including: CRM, product/app usage, advertising/marketing platforms, social media, finance, and accounting. Some of these questions include: Which product usage correlates with the highest LTV customers? What are the demographics of the company's most valuable customers? What product events precede churn or cancellation?

4. Only a few people in the company can answer questions about customers with data and the rest are relying on experience, intuition, or siloed third party apps. This leads to missed opportunities that hurt the bottom line through inaccurate marketing, sales, and customer experiences.

5. The team spends important hours formatting Google Sheets that are widely debated and questioned. Not only does this take up valuable time and resources, but it can also increase the risk of errors and inaccuracies in the reports. A data warehouse alleviates this burden by automating and streamlining the reporting process so fixes occur once and the source of truth is trusted and shared by everyone.

6. Reliance on Third Party Attribution: If the marketing spend is being directed by the reports that the advertising platforms themselves provide then the company is wasting valuable spend and marketing allocation without knowing which campaigns are driving the most top/bottom of the funnel impact. Ad platforms will all claim credit for the same users who pass through their systems so the company will be spending multiple times to acquire the same customers without knowing it.

7. If every meeting presents new conflicting data from the last one it is likely time to invest in centralizing the data and codifying metric definitions so the team can spend less time scrutinizing and more time building with confidence.

Modern data warehouses and a warehouse first strategy makes it quick to setup and maintain a central data repository to unlock advanced analytics and AI tooling rapidly. A proper data collection and processing strategy allows these tools scale infinitely with the company to stay informed, efficient, and confident in where the business stands.