How to develop product operations processes

Product thinking is about focusing on solving user problems. Product operations — or product ops — enables large organizations to scale product thinking.

Two coworkers, an Asian woman and a Black woman, take notes while sitting at a computer in an office.

Everyone on a service delivery team should be a product thinker — even if their title isn’t product manager. Product thinking is about focusing on solving user problems. It ensures that you and your team are building the right thing at the right time to best serve your users.

Product operations (product ops) enables large organizations to scale product thinking. The three key components of product ops are: processes, tools, and data and experimentation. In this toolkit, we'll focus on processes.

Product ops is:

An operational function that grows high-performing product teams within organizations. Product teams strategically drive the research, development, market launch, and continual improvement of a service or product.

Or, as Blake Samic, Head of Product Operations at Stripe put it, product ops is about “building the connective tissue between the teams building your technology and the teams who interact with your users.”

Product ops processes can help:

  • Scale user-centered approaches and product thinking across your organization.
  • Foster collaboration, alignment and transparency between engineering, design, product management, business, and your users.
  • Ensure that you and your team are building the right things at the right time.
  • Provide the best possible value and experience to your users. Optimize for rapid iteration and continuous improvement of services.

The following templates can be used to build repeatable, scalable processes that enable high-performing product teams in any organization.

Start with a product brief

Starting the development of every product, feature, or service with a product brief ensures you’re consistently and efficiently focusing on solving user problems.

📄 Template: Product Brief

A product brief is: a high-level document that describes the vision and plan for a product, feature, or service you’re developing. It explains why you’re building it and documents why you did what you did.

It’s useful because: it provides shared context, objectives, data, and well-defined needs, so that product teams can discuss and make informed decisions about what exactly to build and how to deliver it.

Document your product development cycle

Documenting your entire process in a product development cycle helps keep multiple teams within large organizations on the same page.

📄 Template: Product Development Cycle

The product development cycle is: a living document or diagram that describes the end-to-end process by which a feature, product, or service is developed and delivered to users. It covers the sequence of activities a team completes to plan, develop, and evaluate a product. Activities may include research, design, engineering, quality assurance, marketing, customer support, and more.

It’s useful because: documenting the entire process increases understanding and efficiency across teams by articulating expectations and dependencies. This is especially important and useful in large organizations, with multiple product teams and/or other business teams, (e.g. policy analysis, customer support) who all rely on one another. It also helps with alignment on important questions like:

  • What key decisions are made—and at what step in the process?

  • Which team members and stakeholders should be involved at each step?

The product development lifecycle can vary project to project. The above template is high-level, a great starting point for any project. That said, it’s important to tailor the template to best fit your organizational needs and resources. For example, some of our government partners prefer that we operate using the Scaled Agile Framework (SAFe), which is a standardized set of organization and workflow patterns for lean-agile practices.

Here are some additional resources that may be helpful in defining and iterating on your product development lifecycle:

Use a RACI

Using a centralized, shared framework like a product team RACI chart improves collaboration and accountability by giving teams a shared understanding of each person’s role.

📄 Template: Product Team RACI

A RACI chart is: a shared document that itemizes product- and delivery-related tasks and identifies who is responsible, accountable, consulted, and informed for each one.

It’s useful because: it improves collaboration and ensures that key tasks don't fall through the cracks by creating a shared protocol among your team members about roles and responsibilities.

Your team may not have a dedicated scrum master, product manager and/or project manager. Or your team may have members who haven't worked with these roles before. Even if you have some of these roles on your team, you may find that many activities don't map neatly to them. Developing a shared understanding of roles and responsibilities across the team makes everyone more efficient and effective. This becomes critically important as your organization or program grows.

Get in touch

If you use this guide, we’d love to hear from you. To share questions or feedback, email us at

Special thank you to Loren Yu and Jodi Leo, who created the original Product Brief and Product Development Cycle templates, and to Dan Langrill, Diana Griffin, and Jess Alves de Sa for their valuable feedback on this toolkit.

Written by

Ivana Ng

Vice President of Product

Ivana Ng is the Vice President of Product at Nava. Previously, Ivana worked as a product manager.

Partner with us

Let’s talk about what we can build together.