Peter Guagenti says data teams should start with the business outcome and ask why before deciding how to build a system.
2
A startup needs technical people and go-to-market people who both take responsibility for making an idea real.
3
AI coding assistants can improve developer productivity, but teams still need code review, strong developers, and context from the organization's own systems.
Summary
Peter Guagenti discusses how technical teams and business stakeholders can work together on data products, machine learning, and AI tools. He argues that teams often start with data, algorithms, or implementation details before understanding the business outcome. His advice is to ask repeated why questions, inspect what data exists, and treat early requirements as changeable. He also explains why fast experiments matter, using Aquia Lift as an example of a product built in spare sprint time and tested with a major customer. Later, he describes Tabnine's vision for an AI coding assistant that can work across the software development lifecycle while preserving privacy and respecting licensing. He sees context and user experience becoming more important as models become widely available. For enterprise software, he says the buyer is a group of people with different concerns, so teams must create trust with users, champions, decision makers, and budget owners.
Entrepreneurs often succeed by making a rough idea tangible before the organization is ready
Peter Guagenti describes a recurring pattern in his work: a useful idea can remain blocked while people debate its difficulty, scope, or business case. At Aquia, he proposed Aquia Lift, a personalization and targeting product for media companies that used a multi-arm bandit algorithm. The CEO rejected the idea, and engineers worried about collecting the data needed to support it. Guagenti, an engineering manager, and a sales engineering leader used the company's fourth, open sprint to build a functioning MVP. After two sprints, they had something to show. They took it to NBC, used the customer's data and site in a prototype, and received concrete feedback. Guagenti says the product later became a major part of the company's revenue.
Business requirements should begin with the outcome rather than the implementation
Guagenti says data engineers, data scientists, and analysts often get too specific too quickly. They may begin with an algorithm, a data structure, or an existing reporting method without asking what the business is trying to achieve. He gives marketing as an example, where teams collect many customer interactions but can lose sight of the desired action, such as getting more people to buy or focusing on a category. His advice is to ask the five whys. Teams should ask what outcome the stakeholder wants, how the business would operate differently, and why each requirement matters. Business teams also have work to do. They should explain the outcome clearly and spend time understanding which data exists and what it can show.
Data becomes useful when teams connect it to decisions and actions
Guagenti separates raw data, insight, and action. He says data is not insight, and insight is not action. Business users may not know what they want until they inspect the data they already have. He encourages them to look through their data sets and ask what each source can reveal. At Tabnine, he worked with a data team that tracked product usage anonymously. Rather than arriving with a fixed growth request, he asked what the team tracked, why it tracked those things, and what the measurements showed. That conversation produced better questions and better requirements. He says company leaders should understand what data they collect, where it lives, and how it can inform decisions.
Moving quickly still requires a short period of alignment before building
When Demetrios Brinkmann asks how to reconcile rapid experimentation with careful questioning, Guagenti compares planning to pulling back a bow before firing. He says teams should follow a ready, aim, fire pattern, even when they are moving quickly. This does not require a perfect answer. It requires enough shared understanding to avoid spending energy on work that has no useful destination. Teams can start with a limited view, treat the requirements as provisional, and use the first implementation to learn. Guagenti is direct about the emotional cost. People often defend a bad direction because they have invested time in it. Engineering teams can become attached to their code, but code can be deleted when the evidence points elsewhere.
A product needs technical builders and go-to-market people with equal weight
Guagenti's theory of a successful technology startup has two types of people and two ways of thinking. He calls them hackers and hustlers. The hacker mindset applies to technical people who look for a way to make an idea real instead of listing every reason it cannot work. The hustler mindset applies to people who build demand, relationships, and revenue. Guagenti says the act of creating a business means generating something from nothing, so both sides need the willingness to work through uncertainty. He also warns that technical founders may understand formulas and systems while sales and marketing involve psychology and sociology. In his view, many technology companies win through their go-to-market work, even when another company has a stronger product.
Personalized context can matter more than a more capable general model
Guagenti describes Tabnine's AI coding assistant as part of a wider software development system. The assistant can work with an IDE, Jira, Confluence, Datadog, application performance tools, logs, and other sources. With that context, it could help write tests tied to actual outcomes or assist with deployment checks. He says the system still needs better context from the user and the workspace. A generic model may produce a poor answer because it does not know the developer, the codebase, the team's conventions, or the intended result. Tabnine's approach includes privacy controls, private deployments, zero data retention, and models trained without non-licensable data. Guagenti expects models to become more similar, which would make the surrounding data and user experience more important.
AI coding assistants speed up work without removing the need for engineering judgment
Guagenti responds to research about code generated by AI assistants later being rewritten. He says the finding does not make the assistant a replacement for a developer. A poor developer can produce poor code with or without an AI tool, and copied code from Stack Overflow already created this kind of problem. Engineering managers still need code review and must understand what their teams accept. Guagenti cites studies that put the average productivity gain from AI coding assistants at about 20 percent across writing code, writing tests, explaining code, evaluating code, and related tasks. He says teams can use that time to coach junior developers or improve staffing. He also wants assistants to learn from the practices of senior developers and recommend code that matches the team's standards.
Enterprise software is sold to a group whose members have different reasons to buy
Guagenti says large developer tools are rarely bought by developers alone. The sale involves a sphere of influence that can include an end-user champion, a decision maker, a budget owner, procurement, and the users who will live with the product. Developers may care about finishing their current work quickly. A CIO may care about productivity and efficiency. A principal engineer may care about technical fit and code quality. These people can support or block a purchase for different reasons. Guagenti's advice is to understand each person's concern and give each one a reason to support the product. Building trust with end users can create internal champions, while speaking only to one person's problem leaves the rest of the buying group resistant.
"You don't have one customer you have a champion who really wants this product in because they have a problem they're trying to solve."Peter Guagenti1:16:29
Who should watch
You build data products or machine learning systems and often receive vague requests from marketing, sales, product, or executive teams.
Your team is debating whether to spend more time clarifying a problem or to start an experiment, and you need a practical way to do both.
You sell or deploy AI tools inside an enterprise and need to understand the different concerns of users, champions, technical leaders, and budget owners.
