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