An exclusive resource for Product folks!
A 13-point comprehensive project statement template
A stencil that is evolved through frequent feedback over years of building digital product & service-based experiences.
In Art, the final output revolves around the artist than the patron. In Design, it revolves around the end-user(or the customer in certain scenarios) and it is highly iterative. In Product Design, it doesn’t really matter who the creators are, as long as a problem is solved well under the given circumstances.
As designers and product managers, knowing where the line between success and failure lies becomes the point of reference for measuring the degree of success of a project. Given the variables in play here, there will never be a standard measure in gauging how much understanding is enough to resolve a problem well. Here comes the importance of having a well-crafted Project Statement.
The better the understanding of the elements that influence the problem and its environment, the higher the chances of solving it well. Given the lean work culture, a good Project Statement can optimise the efforts gone into such recurring rituals- gathering the requirements, building a strategy and defining the scope of work.
This Project Statement template aims at helping kick-start any Product Design project by posing some fundamental questions, and a well-crafted statement can serve as a much-needed guardrail and a single source of truth during the project. Towards the end, it helps the stakeholders in comprehending the impact better by providing a point of reference in an objective manner.
Crafting a good Project Statement is a skill and it takes time to master it. It is an inevitable milestone for any design project, unlike an artistic endeavour.
Remember, in the world of problem-solving well-begun is considered as half done!
The 13-point project statement template with definitions.
1. Project title
Give a meaningful name related to the specific task(problem/opportunity) that is being addressed here.
Follow a nomenclature with a version code that works for your workplace. Each organisation may have different archiving/naming conventions.
Elements of versioning can be borrowed from the Design Sprint numbers or Quarter naming codes along with a unique name of the project. (e.g. <projectName>_<SprintCode_YY>_<productCode>)
2. Product vision
A vision must be highly aspirational(also inspirational), and hence it may look subjective in nature.
Product Vision must capture the potential impact(outcome) the business wishes to bring in the long term under the perfect circumstances, and not be limited to design or product interventions alone. However, it must be something that is pragmatic(eventually) with a logical understanding of the future potential.
A vision defined at this level becomes the north star/a guide for all the subsequent projects(missions) be it a small feature or an entire product line. Once defined it usually doesn’t change from time to time, but can be articulated better as newer versions without deviating from its original direction and essence.
It is important to align all the projects with this larger vision set for the product/service as it informs the strategy taken at the individual project level, and those strategies further inform the tactics used at the task level to achieve the project objectives.
This might even look like a redundant item in most Project Statements under a particular product or a service, but it serves as a much-needed reminder to everyone in the pod.
3. Problem/ Opportunity
The single most important part of a well-crafted Project Statement is to identify the right problem to solve. How one defines the problem/opportunity can completely change the fate of the project and its success.
It really demands effort and experience to unambiguously frame the core problems(or opportunities) that will be addressed in the project without getting diluted by the stakeholders’ perceptions based on known solutions.
This might also mean stating even the obvious facts from the problem space owing to their influence on the solution space.
It is not necessary all problems are solved in the early attempts in the best possible way. But while planning, the team and its resources should have the capacity to solve it within a few subsequent versions(iterations), if not it might be better to break the problem into further smaller sub-projects, with specific and realistic objectives.
A suggested read: ‘Are You Solving the Right Problems?’ by Thomas Wedell-Wedellsborg on hbr.org
4. Project objectives(outcome)
A well-defined project objective reveals an ideal outcome when everything about the project is going well. It is best represented through statistical values in the form of leading and lagging indicators.
The more specific and unambiguous the objective, the easier it is to determine the success of the project.
Objectives can be derived from one of the two areas. First, it may come as a milestone set by the business with some Key Performance Indicators to meet. Where the team will actively look for systematic ways to meet the given objectives.
The second can be derived from product analytics or from hypotheses based on user research understandings. In such scenarios, a rough estimate is proposed in the initial phase and specifics are updated as and when there is more confidence and clarity along the way.
Not all project outcomes may not have direct & precise correlating product metrics to track(especially in the early stages of the products with too many assumptions in place, or in the case of experiment-based projects) but, even if it is tentative, the objectives must be contextual and rational(achievable under the proposed timeline).
If the outcome drastically changes at a later stage, the strategies taken may not be valid anymore, and any such deviations in the strategy will also make the corresponding design interventions defunct.
5. Proposed timeline
There is no magic formula for calculating the best timeline for design projects without some work. There are too many variables in play to decide on an optimal timeline. However, timeboxing is an art to master. What is expected here is to have a realistic understanding of the milestones(scope) to be covered under a pre-defined timeline.
P.S: Just spending more time does not guarantee higher quality, and on the same note, all lean approaches may not solve the problems equally well. Especially design infrastructure-based projects cannot be forced into smaller timelines just because the business stakeholders would like to release the product early. Such an act based on a short-term vision will unblock them but, it is bound to create long-term recurring problems that will only deteriorate the quality of the product/service eventually.
Not all design projects may fit well in an iterative fashion or can be completed(end-to-end) within short timelines and yet expect to be solving the problems well. Some projects are inevitably long and done well when taken enough time and migrated at once in a few months if not years. But some are organically/iteratively evolved over time by simply pushing the boundaries.
In an ideal design team, there will be a fine balance between projects of all ages and lengths. (Short& New, Long& New, Old& Short, Old& Long). The trick is in prioritisation whenever it is possible. It is better to timebox all design activities into multiple small milestone-based timelines(e.g. Sprints).
6. Target users
It is usually referred to as the end-user of the project’s output which could be a digital interface or a service. When the target segment has a wide range, it may be further divided into multiple sub-cohorts.
It is always great to specify even the obvious and general(collective) characteristics of the end-users and the primary context/scenarios in which they interact with the product/service. A context could be influenced by various elements like demographical, cultural, psychological, behavioural, attitudinal, temporal, etc.
P.S. At times the actual beneficiaries may not be the ones who are interacting directly(end users) with the service/product solutions of the proposed project, yet the project may be attempting to solve a specific problem for them via the end user. This could be the client(who may be actually paying for the service/product on behalf of the end-users), or it could be even some of the internal stakeholders within the organisation who may be playing an important part in delivering a better client experience. In such scenarios, it might be better to separately call out the beneficiaries(the target users) from the end users.
7. Strategy
The project strategy can be defined as a set of predetermined approaches (which could be simple milestones along the way) that would help the team move closer to the project’s objectives. Remember, it must be also aligned with the larger product/service vision.
The quality of the strategies may vary depending on the design maturity brought by the team with their domain knowledge. That means the same strategy used by different teams will not produce the same results as there will be too many variables in play.
Strategies work better when it is well-informed by the context of the problem and aligned directly with the vision. In a project statement, strategies are not expected to be well-matured from the inception, but they can be articulated better when there is better clarity. However, it must be frozen before getting into the tactical or execution phase of the project. Sometimes, work in progress strategy may take a major deviation and take a different form altogether. In such a scenario it might be a good idea to version the project statement and keep the older versions for future reference.
8. Output
Output is nothing but the final deliverables we promise to provide at the end of the project or with each milestone. These items are very objective and more tangible in nature. For example, it could be a proposal, a report, a set of wireframes, mockups, or final spec sheets of interfaces, etc.
The project outputs should not be confused with the intangible or qualitative project outcomes.
9. Limitations
Understanding the limitations(even the obvious ones) and calling them out is an important part of any problem-solving. It helps in optimising the resources efficiently and helps the team not waste time and effort when they do not have control over it.
Some limitations may have significant negative influences on the final outcome and calling them out early on will help in setting the right expectations among the stakeholders and to be prepared accordingly.
10. Leverages
Looking for the right leverages is an art in itself and it is often an underused trump card in problem-solving. There is a great advantage in starting with understanding the history of a feature or a product before working on improving them.
In most cases, if there is a lot of work done in the past or have many resources within the team/organisation that could be utilised towards better and quicker execution of the project.
Such leverages are often gone unnoticed when there are poor documentation practices or when there are fewer collaborations within teams. If used well, they can not only reduce the effort, time and money but also increase the chances of success in multiple folds.
11. Hypotheses
Given the iterative nature of product/service design projects, calling out hypotheses can make meaningful progress towards realising the larger vision.
A hypothesis is something the team will be explicitly tested to prove/disprove during the course of its implementation through planned feedback collection events and analytics. It is a list to watch out for in understanding your users better.
12. Assumptions
Unlike hypotheses, assumptions are not explicitly tested during the course of the project’s implementation. However, they are considered ‘undeniable facts under the circumstances’ for the time being to move forward with the project. These assumptions are usually formed from secondary research or deductive reasoning based on widely-accepted norms, or even gut feelings developed from previous experiences.
Like the Limitations, calling out Assumptions will be helpful at a later stage when analysing the impact the project interventions may have had on the final outcome.
13. The RACI matrics
Given the number of stakeholders involved, a product/service-based project can be complex, confusing and chaotic. The RACI matrix is a popular and effective framework for defining roles and responsibilities within a project.
Knowing exactly who is responsible, who is accountable, who needs to be consulted, and who must be kept informed will ease the friction in decision-making moments. Accountability can only be owned by a single person per department like Design, Product, Technology, etc. They are the ones who take the final call on their respective expert areas),
(If you wish to dive deep and understand this more, here is a good read on RACI)
Additionally, there is also a practice of having an A plus(A+) in the team. A+ intervenes when A is unable to come to a consensus with the pod members. A+ is usually the next in the hierarchy who can override the decisions made by the A. By doing this, the understanding is A has transferred the accountability of a particular decision to the A+.
For a Project Statement, I would suggest keeping things simple. It need not be broken down at a task level.
Here is an example,
A- Priyanka(Design), Siddharth(Product), Bharat(Technology)
R- Sayantan(UX), Abhram(UI)
C- Ravikiran(Operations), Ankita(Behavioural Design)
I- Dileep(Product Training Team)
A+- Hari Mohan(Head of Product)
Conclusion
All problems are unique, and there is no single framework to solve all of them in the exact same way. Owing to the degree of one's understanding of the problem space, the wisdom(x-factor) from the past and other unique contexts, each individual/group will have their own unique ways to solve problems.
A Project Statement is mostly built during the initial requirement-gathering phase and then parked aside when getting into a more tactical phase. One must stay away from making major alterations to the Statement as it may defeat the purpose of it being the single source of truth for the team. But better articulations of the same are something acceptable as edits.
Keeping a project log sheet along with the project statement for future reference can be a good practice. It has been very helpful in my past experiences where I record minutes of the meetings with major changes and decisions made along the way.
Cheers,
Dhaneesh Jameson | LinkedIn | Twitter
(Product Design Leader, Filmmaker)
