Fewer things are harder than writing a scope of work document, because it is more than just writing — it’s an experience, with multiple acts. Therefore, the purpose of this isn’t just to help you write one better, but to help you ease the burden; if like me, you find yourself in the unfortunate albeit rewarding role, of being a product manager. This might be a long read, depending on your tolerance levels, so I split it up into two parts to give you a breather in between that will help with understanding it all.
A key point, before we get down to business. In order to write a good scope document, you need to be able to visualise the product, the process of building it, and each of its working parts — which should by no means be perfect, but is a good way to start to open up your mind to infinite possibilities (go back and read that again till it sinks in). Think of it like wearing new shoes, where you completely forget about what you are used to and put aside your assumptions, limitations and biases. Just focus on the information you have been given about the idea and product concept, then let your mind run wild.
For the purpose of illustration, I’ll be using a sample company called KMo Ltd, that wants to build an application to sell bus tickets to road travellers. So, customers should be able to download an app to book bus tickets from different companies (e.g. GIG, Chisco, etc) and KMo staff should have an admin panel where they can manage orders, track metrics, payments, and so on. Sound simple enough? Great.
Now to the key parts of the scope document. These are high-level so you can add or remove as many subheadings and titles as you want, under these, as are applicable to your product:
- Business Overview
- Product Strategy
- Product Definition
- Technical Definition
- Architecture
- Development
Business Overview
In order to write this section, you need to speak to the key stakeholders, and get an idea of the vision, mission, aims, objectives and goals of the company as a whole, as they relate to the product. The critical aspect to getting all required information is asking questions and if done right, it will help to keep the product aligned with what the business is trying to achieve. As a PM, you will want to do a deep dive into what the overarching purpose of the product is, and its relevance to the business. So for instance, you would typically be asking questions about why the hell KMo even wants to build a bus ticketing app? (Excuse my French) In my experience, I find the Five Whys methodology very useful. This is a very simple technique originally used in manufacturing. The idea is to ask why until you get to the root cause of a problem — although typically, it requires asking why five times, this could require more or less whys.
An example for KMo, might look like this;
We want to build a bus ticketing app
Why? — Bus tickets are not easily and quickly accessible for people to buy on the go
Why? — They are sold by individual bus operators via separate channels
Why? — There is no single platform that sells tickets for all operators
Why? — The industry is not organised properly enough for information to be easily accessed
Why? — The bulk of operations exist offline in informal environments, which makes it a hassle for anyone seeking to get relevant information like price comparison, time, and dates of travel across different operators
It might look easy on paper, but the process can come across as redundant in practice, meaning that you have to be quite persistent to get to the juice of it — the root cause of why a company is launching a product. From the above, we can deduce that an opportunity exists for KMo in the bus industry space, to potentially earn revenue from bus operators through tickets sold on their platform, based on high sales volumes.
Once you achieve this, a huge benefit is that you will have more clarity on what is driving the product, and this will guide your product strategy in the next section.
In the next part of this section, you need to outline the assumptions and hypotheses that the company is seeking to test by building this product. Usually, these are implicit and not immediately clear, but they can be deduced from the problem statement, and the solution the business is offering. One assumption KMo makes for instance, is that by launching a new bus ticketing app, there will be a large enough volume of pained customers willing to use this app, and that will generate sustainable revenues.
Other key parts of this section are necessary information such as an outline of the team members, along with a high level timeline of when the product is expected to be delivered. I know a lot of PMs struggle with agreeing to fixed timelines for products, especially those working in Agile environments. A great way to manage expectations of higher management is to break product deliverables into Phases. So, Phase I could be delivery of an MVP, Phase 2 would be a more stable product with additional features, and Phase 3 would be the final product with all the extras.
Finally, this section should end with a business positioning statement that looks something like;
“For (target customer) who (has key need(s)), the (product name) is a (product category) that (proposition of key benefit). Unlike (competing offerings), our product (unique value proposition / differentiation statement).”
I wouldn’t worry too much if you don’t have this yet, because writing this document is an iterative process, so you can revisit this after covering the other sections.
Product Strategy
The product definition is a component of the Product Strategy, which makes it a bit difficult to distinguish what falls under each specific heading, so if you find that these sort of meld together in the process, you should not worry too much.
I heard about Design Thinking about a year ago, and it had a profound impact on not just my work, but the way I think about products in general. While at my previous company, we were lucky enough to participate in a program organized by Stanford University, whose d. school popularized the concept in the tech world. Design Thinking is simply put, a solution-based approach to solving a complex problem, and the d.school has a five-step methodology, which are below:
- Empathise
- Define
- Ideate
- Prototype
- Test
As a side note, I intentionally don’t use numbers throughout this article, because in reality, product development is hardly linear. Although there are steps in theory, these things often happen in tandem and continuously form a cycle.
The first part of your Product Strategy should focus on extracting and identifying users, crafting a target audience, defining competition, and exploring the business model. The second part is the product definition which outlines the specific products to be built, feature definitions, acceptance criteria, and more. I feel Design Thinking is a brilliant guide to help you intentionally craft this section of the document, so I will expand on the steps above to guide you through writing the Product Strategy.
Empathise
User research is an extremely underrated part of building a product, because more often than not, probably because it’s tedious to do otherwise, we assume that a market exists by default. And that’s wrong because although a market exists, does one exist for your product? The first stage of the Design Thinking process can really help with identifying who exactly your users are, and the audience you should be trying to target. In this step, the idea is to deeply immerse yourself into the environment of the user whose problem you are trying to solve. The purpose of this step is to gather information in as many forms as possible, that will help you achieve product/market fit. Although, we have an idea of the kind of product we are seeking to build, we need to put aside all assumptions and seek to understand the users through interaction, and also by observing them in their natural environments.
So, we are back at KMo HQ and we have arrived at this wonderful business positioning statement, but this is just the beginning. Now, we have to go back to the problem we are trying to solve — bus travellers lack access to accurate information across operators, because the bulk of operations in the bus industry exist in offline environments, and is not properly organised. This means that we have to go directly to the source of the problems with open minds, open eyes, and questions; where do current travellers buy tickets from? What channels are used by the bus operators to sell? What are the biggest pain points of the travellers?
The result of user research should give you an idea of who your audience really is, and what problems exist for them. If we had previously thought that we might be able to aggregate information from all bus operators, and having done research, couldn’t find a sustainable way of doing this for some older operators with an older demographic of users, then we would have to narrow our focus down to the newer operators and sell to younger travellers, in order to accommodate this new discovery.
Once you have a solid idea of who your users are, the next step is to fine tune them into personas.
Get your FREE User Persona Cheat Sheet here!
Try to assign distinct characteristics and identify unique problems pertaining to each persona, so that your solutions will adequately capture your entire audience. You will realise the true value of this in the product definition stage when outlining features, because you should then be able to map requirements to the specific user persona you are building for. For example, a Student bus traveller could be one persona who is very different from a Sales Executive of a bus company, but KMo’s solution should be able to cater to both.
Click HERE to get your free cheat sheet or go straight to Part 2 here!
