The Great Divide
In most tech companies, a subtle but powerful divide exists. There are the "builders," the engineers who write the code, and then there is everyone else. The product organization, for all its strategic importance, often operates on the other side of this divide. We write specs, create mockups, and analyze data, but we are fundamentally dependent on engineering for the tools, access, and data we need to do our jobs.
This dependency is a source of constant friction. It manifests as a product manager waiting weeks for a new analytics dashboard, a designer unable to query production data to validate a hypothesis, or a product marketer begging for engineering time to build a simple internal tool. This model creates a bottleneck that slows down the entire product development lifecycle.
In an AI-native world, this dependency is no longer just a source of friction; it is a strategic liability. The new generation of code-assisted AI tools is erasing the line between builder and user, and it's time for the structure of our product teams to catch up.
The New Mandate: Everyone is a Builder
The thesis is simple but profound: onboard every member of the product organization as if they are an engineer. This does not mean everyone needs to become a senior software developer. It means that the expectation is now that you will leverage code-assisted tools to directly access data, automate tasks, and solve your own problems.
We recently put this into practice. A new product manager joined our team. Traditionally, their first week would be a marathon of getting access to a dozen different SaaS tools, learning the intricacies of our analytics dashboards, and scheduling meetings with engineers to understand the data schema.
Instead, we set them up with a Github account, cloned our repository, and gave them access to Cursor.
Within their first week, without writing a single line of production code, they were able to use AI to:
- Write complex SQL queries to analyze user retention for a feature they were researching.
- Build a small script to pull a list of users who had requested a specific integration.
- Identify a gap in our API documentation that was causing confusion for a new partner.
At most companies, each of these tasks would have resulted in a ticket in the engineering backlog. Here, they were accomplished in minutes, not weeks. The PM was not a requester; they were a builder, empowered to find their own answers.
Your APIs Are Your Internal Tools
This approach forces a critical shift in thinking. The best internal tools you have are your own APIs. By providing safe, well-documented API endpoints and empowering the entire team with AI assistants that can interact with them, you eliminate the need for a sprawling, disconnected suite of third-party tools.
Instead of building a one-off Retool app for the marketing team, you give them the tools to query the marketing API themselves. Instead of waiting for an engineer to build a custom dashboard, you empower the product manager to use AI to generate the data visualizations they need on the fly.
This triggers a common and valid concern: what about security and safety? Giving more people access to the codebase can feel risky. This is where the product leader's job is crucial. Our responsibility is to provide safe, powerful tools. This means enforcing access through a well-designed API layer with clear permissions, not allowing direct database writes. The goal is not to unleash chaos, but to provide a secure and sandboxed environment where the entire team can build.
Builders, Not Ticket Writers
The useful distinction is no longer technical versus non-technical. It is between people who can move a problem forward themselves and people who can only describe work for somebody else to do.
AI gives more roles access to code, data, and prototypes, but access is not the outcome. The outcome is a shorter distance between noticing a problem and testing a solution. Product teams should be organized around that ownership, not around who was historically allowed to build.