A Six-Step Playbook for Building a Product Growth Team

7shifts’ product growth team used five backlog practices, including 15-minute wireframes, to run fast tests without making A/B tests the default. Marcus Bennett spent six years as a service and product manager there, helping its lifecycle team test existing products and take new ideas to market.

More than 350,000 restaurants worldwide trust 7shifts, including Five Guys and Bareburger. Its scheduling and management services simplify restaurant labor, giving the team a concrete operating context.

What does a product growth team do?

A product growth team prioritizes experiments that increase top-line revenue, or total revenue, and aims to automate revenue generation across the customer lifecycle. At 7shifts, the “lifecycle team” monitored customers, combined product and customer knowledge, and connected departments to find gaps. It covered technology, customer experience design, market expansion and existing-product improvement.

Product-led and sales-led companies can use the model. Lead qualification matters in a product-led business. Sales-led firms can still form the team, but focus less on customer value and more on business value.

How do you secure support?

Six steps establish the case:

1. Build a story. Set goals, activities, benefits, agenda, participants and revenue metrics before recruiting supporters.
2. Build a coalition. Recruit people in the department with direct revenue targets to champion the team.
3. Start at the top. Approach the CEO, COO or founder in a small company, or a senior executive in a larger one. Work with one sponsor to build a shared mindset and reduce resistance.

Bennett said: “Most executives, no matter where you are, speak two languages. Data and money.” At 7shifts, raw data from the initial sign-up flow exposed a revenue opportunity. Translate evidence into expected impact on monthly recurring revenue, or MRR, and customer efficiency.

1. Bring in sales and marketing. Dispel myths that the team will replace them or become a closed executive unit. It should amplify their work, bridge departmental gaps and supply insights, data and tools for customer reach.
2. Secure product and engineering support. Where those functions exist, tie buy-in to growth milestones. Startup funding milestones can support extra developers and more scalable, stable code.
3. Prove value. Find, analyze and evidence lifecycle opportunities. This takes time, and teams can begin before the formal group exists.

How should the team prioritize and learn?

Three practices turn the model into work:

• Guiding principles. Align decisions and value. One principle may be reducing time to value, the time needed to deliver customer outcomes.
• Prioritization. Find the lifecycle stage with the greatest benefit and revenue impact, then publish priorities and first actions. 7shifts focused on activation, meaning customers begin using the product. Balance data with company goals through cascading OKRs, or objectives and key results.
• Backlog management. Own experiments across new-product acquisition, process development and growth. Gather ideas from every team, where hundreds may emerge, then make a promising experiment a provisional priority.

Five tasks keep the backlog usable:

• Score and theme. Rank items on a simple scale, then group them.
• Frame hypotheses. State what you will learn, not the chosen solution, so stakeholders see tests rather than finished proposals.
• Design quickly. Use rough wireframes; 7shifts allowed about 15 minutes per hypothesis.
• Show reasoning. Explain why items move up or down and keep contributors engaged.
• Standardize. Record priority, hypothesis, design, rationale and action steps so teams can scan and act.

7shifts also used a test backlog framework and management matrix. Its team ran uncontrolled tests, smoke tests and other quick methods because A/B tests, which compare two versions, took too long. It measured hypotheses instead of forcing every question into the slowest format.

Which skills does the team need?

The structure needs five skill groups, each covered by at least one person. Bennett’s warning is blunt: “It’s not about people.” He says full coverage gives the team a high likelihood of success.

• Driver: Leads with data and product-management experience; sets cadence, prioritizes, decides and documents work.
• Marketer: Combines product marketing with branding, copywriting, messaging, web design and social media.
• Code writers: Ideally two to three developers, focused where customers pay. Put two on a mobile app that drives more sales and keep another on web and lifecycle work. Prefer broad, fast builders willing to discard work over scale architects.
• Designers: Apply customer experience (CX) and user experience (UX) to friction, customer expectations and functional experiences throughout the lifecycle.
• Statistician: Interprets data, validates hypotheses and provides strong A/B-test and SQL analysis, meaning database queries used to test product performance. Retain this capability; Bennett calls the statistician invaluable.

One person can cover several groups; larger groups need more than one.

What keeps the model working?

Six practices govern the pace:

• Time: Buy-in and process change require consistency and perseverance.
• Alignment: Keep priorities and metrics consistent, and define success for everyone.
• Experiment velocity: Repeated fast tests are the best leading indicator.
• Learning from failure: Many backlog experiments will not work first, so preserve what each failure teaches.
• Small starts: Iterate quickly before scaling rather than trying to make a large team right immediately.
• Experimentation mindset: Give all product teams tools, training and strategies, then require communication and collaboration.

Scaling will fail if the organization skips alignment, starts too large, or treats failed experiments as evidence against experimentation rather than inputs for the next cycle. The direction for product practice is smaller, lifecycle-based experiment cycles, supported by shared metrics and visible learning from failure. Start with one priority, one hypothesis and one review cadence.