# How to define a product-qualified account > A useful product-qualified account model combines product behavior, account fit, user context, and a sales action that can genuinely help. - Author: Dan Stotts (Head of Marketing at Runpod) - Published: 2026-08-14 - Category: PLG-to-sales - Canonical: https://www.gtm-consulting.io/notes/product-qualified-account-model-for-infrastructure-companies/ --- The product-qualified lead was designed for a simpler idea: a user experiences value, reaches a meaningful threshold, and becomes more likely to buy. Infrastructure products complicate that model. One user can generate substantial activity without representing a commercial opportunity. A quiet account can be coordinating a serious evaluation across several people. Usage can reflect experimentation, production, abuse, education, or a workload that will never expand. That is why infrastructure companies usually need a product-qualified account, not just a product-qualified lead. ## What is a product-qualified account? A product-qualified account, or PQA, is an account whose product behavior and company context justify a specific commercial action. The definition has four parts: 1. **Product evidence:** The account has reached a meaningful state or pattern of use. 2. **Account fit:** The company has characteristics associated with the problem the product solves well. 3. **People context:** The users and roles suggest a path from technical value to an organizational decision. 4. **Useful next action:** Sales or success can do something that helps the account at this moment. Without the fourth part, a PQA is just an interesting row in a dashboard. ## Which product signals matter? The best signals describe progression, constraint, or organizational adoption. Examples may include: - A workload moving from an isolated test to recurring use. - Growth in projects, environments, seats, or team members. - Use of features associated with production readiness. - Repeated contact with a capacity, governance, security, or operational limit. - Activity across multiple users or functions inside the same account. - A pattern that resembles accounts that expanded successfully. Raw volume is rarely enough. High usage can be valuable, but it can also be one technical user's temporary workload. The model needs to interpret what the activity suggests about the account's next decision. ## How should account fit affect the score? Product evidence and account fit should remain visible as separate dimensions before they are combined. An account with strong usage and weak fit might deserve product-led nurturing, not sales attention. An ideal-fit account with little meaningful usage may need activation help, not a commercial conversation. Blending both into one score hides the reason an account qualified. Useful fit inputs can include: - Technical environment and deployment model. - Company stage and operating complexity. - Team composition and relevant hiring. - Regulatory, security, or procurement needs. - Geographic or support constraints. - The economic value of the workload the product supports. The model should also include negative fit. Disqualification protects the customer experience and gives sales permission not to chase activity that cannot become a good account. ## Should every PQA go to sales? No. Qualification should route an account to the right action, not automatically create a sales task. Possible routes include: - A helpful lifecycle message tied to the behavior. - Technical guidance from developer relations or success. - An invitation to discuss architecture, capacity, security, or procurement. - Account research before any outreach. - No action until another signal appears. The route should reflect what the account is likely trying to accomplish. A user approaching a production constraint may welcome help. A user completing a first tutorial probably does not need a sequence from an account executive. ## How do you build the first PQA model? Start with evidence the company already has. Compare accounts that expanded, converted, stalled, and churned. Look for patterns in product state, company fit, team activity, timing, and the intervention that occurred. Interview the people who handled those accounts. They often know which signals are useful but have never expressed them as a shared model. Build the first version with a small number of observable rules. For each rule, record: - Why it may indicate value or intent. - Which accounts it should include and exclude. - What action it triggers. - Who owns the action. - What outcome would validate or reject the rule. Do not begin with machine learning because the data is available. Begin with a hypothesis the company can explain and test. ## Which metrics show whether a PQA model works? Measure the quality of the decisions the model creates. Useful measures include: - The share of qualified accounts that receive the intended action. - Time from qualifying behavior to a relevant response. - Meeting, opportunity, and expansion rates by qualification reason. - False positives identified by sales, product, or success. - Product engagement after outreach compared with similar accounts that were not contacted. - Revenue or retention outcomes by PQA cohort. Do not optimize only for the number of PQAs or meetings. A model can create more tasks while making the customer experience and pipeline quality worse. ## Who should own the PQA definition? No single function can define it well alone. Product understands behavior and value realization. Data or operations understands the instrumentation. Marketing understands lifecycle and account context. Sales and success understand which interventions are useful and which signals waste time. One person should own the model as an operating artifact, but the company must agree on its meaning. The definition should be reviewed as product behavior, customer mix, and the commercial motion change. A PQA is useful when it turns product evidence into a better customer decision. If it only turns usage into another lead queue, the model has missed the point.