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.
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 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:
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:
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:
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!
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:
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.
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:
In general, there are different types of SOP formats that you can adopt based on your unique requirements.
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;
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:
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.
To summarize a few key takeaways,
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 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.
Value has many forms outside of the exchange of money for products/services. It can be in the form of saving time, increasing revenue, etc.
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.
Learn more →
