Product discovery in waterfall vs. agile: The ultimate guide

If handled properly, the product discovery phase helps you make sure you are solving the right problem in the right way for the right audience. It also provides the basis for accurate project time and budget estimates. Poor planning is a top reason for IT projects to spin out of control. Various studies suggest that it is a source of defects in 40% to 50% of software products. Budget and schedule overruns are also commonplace, along with projects done perfectly on time and on budget but delivering a product that users just don’t need or like. Regardless of the type of software or feature you are planning to deliver, you ALWAYS need a product discovery process. The question that still remains is how you should handle the effort. There are two strategies to approach the product discovery phase: waterfall and agile.

User requirements

System requirements

After the product discovery process is completed, you have valuable deliverables serving as the springboard to kick off software development. The deliverables usually include: 1. Project Scope & Vision Statement. This document outlines a product concept and incorporates a scope part, covering:

2. Interactive prototypes. These can include mock-ups and proofs of concept implementing a slice of the product, wireframes for custom user interface or website design to understand how users will interact with it, and evolutionary prototypes that provide an architectural foundation for the product 3. Software Requirements Specification (SRS). This document, used as the basis for coding, is created to record in detail all functional and non-functional requirements. Its purpose is to outline all possible behaviors of the system under various conditions, data requirements, requirements for external interfaces, including user interfaces, and the systems’ desired quality attributes like performance, security, and usability. It may incorporate visual product models (context diagrams or environment maps) to provide a more clear perspective or analysis models (data flow diagrams, feature trees, state-transition diagrams, etc.) 4. Architecture design, built on the basis of the product’s functionality, quality attributes, and constraints 5. Scope baseline that consists of a scope statement, WBS (work breakdown structure or a hierarchical decomposition of the total work to be done to create the deliverables), and WBS dictionary 6. Project schedule created based on the scope baseline, activity duration estimates, resource requirements, resource calendars, and the risk register 7. Project budget estimates, driven by the scope baseline, activity cost estimates, project schedule, and risk register This upfront effort to discover and engineer the product’s requirements is truly massive and hard, so it’s critical to find a vendor with enough experience and capabilities to handle it properly (you can drop us a line if you choose to go waterfall). There’s one more thing to remember. While giving you the most predictability possible, the whole plan created in waterfall mode will still rely on many underlying assumptions. As a famous quote goes, planning is still guessing. And as godfathers of software development best practices ruthlessly add, “you’re never going to get perfect requirements.” The truth is, business requirements may change, either because of evolving priorities or because business people just haven’t thought through in detail what they actually need. Your developers may stumble across unforeseen technical challenges weeks or even months after the start of the project. Also, integration, security, or quality problems (if any) can be uncovered only in testing, which is not possible in waterfall until a stable product has been built. This brings us to the next alternative where such risks are mitigated.

The deliverables include:

To sum it up, the software product discovery process at Sprint 0 allows you to quickly set up a few things to get the team going in the right direction. After that, “hard-boiled” discovery begins. Discovery track Product discovery in agile normally runs one or two iterations ahead of the development track, with the same, cross-functional team doing the two tracks in parallel. The discovery track can be broken down as follows:

When doing software product discovery in agile, you basically collect ideas about new use cases, features, improvements, or bug fixes for your product backlog by researching and prioritizing user needs. Then you validate the ideas through experiments to make a decision whether you should build, or kill an item and keep learning. At the end of each iteration, you again engage with users to get their feedback, and new iteration planning takes place. The team is normally led by an engineer, a UX designer, and a product manager. It’s important to involve engineers in the product discovery process so that your development team doesn’t end up with solutions that aren’t technically feasible. This approach enables the team to eliminate failing assumptions fast, making them confident that they’re building the stuff users will surely like. Product improvements are right on the mark and quick, too. Removing many unknowns early in development also means that the project will be cheaper if it (sadly) fails or will produce a better quality product if it doesn’t.