Project Discovery vs. Product Discovery: What’s the Difference and Why It Matters
In the previous installment of this article series, we introduced the concept of discovery. Discovery is the process of learning and documenting important information about a project before the “real work” starts.
The goal of discovery is to provide the development team with information about the project’s environment. With sufficient knowledge of the project context, the team will understand the high-level business problem (or problems) to be solved and the full scope of the project.
Before we discuss the details of the discovery process in the next article, let’s take a side trip to distinguish two related but separate concepts: project discovery and product discovery. Both are essential to project success, but their goals are different.
Project DiscoveryProject discovery covers information about the project as a whole and its business drivers.
In project discovery, the development team meets with the business-side stakeholders to discuss high-level aspects of the project, such as:
- The business problem(s)
- The expected project outcome(s)
- The project customer(s)
- The end user(s)
- The roles of the stakeholders
- The expected timeframe
- How much the business is willing to spend on the project
The business-side participants in project discovery generally include the project sponsor, business and IT leadership, and business process owners. Depending on the organization, one person might fill more than one of these roles. In any case, the participants should be decision-makers knowledgeable about the business problems, objectives, and budget.
A critical benefit of project discovery is that it can uncover “red flags” that indicate the client is not ready to embark on the project. If discovery turns up a lack of agreement on the goals and scope of the project, for example, it’s a sign that the project is likely to fail.
Product Discovery
Product discovery is more detailed and relates to specific applications or modules’ requirements and use cases. A software project may involve more than one product so that several product discovery exercises might exist.
Product discovery covers aspects such as:
- Details of the specific business processes to be supported by the software
- Who the end users are (business users, external customers or vendors, and so on)
- The end-user environments (office, lab, factory, warehouse, field)
- Devices (PCs, laptops, tablets, phones)
The outcome of product discovery should be a set of software requirements that describe what the solution should do. How the solution will be implemented is not part of the product discovery agenda–that comes during product design.
Product discovery should always be conducted regarding the findings of project discovery. For example, the scope of a software product should not be outside the project’s scope. It should not attempt to solve business problems other than those identified in project discovery.
Product discovery sessions should involve representatives of the end users who can describe their pain points and what they need to do their jobs more efficiently.
Up Next
In the final article in this series, we will examine how project discovery is performed, who participates, expected outcomes, and–most importantly–how the information is used to prevent project failure.
How Solution Machine Can Help
Solution Machine’s consultants have extensive experience with custom development and rescue projects.
By staying connected with our clients, we’ve been able to quantify the financial benefits, on both the cost and revenue sides, for projects we have helped execute.
If you are planning a software development project, contact Solution Machine today to learn how we can help you estimate the financial impact of your initiative.