Product & Scope

What shall be created and delivered? Creating the right product with the right scope are probably some the most important and challenging project tasks, including:

– Inventing a new valuable product. 
– Prioritizing the right features to include in the scope 
– Defining business needs in details 
– Designing solutions right 
– Managing and prioritizing scope throughout a project

Read More

Creating a valuable product: In the preface to his book “Inspired – How to create products customers love” Marty Cagan writes: It doesn’t matter how good your engineering team is if they are not given something worthwhile to build. It is fundamental to all projects that they build something that creates value (ref 1)

Inventing a new product is a creative process: Consider it to be an elicitation or discovery process to define a new product or service. The process is not necessarily linear it may require the combination of many different skills brought together. Workshops, prototyping, diagrams, drawings, interviews are methods that can be used. Long textual descriptions are usually not the most effective way to invent and explain a new product.

Invest in the product definition process: Defining the product to be made is one of the main activities in a project. Surveys show that app. 15% of total time in a project is often used to define the product. Good quality in the product definition and specifications used for development saves time. Studies show that product definition and requirements defects are often accountable for more than 50% of project rework and  it can cost as much as 10-20 times more to change a requirement once it has been developed (ref 2)

Key roles: Those persons that can create the right product and define scope right are some of the most important persons in the project. Therefore make sure to have the right product owner and architect on-board.

Product definition: Defining the product, the service or the solution to be made is a task taking place throughout the project, and even before a project is initiated. Product definitions start with initial ideas, evolving to product visions and to requirement specifications or backlogs defining features in and out of scope, and specifications required for the development.

Scope: Defining what shall actually be delivered in the project is a key task to ensure the project team working towards the same objectives and to align with stakeholders what is in scope and what is not in scope. There will never be capacity, money, or time enough to do everything in a project, the scope represents what the project shall actually deliver

Functional and non-functional scope: Projects are always initiated with the purpose of creating something new, however, and not at least when something new is made and when a project is big so-called non-functional requirements tend to make up a huge proportion of total effort – often more than 50%. This includes technical tasks like establishing infrastructure, system integration, and project tasks like project management, test, and reporting. 

Requirement specification or product backlog: In order to get an overview of the work to be made in a project all known features can be collected in a requirement specification or a product backlog, typically with some hierarchical or WBS structure. To serve needs for prioritization, estimation, or planning the backlog must be broken down to the appropriate level. 

Be aware that the estimation of big chunks tends to be un-precise and be aware that there is usually never a full overview of scope when a project is started.

Baseline scope: As a basis for managing the project a baseline version of the scope can be used to align with key stakeholders what the project shall deliver, to monitor progress, and manage scope changes

Change management: A project that tries to do everything will get nothing done. At the same time projects cannot define everything right up-front. There will be things nobody thought of, new good ideas will evolve and needs will change. A change management process is used to make a controlled process for scope changes including who is involved in approving consequences (solution, time, budget)

Approach: Traditional waterfall methodology will argue that the full product shall be described and specified before development is started, while an agile approach will advocate that product definition is an iterative process taking place throughout product development. Only enough details required to start development shall be collected initially. Details can be added when they are needed. This approach allows to incorporate learning and to adapt to changing priorities. 

Split between requirements and design: In order to make the best possible solution, it is considered good practice to separate the requirements or acceptance criteria that shall be met from the actual solution design that is being implemented. The reasoning behind this is that it makes sense to define the problem to be solved and the user needs to be addressed, before defining the solution to the problem. 

User involvement throughout product development: Evidence shows that products get better when users are involved throughout product development with time to incorporate users’ input.

Release early: Many projects have been negatively impacted by being in development-mode for too long without getting any real user feedback. To get early validation that product development is on right track considering how early validation can be obtained. Either by an early launch of the product or second-best by having early versions of the product that can be demoed and tested.


Ref 1: Cagan, 2008, Inspired, How to create products customers love, SVPG Press

Ref 2: source: Wiegers and Beatty, 2013, Software Requirements – Third Edition, Microsoft Press

Define product ownership
Create and share a product definition
Create a product vision/value proposition
Involve users in product and scope definition
Define documents and other information part of product definition
Create a prototype
Share product definition with stakeholders
Start product specification prior to the start of development
Define the process for product development (agile vs waterfall)
Create product backlog/requirement specification
Define the method for collection and documentation of requirements or backlog
Separate requirement - and design specification
Define the process to collect requirements
Collect requirements
Define Non-functional requirements
Prioritize product features
Define baseline version of requirements specification or backlog
Share product specification with stakeholders
Establish the change management process
Define milestones for product development
Create product releases that create actual value
Allow time to incorporate user feedback
Plan for post-go-live improvements
No plan for post-go-live product improvement

A real go-live can never be fully simulated. After a go-live, new issues, defects, and requests for improvements will always come up and the period after go-live is maybe the best time for learning and product improvements

Without a plan for post-go-live, an important opportunity for improving business value is missed

No clear milestones in product development

Problem: It is impossible to tell how far product development has come. Many aspects of the product are in process at the same time

Consequence: It is difficult to define the product scope, to plan and finalize development. There is a major risk that it is not the most valuable features that are being created.

No product change control process

Problem: There is no controlled way to incorporate new requirements.

Consequence: New requirements can be incorporated without proper consideration of value, priority, and time and budget implications.

No fixed/frozen product specification

Problem: There is no clear picture of what is inside and outside of scope. The delivery team is not sure what to create and it is difficult to plan and track progress.

Consequence: The project is exposed to the risk of scope creep, not prioritizing the most valuable elements of the product, and time and cost consuming product delivery

No clear and shared product definition

The product definition (vision, main features or details) is not well defined. Since it is not clear what to produce it is difficult to utilize project resources efficiently

Consequence: It may take many iterations to come up with a product that is valuable and the project is exposed to the risk of devastating the business case

Lack of product ownership

Without a solid product ownership, it can become hard to tell who is defining what the product shall be and it can be difficult to make the right decisions.

The consequence can be an unclear product specification with a significant negative impact on business value