Unpacking the problem
Greenfield projects refer to developing a product for a completely new environment and lacks constraints imposed by prior work. When scoping products that have no existing infrastructure or user base, it is important to take a problems focused approach. Beginning the scope with a problem statement, means that the team can diverge on a myriad of different ideas before finding the most viable solution.
The observe phase of scoping is critical for Greenfield projects to validate ideas through discovery interviews and user testing. Quantifying feedback and comparing it against market research will help to ensure a usable and lovable product is developed.
Brownfield projects refer to the development and deployment of a new software system alongside an existing or legacy system. For example, a system that was developed years ago is now legacy and the technology is at risk of becoming end of life. Modernising that system would constitute a brownfield project.
When scoping projects where legacy software is involved, there is generally a pre-defined solution in mind. In this case, the customer will supply a set of functional requirements or have a clear idea of their project goals. It is important that the scoping team spend time to deeply understand the existing platform, so that they can design the next phase of its roadmap.
The benefit of a Brownfield project is that there is an opportunity to learn from the existing user base and make improvements. The risk, however, is that it can become difficult to constrain the scope to a single problem statement. As mentioned above, smaller scopes are key to de-risking the development workload. The simplest way to accomplish this is by breaking the scope into manageable builds.
A worthwhile note is that scoping projects in this manner hampers a Product Designer’s ability to perform validation of the underlying problem, and instead assumes the validity of the legacy (Brownfields) application.