New Product Introduction (NPI) Process
Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership
Context
Launching a product or service at GitLab involves coordination across a wide range of teams. Launching products smoothly is a critical part of delivering value to the customer, ensuring a positive customer experience, and positioning us to meet our financial targets. Our ability to efficiently manage the New Product Introduction (NPI) process will become increasingly important as we bring new products to market more frequently. To ensure that we launch new product offerings, service offerings, or SKUs effectively; we require a set of steps that happen in phases.
To launch features into our existing product set and tiers, use this process instead. This process often interlocks with the Go-to-Market Field Enablement function which supports launching and ensuring adoption of new products and services within our sales field team and ultimately with our customers. Learn more about this process on the GTM Enablement page.
Summary of phases
- NPI planning: teams & a Steering Committee (SteerCo) define scope and requirements; agree on prioritization of NPI project against other priorities
- Project Execution and Launch: teams work based on their own plans, with close coordination on decisions and steps that impact others
- Feedback: contributing teams retro and evaluate how the NPI process could be improved in future iterations
Criteria for using this process
What makes a product, service, or SKU appropriate for the NPI process?
- It constitutes a new product or service (i.e. it is not just functionality that cleanly slots into existing product tiers or existing SKUs)
- It is as operationally complex as a new product, service, or SKU; even if not new. (e.g. new packaging, business model, or SKU that requires custom systems configuration or revenue treatment)
- It represents a significant enough financial or strategic opportunity to warrant investment of dozens of teams’ effort
- The process may also be applicable if a product, service, or SKU is associated with a significant external announcement or event and we want to ensure operational excellence
How do we determine whether it’s ready to start the NPI process?
In order to launch the NPI process, the DRI must communicate:
- What we’re launching: product features & functionality, service entitlements, or something else
- Why we’re launching: value proposition, strategic value, and scale of financial opportunity (understand that finance will not have built detailed models, but some financial justification must exist)
- Who we’re targeting: Ideal Customer Profile (ICP) and target market
- When we need to launch: any internal (e.g. Field blackout periods, month/quarter/year end financial close, quiet periods, etc.) or external factors that create timing requirements
- That we’re able to launch: product development is sufficiently far along that it makes sense to start the process, and GTM teams have sufficient bandwidth to do the work in the required timeframe
What happens if a product or service doesn’t meet the criteria?
Possible routes:
- The SteerCo needs more information → sends the proposal back to the DRI
- The SteerCo agrees the product/service is suitable, but teams do not have capacity → problem-solve with DRI & E-Group (prioritize & sequence launches, reallocate resources and/or adjust launch scope)
- The SteerCo doesn’t think the product/service is suitable for the NPI process → discuss with DRI & E-Group
A Note on NPI Process Updates
We are actively iterating on the NPI process. You can use the #npi-process-working-group Slack channel to follow along about the work as well as to share any feedback you may have. Since this is an active change to ongoing processes, we’ve left the original process instructions at the bottom of this page. This section will be removed once the revised NPI process is finalized.
Phase 1: NPI Planning
This phase happens before the NPI process officially launches with cross-functional stakeholders.
Step 1: Write up the details of the product or service
The DRI should create a business plan based on an NPI Planning Info Sheet (template not finalized, to be linked once done) to communicate how you’ve defined the specific product or service that is being launched. At this point in the project you may not have all the details - use this resource as a starting point to help you and your stakeholders understand what still needs to be resolved cross-functionally over the course of the project.
Ideally at this point you will already know the pricing structure, but if not, a conversation with the Pricing Committee is needed:
- Contact Justin Farris’s EBA to schedule time with the Pricing Committee (currently Sean Hall and Justin Farris)
- Pricing will review the product or services brief and follow up within a week for any clarifying questions, and suggest the right level of research needed to arrive at a recommendation.
- Pricing team will conduct required research following our process, and pricing principles. Depending on the complexity of the offer, and potential market size this research could take a couple of weeks, up to a few months to complete.
- Pricing team will make a recommendation of what business model the product/service should have (e.g. fixed fee, subscription, consumptive, add-on, new tier), and recommend a price point or range to consider for the offering
Step 2: Meet with the NPI SteerCo and get alignment on the launch plan
The DRI/Business Sponsor and the Program Manager meet with the NPI SteerCo and present the information included in the NPI Planning Info Sheet.
The NPI SteerCo will advise on whether there are available resources to complete the NPI process for your proposed feature or service. In some cases, there may not be sufficient resources to match the prioritization level of a given project. In that case, it is important for the Business Sponsor and the NPI SteerCo to work together to escalate to the E-Group for further direction.
To meet with the SteerCo, reach out to Natalie Pinto or Lee Work who will add you to the next meeting.
Step 3: Assign a DRI and Program Manager to launch the product/service or SKU
Once approved by the NPI SteerCO, the project should have both a DRI and a Program Manager. The DRI drives the feature or service strategy and is the primary business owner. This is the person requesting a new product, service, or SKU. The person is responsible for delivering the initial business plan, and ensuring that the launch meets business goals.
The Program Manager coordinates and directs the multiple parallel work streams required by the NPI process. The Program Manager can be assigned from the Product division, or if necessary from the Office of the CEO. The Professional Services team can Program Manage SKU additions or modifications for Professional Services. In some cases, the DRI and the Program Manager may be the same person.
Step 4: Communicate the plan to stakeholders
Once the NPI SteerCo has given your project the go-ahead, it’s time to get the rest of the stakeholders aligned. Reminder: there are many steps required to deliver a net new SKU; this isn’t a process for processes-sake. We’ve learned through multiple NPI projects that this kind of work can’t be completed efficiently without clear communication and transparency in the process (NPI’s might be limited access in which case, details would not be open to all team members only those that need-to-know).
The Program Manager should begin coordinating efforts and identifying the relevant stakeholders across the organization. We recommend hosting the following meetings as soon as possible in order to kickoff the project:
- Stakeholder kickoff (process-focused): Meeting with all NPI stakeholders to launch the process: share overview of timeline, milestones, what success looks like, expected challenges.
- Product review (product-focused): Product Manager to present overview to all stakeholder teams. This is a deeper dive than stakeholder kickoff, and more focused on the product. GTM teams use this information for additional due diligence & clarity, and as an input to start developing their own strategies and roadmaps. (e.g. Deal Desk may have questions around usage boundaries, approval processes for non-standard steps, etc.)
These meetings are a chance for the various stakeholders and Subject Matter Experts (SMEs) in the organization to raise risks/issues sooner rather than later. The SME may ask questions that you can’t answer yet; that’s an opportunity for further discussion later in the project. For stakeholders this is a chance to understand what will be expected of them in the coming weeks/months.
We acknowledge that synchronous meetings aren’t GitLab’s ideal way of working, however in cases of complex cross-functional projects it can be challenging to make decisions and keep teams aligned without synchronous check-points. Our suggestion is to approach these meetings as “advised, but optional.” The project leads can use their own judgement to decide if a given meeting is necessary for their project and whether it can be optional for some members of the larger team.
Step 5: Organize logistics
The Program Manager should ensure that the team is set up for success. The following resources are valuable, but not mandatory. We recommend creating a Single Source of Truth (SSOT) with a link out to the following resources/information:
- Project epic (or group/project, whatever makes sense for your project)
- Slack channels
- Recurring meetings (on whatever cadence makes sense for your project)
- Plan for recurring async updates
- Define project milestones/timeline
- Project planner
Phase 2: Project Execution and Launch
This phase of the NPI project is generally handled by the stakeholder teams. They are subject matter experts in their own tasks / needs and can be trusted to manage their work accordingly. These stakeholders will create the relevant artifacts necessary for their function. For example: GTM plans, marketing message and vision, partner plans, enablement materials, sales projections, gross margin projections including hosting/infrastructure costs, support/PS costs, etc.
The Program Manager and DRI should be continually working with teams to ensure that work is on track against the defined timeline. The Program Manager should also partner with teams to facilitate decision making and problem solving where needed. NPI projects can be highly complex and the teams will need to discuss challenges regularly.
An important note: occasionally the team may encounter decisions that dramatically change the parameters of the project. In this case, we ask that the Program Manager and DRI realistically approach the long-term plan. If the stakeholders say they cannot complete the project on time given the changes, then the plan needs to be adjusted.
In the future this section will include detailed project plan templates for teams to use and collaborate on together - this will be more action focused for the broader team.
Phase 3: Feedback
Once the new feature or service has launched, the Business Owner and Program Manager should organize a retrospective. This will inform future NPI projects so we can continue to iterate and improve.
Teams should also follow up post-launch with input on customer perspective/feedback, as needed.
Click here to expand and see the earlier version of this process.
Context
Launching features into our current product set is a well understood process. To launch new product offerings, service offerings or SKUs requires a set of steps that need to be sequenced in a way to ensure product launch is done efficiently and effectively.
Summary of the steps.
- Business Sponsor and a program manager should be assigned to launch the product/service or SKU.
- The product or service needs to be clearly defined
- Pricing research / pricing and packaging plan should be created
- An operations / business plan / financial projection should be developed for the product / service
- Approvals should be obtained to move forward with the launch
- Product Launch checklist should be created with clear DRIs assigned
- Execution against Product Launch checklist should happen
Step 1) Business Sponsor / program manager should be assigned to launch the product/service or SKU.
A Business Sponsor should request a new product, service, or SKU. The business sponsor can be the DRI to drive the SKU launch if it is smaller in scope. If the scope is larger, a program manager will be assigned to execute, and launch the product, service or SKU. A program manager can be assigned from the Product division, or if necessary from the Office of the CEO. SKU additions or modifications for professional services can be program managed by the Professional services team.
To initiate the work (and proceed to steps 2 to 7) provide a three sentence proposal to the Pricing Steering Committee to kick off steps 2 to 4. The committee meets monthly and will review and provide any necessary feedback, and ensure the team is aligned on supporting the follow up work.
Step 2) The product or service needs to be clearly defined
A services brief should be drafted. This should include:
- Details of the service offering (e.g. 24x7 support, emergency support SLAs, PS SOW description, etc)
- Description of the market and ideal customer
- What the customer gets in terms of entitlement
- What is required of GitLab to deliver the service
- Hypotheses of how the product will be priced (e.g. Hourly, fixed fee, subscription)
A product brief: (use this template)
- Description of the product.
- Description of the market and ideal customer
- What features are available today that will be part of the product.
- What features will be part of the offering
- If the product will be included as part of our primary tiers or as an add-on
- Hypotheses of how the product will be priced (e.g. new tier, add-on, consumption)
Step 3) Pricing research / pricing and packaging plan should be created
- Pricing will review the product or services brief and follow up within a week for any clarifying questions and suggest the right level of research needed to arrive at a recommendation.
- Pricing team will conduct required research following our process, and pricing principles. Depending on the complexity of the offer, and potential market size this research could take a couple of weeks, up to a few months to complete.
- Pricing team will make a recommendation of what business model the product/service should have (e.g. fixed fee, subscription, consumptive, add-on, new tier), and a recommended price point or range to consider for the offering
Step 4) A Operations/ business plan / financial projection should be developed for the product / service
For a new product or service we should build an operational business plan (this this template). This includes
- Product plan
- Marketing message and vision
- Ideal customer profile
- GTM Plan
- Partner Plan
- If necessary a infrastructure cost/operating model for the offering
For a new services offering we should also include a:
- Staffing Plan
- Operational Model
- Systems changes required to support the new service
Build a financial model
- Topline sales projections
- Gross Margin projections including hosting/infrastructure costs, support costs, professional services costs, etc
- Possibly model contribution including other costs such as Sales and Marketing or R&D.
- Any financial asks needed to support the product (e.g. support staffing)
Step 5) Approvals should be obtained to move forward with the launch
With the product/services proposal, pricing research, operational plan and business plan in place, the leadership can make a decision to move forward. This approval with the correct structure will accelerate the next phase which is planning and execution. Approvals will follow this matrix.
Once the approval is made the following teams need to be notified that a workstream is kicked off:
- Product offering: Product owners and engineers
- Services offering: Professional services or support team
- All offerings: Product Marketing, Legal, Product Fulfillment, IT, Data, FP&A, Billing, Revenue accounting, Tax
Step 6) Product Launch checklist should be created with clear DRIs assigned
- Example Template is here.
- The program manager should fill out the product launch checklist and ensure there are owners for the generic items but also adds custom items.
The following areas may need to be considered in the planning:
- Marketing Plan including positioning, press, customer references, etc
- Product Plan including Beta programs, code complete, launch criteria, data logging, etc
- Sales readiness including GTM plan and enablement of field and channel
- Pricing and Packaging
- Legal readiness including terms of service, data retention, privacy or product counsel issues
- Customer Support / Success readiness
- Product fulfillment including licensing, upgrade, downgrade, trial
- Billing including preparation to sell on all sales channels (sales assisted, web direct, channel)
- SKU creation including Zuora Billing, Zuora Revenue, CustomerDot, SFDC, Netsuite readiness
- Revenue readiness including SSP impact and rev rec rules
- Tax readiness
- Data including operational metrics, impact to reporting, data warehouse ready
- If cross functional data pulls/analysis will be required, please identify Data DRIs that can help. As an example, please see what was done for the Storage Limits Initiative
- Metrics and comp including impact to NetARR and compensation
- Finance including financial forecast
- Investor Relations including investor messaging
Step 7) Execution against Product Launch checklist should happen
Execute against the plan created above some resources that are helpful are:
eed8e1db)
