How to write standard operating procedures (SOPs) with template

A product manager has to navigate multiple scenarios from discovery to delivery. There are a lot of internal and external stakeholders involved across business, engineering, design, marketing, growth, finance, legal, you name it! As most PMs know, it’s hard to align stakeholders, especially when each one is working in an entirely different field within a company.

But how can one navigate through all of these different areas? And how can one make this navigation their own? One way is through SOPs.

In this article, we will explore the fundamental principles of standard operating procedures (SOPs) and how they serve as a valuable tool for product managers to navigate the stakeholder landscape and ensure effective collaboration.

What is a standard operating procedure?

A standard operating procedure, in essence, is a standardized process that everyone in the organization adheres to. Commonly, an SOP then becomes a dynamic reference document that summarizes these standardized processes. SOPs help foster collaboration and, if done correctly, ultimately help teams achieve common goals.

In the world of product management, an SOP is used as a reference doc to make sure business value gets translated into product requirements, thereby creating value for users by solving their problems.

It’s important to remember that an SOP should not be seen as a rigid, unchanging policy document; it should be agile and open to updates as circumstances evolve.

Why do I need an SOP?

Why are SOPs necessary? Well, the short answer to that is to help PMs derive the signal from the noise. There are essentially three types of noises:

1. Noise of ideas — PMs are constantly exposed to their own ideas during discovery. Not only that, PMs are also exposed to the ideas of stakeholders, both near and far from their product’s immediate impact circle
2. Noise of priorities — PMs have to deal with dynamic business priorities and choose between velocity, quality, and impact of their work
3. Noise of perception — This is a necessary evil garbed in the form of marketing the work the team is doing, thus attracting more investments

How do you write standard operating procedures?

The foundation of a well-crafted SOP lies in asking insightful questions, as this process kickstarts the development of a comprehensive document. This shared document is not an isolated entity; it is a result of co-articulating questions and solutions collaboratively among stakeholders.

Further, it’s essential to emphasize that an SOP should be tailored to fit the specific needs of your product and business, rather than attempting to adapt your operations to a predefined format. When articulating SOPs, it is also crucial to consider the diverse audiences they serve, as different stakeholders may require varying levels of detail and communication.

To find an answer to the “how” of creating SOPs, I have framed three main steps and a template for you to work with:

1. Ask good questions
2. Co-document the answers
3. Frame the SOP

1. Ask good questions

Start by asking a lot of questions. Whether it’s your first PM job, a new team or project in an old job, or just your everyday, regular PM work, always ask questions!

The following questions are key to initiating the process of creating an SOP. These work for not only the PM but also for the stakeholders around them. I divided them into three parts:

• Product
  • What is my product area?
  • What are the OKRs for my product area?
  • How does this product area impact the organization’s OKR?
  • Is this a legacy product area or a new product area?
  • If this is a legacy product area, what is the tribal knowledge?
  • If this is a new product area, what is the vision and mission?
• People
  • What is the organizational structure of my product area?
  • Who are the primary stakeholders for my product area?
  • Who are the secondary stakeholders for my product area?
  • Who are the other mandatory stakeholders for my product area (legal, tax, etc.)?
  • What is the escalation hierarchy and process within my product area across primary and secondary stakeholders?
  • Is there a RACI or similar role designation within my product area?
• Process
  • What is the existing product development lifecycle in the organization?
  • How do we do discovery?
  • How do we run research?
  • How do we brainstorm ideas?
  • How do we run tests on those ideas?
  • How to instrument the tests?
  • How do we set up dashboards?
  • How do we run QA?
  • How do we launch?
  • How do we communicate impact?
  • How do we gather feedback from clients/customers/internal stakeholders?
  • What are the existing internal comms and GTM structures?

The above list of questions is a great place to address all three types of noises we talked about. There could be answers to questions that PMs already know about, as well as answers that the PMs don’t know right away but other stakeholders might be able to call out during discussions.

On top of this, there could be questions that no one thought at the time but eventually became critical — hence, they should be added to the SOP as a live document. Don’t forget to get creative and add more to this list as you deem fit!

