Product discovery is a crucial part of software development. It answers a bunch of questions critical to your project success, including:
  • What should your software product look like?
  • What’s its main goal?
  • Who will use it?
  • What should the product be able to do?
  • What are the best solutions and are they technically feasible?
  • What resources are needed to make the product a reality?
  • What are constraints and unknowns?
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.

Product discovery in Waterfall

In the classic waterfall model for project management, the software product discovery phase comes first and is 100% completed upfront, before the development team touches any code.
waterfall product discovery
A lot of research, analysis, and documentation effort is involved, so this stage is lengthy. It can take four to eight weeks and more depending on your project complexity and consume a substantial part of your budget, typically 10-15% of the total project costs. At the product discovery phase in waterfall, you go through discussions, interviews, questionnaires, focus groups, observations, and documentation and interface analysis to elicit requirements for your software system, including: Business requirements
  • Getting a deep understanding of the business context, business model, objectives, and risks
  • Determining the product vision and scope aligned with the business objectives
  • Identifying success metrics
User requirements
  • Identifying and classifying users
  • Understanding user needs and pain points
  • Determining how users will interact with the system
  • Resolving conflicting requirements
System requirements
  • Determining how the system will meet user needs and business objectives
  • Identifying functional and non-functional requirements
  • Prioritizing requirements
  • Uncovering risks, uncertainties, and possible roadblocks
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:
  • Business description, opportunities, needs, goals, success metrics, and risks
  • Project scope broken down into initial release and subsequent releases, and system limitations and exclusions
  • Stakeholder profiles, project priorities, and deployment considerations
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.

Product discovery in Agile

The essence of the agile approach is about the continuous delivery of valuable software. This is done through iterative development where a cross-functional team creates a meaningful work product (a feature or improvement) at the end of each iteration that lasts two to four weeks.
agile product discovery
Software product discovery in agile runs in parallel with the delivery track. And unlike in waterfall, it is focused on a fast validation of ideas based on experiments and user feedback to inform the team of product increments that should be built, tested, improved, or fixed for bugs in the next iteration. As estimates are made for relatively small tasks, the scope complexity and risks are significantly reduced, and development goes faster. But how do you get started in agile? Sprint 0 In agile, a software development project often begins with pre-Sprint 1 activities that are in fact waterfallish in nature and are known as Sprint 0 or the Inception Phase. Unlike in the waterfall strategy, this pre-planning, which we will call for convenience Sprint 0, is short. It takes a couple of weeks or less. The key objective of Sprint 0 is to get a grasp of the problem, develop a high-level understanding of the solution, and prepare for Sprint 1. Normally, Sprint 0 activities include:
  • Identifying a high-level product vision
  • Exploring the system’s scope, including a high-level software architecture
  • Identifying and prioritizing an initial product backlog, which is a list of work on the deck for the development team to complete
  • Defining non-functional requirements (security, performance, scalability, etc.)
  • Identifying the required skillsets for assembling the team
  • Defining roles and responsibilities
  • Estimating the team’s velocity (the amount of work that can be completed in each iteration)
  • Identifying project risks
  • Planning an initial roadmap based on the product backlog, velocity estimates, and dependencies
  • Defining your Definition of Done (DoD)
  • Defining a software testing strategy for the project
  • Agreeing on, and setting up, reporting and progress tracking tools
  • Setting up technical infrastructure and development environments
  • Preparing initial low-fidelity prototypes and wireframes
The deliverables include:
  • Prioritized initial product backlog, including low-fidelity prototypes and wireframes, if applicable
  • A high-level software architecture
  • Defined DoD
  • Project risk strategy and mitigation plan
  • Ready-to-go project infrastructure and tools
  • High-level definition of non-functional requirements
  • Defined test strategy
  • Team setup
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:
  • Understanding and defining the problem
  • Identifying, prototyping, and testing a solution
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.

Which way you should go — Our tips and insights

Both agile and waterfall are proven strategies and good ways to do the software product discovery process. The choice for your specific project would depend on many of its variables (and your preferences). However, there are a few rules of thumbs, including:
  • Your product vision. If your product vision is not final, there’s no other way around but to go with agile discovery. For instance, you may be nurturing an idea about an innovative product, meaning there are too many unknowns to plan the entire project ahead. Alternatively, you may have only a vague idea of what your product should be and want to test and validate as many hypotheses as possible. Or, the efficiency of your software would highly depend on end-users’ feedback, which you then need to collect as your product is evolving.
  • Your project scope. You should also opt for agile discovery if you want to be flexible with your project scope. Agile welcomes changing requirements even late in development, allowing you to improve initially planned features or add new use cases when, for instance, updated data on user needs arrives. But Heaven forbid a requirement change in waterfall. Redoing all the planning or even a ready piece of software (and testing along the way) will cost you both precious time and money.
  • Project complexity. The waterfall strategy will be your right choice if your company needs thorough and detailed project documentation because of compliance issues presented by a highly regulated industry or internal policies and procedures. It also makes sense to set money and time aside for a massive product discovery phase, if your product is too complex and will need integration with a lot of external systems.
  • Time constraints. If you want to hit the market as quickly as possible, skipping the lengthy planning stage and going with agile discovery will be a better strategy.
  • Your budget, too. Sometimes, a company just doesn’t want or doesn’t have the budget to spend on massive planning activity. With limited funds available, giving away 10% of the budget before you’ve hardly started fleshing out your project, will likely mean saving on functionality. So, agile will be your go-to option here.
If you’re still unsure about a product discovery path for your project, contact our experienced project management team for a free consultation. We will be happy to dive into details and figure out the right strategy for you.