How to write a Program Document?
This is part 2 of a long-form series of setting up your Product Documentation.
You can read part 1 here, where I discuss how to set up your Product Documentation structure, which tool to use according to your requirements, and the type of documents you’d have to write for building Products.
If you don’t have the need to write a Program Document or already understand how to write one, feel free to skip over to the next part where I discuss how to write a Product One Pager for aligning your Business and Design stakeholders to build your next Feature or Module.
A Program Document is a document that’s meant for instituting a new Program in an organization meant to attain a business objective that involves multiple functions working together to roll out a combination of Products and Services.
A Program is broadly an Initiative taken up by an organization that may involve the collaboration of multiple functional units in an organization to put together an experience for their customers. Organizations that are tech-enabled and aren’t only technology-based do have an operational leg to be performed in the delivery of the Product or Service to their customers.
In such cases, a large part of technology adding value to the organization is by enabling your employees or personnel to scalably and reliably deliver a service or an experience to your customers.
Both types of organizations nonetheless need formulation of programs for the launch of initiatives to solve a business objective that is cross-cutting in their concern across different functions or departments. Programs are usually initiated by Program Managers or Product Managers in collaboration with the formulation of a business plan to attain the stated objectives.
In the case of EasyRide, the process of a user placing a booking request to a driver for availing a cab online on demand and the drivers responding to the request is enabled by ensuring that there are enough drivers in the user’s vicinity to pick up and service the request. In order to ensure enough drivers, the ‘Supply’ program managers would be responsible for bringing drivers into the system strategically across different locations and geographies.
Let’s take the example of EasyRide wanting to increase the average revenue per user. To increase their ARPU, let’s assume that they decide to come up with an initiative of offering Value Added Services for their customers by offering ‘Food’ and ‘Beverages’ on rides. The users would place orders and based on the inventory available with a particular driver, would be offered these food items while on their way to their destination.
Let’s discuss the structure of a Program Document by taking the example mentioned above -
Objective
The objective of your Program Document should be the Business Objective that you’re chasing for which you’re formulating a Program. This Objective should be a measurable goal with a defined cadence (Frequency of tracking) for the goal.
For our use case, the objective would be to increase the ‘Average Revenue Per Paying User’
Success Metric
Please note that the business success metric is a little different from the Product Success Metric unless the entire experience of the Business is on the Product. Here, we’ve defined a Business Metric as the criterion for success or failure of this program. For our case, the success metric would be —
User Journey
The User Journey Plan should be the broad idea of the steps that your user will go through while experiencing your service or product. Please note that we’re taking users in the generic sense. A user could be a direct consumer of your product or service or an internal user or partner for whom you may be coming up with a program.
Let’s put together the User Journey for our Program above —
Notice that the user journey as defined in the steps above is spread across 3 different types of users and 3 different products. We’d need to build these 3 features on the respective products according to our initial analysis.
Execution Plan
The Execution Plan should be drafted only after your User Journey Plan is completely thought through and you’re clear on what your user will experience after inputs from all the teams involved in this Program.
We can clearly see from this plan that the total functional stakeholder types in this Program are the following -
- Supply Team
- Operations Team
- Logistics Team
- Crew Management Team
- Marketing Team
Please note that this could differ from Program to Program.
This type of execution plan of a Program is also good at communicating the current status of each function’s execution and the expected timeline of doing so. This also holds all the functions accountable for their respective deliverables.
Product Plan
A Product Plan should list down all the Product features you’d need to build taking inputs from the User Journey and Execution Plan drawn out by all the relevant stakeholders. This is the exact space where your Initiative gets broken down into implementable Features across Products.
For our example, the following should be a Product Plan —
Notice that the Product Plan is an extension of the User Journey but also borrows from the Execution Plan to gather the Product requirements of other stakeholders involved in the process.
Business Model
There’s no one defined method for writing a Business Model specific to your Program flow. A Business Model, however, should contain what the net Profit and Loss statement of your program would look like, what amount of budget you’d have to come up with, and the unit economics of your Program if required.
It should also define in economic terms, the benefit that the organization would accrue by going ahead with a Program.
Summary
A Program Document is the largest level document that you should come up with if the size of your organization or the number of departments or functional units is large.
The Product Plan in your Program Document should become a reference guide for your Product Roadmap and the features on the roadmap. The Product Plan should also set the process rolling for writing the subsequent Product One Pager documents corresponding to each Feature or Module that you intend to build as a part of the program.
While it may not be necessary to write, a Program Document brings together disparate functions in an organization like nothing else and forces everyone to become accountable for their part of the responsibility with adherence to an expected timeline. With that said the ownership and accountability to deliverables of a Program should be enforced by top management personnel. Without accountability, the Program document quickly devolves into a set of To-do lists.
In the next part, we’ll discuss breaking down a Program Document into implementable Features writing a One-Pager document, and coming up with a free one-pager template.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