2. Co-document the answers

There’s a key reason to call out why I say “co-document.” A PM’s job is to rally the team towards a common product goal with a well-crafted path from discovery to delivery. While you’ve started asking these questions from step 1, don’t forget to:

1. Map your stakeholders across teams so everyone knows the primary, secondary, and mandatory stakeholders of your product area
2. Involve stakeholders in your documentation process by letting their expertise shine in the document

Make sure you work with a timeline in mind. No document is perfect or absolute, and it is easy to fall into the trap of taking too long to arrive at a “good enough” version. Focus on progress over perfection.

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

3. Frame the SOP

This is the final stage of articulating what you learned from steps 1 and 2. There are different SOP formats, but it’s important to make the document fit your requirements and not the other way around.

Here is a free template for you to start with, you can click File > Make a copy to save and customize it as you see fit:

Different standard operating procedure formats

In general, there are different types of SOP formats that you can adopt based on your unique requirements.

The FAQ SOP

A simple question-and-answer-based SOP will help stakeholders read through different scenarios and tell them what to do as they occur. You can pick or re-frame questions from step 1 and put the agreed-upon answers in a product-people-process format.

Let’s go through an example to make this template more palatable. Imagine you are working on a B2C product feature where you need to add a trust signal during the check-out process.

Let’s say, the primary audience for this FAQ SOP is your customer service team. Most of your FAQs in this section will be from the process subsection under step 1. For example;

• What happens when the user clicks an ad on the checkout page, which works, but then they lose the transaction user flow?
  • Ask the user to:
    • Check the notification center where they’ll be prompted with a pending transaction
    • Look at the cart icon at the bottom of the screen where their selected order is kept on hold for 10 minutes. They can complete the transaction before it times out and the items are removed from their cart

The checklist SOP

This is like a checklist for the things that have to be done across various scenarios. The sequence is extremely important in this section. For example, if the audience is your core product team including devs, technical program managers, analysts, and other relevant stakeholders:

Steps the team will follow before releasing a feature:

• Check with other PMs to see if they are running any experiments on the surface you plan to release your feature, i.e., clarify dependencies, if any
• Clarify if your feature is an experiment or a global release
• Give visibility into the primary and secondary metrics you will evaluate for this release
• Clarify the date and runtime for your release, if it’s an experiment
• Share the roll-back plan for situations where the feature might break

The flowchart SOP

This flowchart SOP is relevant in scenarios that have a lot of moving parts across the decision tree. Make sure you have a clear goal for using this SOP type. For example, where the audience in this example is the program management team:

Remember, for each of these above SOP formats, you can customize the template that benefits you. Do not let the template take over your process — these template options are for your guidance only!

I’ll strongly encourage PMs to make it a mix of different formats they think their audience can easily consume. The SOP may also change based on the audience you are aiming for.

For instance, if you are creating an SOP for your customer service team, you’ll likely need to word and structure it very differently than one for your engineering audience. A customer service team may want an SOP in the form of question and answer, whereas the engineering team may want details about how to standardize story points for each ticket and how will the team calculate velocity or feature impact.

As a PM, it is your job to either find a common SOP format that works for all — which is difficult to achieve, unless you want to make a very long document that lacks brevity — or create a few different versions targeting the different audiences.

Conclusions and key takeaways

To summarize a few key takeaways,

• Asking good questions is a great start to drafting a good SOP
• SOPs can help PMs navigate the complex stakeholder landscape
• SOPs are a by-product of co-articulating both questions and solutions. An SOP is a shared document across stakeholders and should not be made in isolation
• PMs need to customize SOP formats to fit their own product and business requirements, not the other way round
• SOP articulation may differ based on the audience it is trying to cater to

And finally, remember that an SOP is not a policy document or a mandate that you can’t change when it is required. Don’t get fixated on a process you believed would work but later realize it’s not working anymore. Be agile and ready to make updates and changes to the SOP when the team needs it.

An SOP is just another reference document to make your and the stakeholder’s life easier to achieve a common goal. Keep testing and iterating because an SOP is not far away from a product, after all 🙂

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.