Understanding the problems that a customer has with your product is one thing. Translating those problems into solutions and why those solutions matter is another thing.
Creating a one-to-one link between problems and solutions and getting your team to understand that link is an art in itself. As the product manager, it is your responsibility to not only ensure that customer problems are well defined — and have ample evidence to support your assertions about the customer problem — but also that the link between the problem and solution is made clear.
This is where a statement of work (SOW) can help. A statement of work is the singular place your team and stakeholders should reference for questions. SOWs answer the usual “who,” “why,” “how,” and “what,” as well as the reasons for building a feature.
In this article, we’ll explore the definition of the statement of work (SOW), reasons why an SOW is important, the typical structure of an SOW document, and an example of how to use an SOW.
A statement of work is usually an internal team document that defines a customer problem that needs to be solved and the investment required to solve it. Determining the investment involves considering different types of solutions, whether or not they’re feasible, as well as resource constraints.
There is no one right way to write an SOW. The main requirement is that it’s clear on communicating the type of problem that needs to be solved and the time and money required to solve it. A well-written SOW can compare and contrast these factors and ultimately offer guidance on what to do.
The following reasons are the main purpose behind writing a statement of work and why a well-written SOW is important:
As mentioned previously, part of the statement of work is to clearly illustrate the type of investment needed to fully investigate and deliver the solution for the customer. This investment does not need to be exact or known far in advance — it can be a simple estimation based on previous experience and on how much investigative work needs to be done.
As a product manager, it is your responsibility to collaborate with the appropriate team members to shape investment expectations. This should be done in a way that accurately reflects the team’s ability and capacity. It’s important to use wording that’s easy to understand but specific enough to give outside stakeholders an appropriate, reasonable indication.
Part of the SOW should cover a summary of customer problems, including details as to why these are problems for them and where in the product they are facing them. This summary will be referenced later on in the document when determining the different ideas and solutions the team has to tackle them appropriately.
Laying out the problems in this manner helps communicate the customer’s pain points and issues to the team as a whole. It also helps stakeholders outside of the team get an overview of why the customer feels this way and what the team is doing to solve it.
Ultimately, the SOW provides alignment and clarity between leadership and the team whilst also making the reasons for investing time in this work clear.
Finally, the team benefits from having all this information laid out in a formal and structured document. It helps to ease the team’s concerns or fears that the problems may not be a big deal and provides them with confidence that they are building something that will benefit customers (and the product as a whole).
By providing this validation and confidence to the team, they can follow through with solutions without any doubts about the problem space they’re operating in.
As mentioned previously, there is no one set way to write an SOW. Rather, it is important to structure the SOW in a way that helps the team understand the customer problems they are trying to solve, as well as formally puts down an estimation of the effort to solve it.
That said, the following is the typical SOW structure (that I also use at work):
The background section should include a summary of previous decisions or events that led up to the problem that the customer is facing. Giving this perspective to the reader allows them to understand, retrospectively, why certain decisions or structural changes were made in the product that led to the current issue.
Examples of what can constitute part of the background include:
Other than previous decisions or events, this section should also cover industry trends and/or competitor offerings that contribute to the customer problem.
Gathering this information primarily relates to the continuous discovery and analytical cadences that you, as a product manager, adopt every day. Most of the information in this section depends on how you investigate and converse with customers to figure out the true reasons for this problem existing in the first place.
The conclusion of the background should transition to the problem the team is trying to solve. Ideally, this is also in the form of a summary — the Jobs-to-be-Done (JTBD) framework below will allow you to expand.
This section should cover the following:
As the product manager, it is your responsibility to clearly and succinctly explain the problem so that anyone reading through — whether they are engineers, designers, product managers, marketing, sales, etc. — can grasp the problem and its importance.
This is where the proposed solution — ideally brainstormed and discussed by the team, including any other relevant stakeholders — is considered. It doesn’t have to be the one solution that everyone agrees to and is the definite way forward. Instead, have about three to five alternative solutions that either solve the problem entirely or are components of a whole solution.
Again, this does not have to be something concrete at this stage. There will be assumptions, estimations, and questions that can only be answered when the work is green-lit and the team invests resources. Instead, the goal here is to give the team and other stakeholders an idea of what the work might look like. This will help feed into the discussion of what the investment will be later on in the document.
The types of solutions that can be shared here include:
Following on from the proposed solution, this section should be used to explain what the team would not be focusing on as part of this work. The information for this will come out of brainstorming sessions you have with your team (for example, running through a MoSCoW framework or other prioritization matrix that you like to use).
It’s good to be clear — not just with your team, but with other stakeholders as well — the kind of work the team is thinking of doing and the scope to be done in a certain time frame. This will help budget the investment of time and money required and help others understand the reasons for scoping.
The JTBD framework revolves around the idea that customers want to buy products or use services that help them get an important job done. When considering which products to purchase or use daily, customers will assess how well that particular product delivers on their optimum outcome —the “job to be done.”
One of the biggest reasons for thinking about the customer needs in terms of a job, rather than the benefits they’re looking for, is that customers are usually imprecise about what they are actually looking for. This tends to then muddy the problem space, leading to product teams building functions and features for the wrong reasons.
Including JTBD stories here as part of the SOW is the connective tissue between the problem and the proposed solution(s). This helps the reader understand why the solutions are effective in solving the customer’s problem.
For this section, you can follow this easy structure where the issue is the job to be done and the user story is written in the “As a [persona], I [want to], [so that]” format:
| Issue | User story |
| xxxx | As a [persona],
I [want to], [so that]. |
| xxxx | As a [persona],
I [want to], [so that]. |
| xxxx | As a [persona],
I [want to], [so that]. |
Finally, the SOW should be rounded out with the proposed investment that the team will make. As mentioned previously, this does not need to be anything exact — it’s just an estimate.
This should be a reasonable estimation — one that is based on previously completed initiatives of similar size and scope or on the capacity the team has.
An example of how this can be framed as an estimation would be in terms of batches. A “big batch” can take anywhere between 4–6 weeks of engineering work and a “small batch” can take 1–4 weeks, for example.
Ultimately, it is up to you to provide an estimation and how it’s measured.
Here is an easy template using the above SOW structure. You can modify it however you like, but I find it easiest when the components are explicitly laid out this way:
The following is an example of how you can create an SOW document based on the structure mentioned above. Imagine that, based on your continuous discovery efforts, you found out that you needed to implement two-factor authentication so that your users will feel safe and secure when logging into their accounts on your social media app.
The SOW would look something like this:
As part of the initial implementation of our product, we decided not to implement two-factor authentication so that we can push an MVP as soon as possible to potential customers.
Although this helped us gain traction in the market and assisted in the growth of our product, we soon realized that customers were not happy with just using a username and password to log in, particularly due to widespread industry reports of customers finding that their accounts have been hacked.
We’ve identified a main reason for this occurring: the absence of two-factor authentication for most other products out there. This is why we are not considering it as part of this statement of work (SOW).
Due to previous decisions made and the current industry trend of widespread social media hacking, our product is now at a distinct disadvantage to some of our competitors. The main disadvantage is that our identity and access management (IAM) system is now exposed to anyone that can steal the usernames and passwords of our users without having any secondary checks in place to verify the user’s identity.
Based on conversations with customers, this is not acceptable and something that needs to be addressed in the immediate term. The main way in which customers would like this addressed is through the implementation of two-factor authentication, with the use of external authentication methods such as Google Auth or Microsoft Authenticator.
The risk of not focusing on this work now is that we continue to leave our users exposed to the possibility of being hacked. We are accountable for any user accounts that are hacked easily due to the lack of secondary security measures, which are somewhat easy and reasonable to implement, based on the proposed solutions later on in this document
The following are the possible proposed solutions being considered by the team to tackle the above problem:
Of the above, we believe the first proposed solution, and perhaps the last, would be the most reasonable to implement within the proposed investment period, covered below.
We are not considering the following:
We believe that, of the above two, the former is too complicated to implement in our proposed investment time frame, and the latter does nothing to solve the real problem (the inability to authenticate a user when they are logging into their accounts as a secondary security measure).
Jobs-to-be-Done (JTBD) user stories
| Issue | User story |
| Allow users to enable two-factor authentication when logging in | As a social media user;
When I am logging into my account; I want to be able to authenticate by identity via two-factor authentication; So that I can log into my social media account safely and securely |
| Allow users to enable a special code/link sent to their mobile devices when logging in | As a social media user;
When I am logging into my account; I want to be able to use a special code/link that is sent to my mobile device to log in; So that I can log into my social media account safely and securely |
| Allow users to create security questions that need to be answered when logging in | As a social media user;
When I am logging into my account; I want to be able to answer security questions when logging in; So that I can log into my social media account safely and securely |
| When using their mobile phones, allow users to use their devices’ biometric authentication methods to log into their accounts | As a social media user;
When I am logging into my account; I want to be able to use the biometric authentication methods on my phone when logging in; So that I can log into my social media account safely and securely |
The above solutions are all “big batch” investments and will take approximately 4–6 weeks to complete, with all six members of the engineering team involved in the work.
Follow the above steps and you’ll be creating your own SOW in no time. Until next time!
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.
A product sense interview measures a candidate’s ability to understand users deeply, frame problems clearly, and generate creative solutions.
A competency matrix is a structured framework organizations use to evaluate, align, and map skills across different roles.
It’s important to distinguish between these roles and create an infrastructure where they come together to build useful products.
Memos don’t have to be complicated. Just keep them clear, concise, and focused on actionable items. More on that in this blog.
Learn more →
