Discovery Phase in Software Development

When do you need Discovery?

Hardly it is a mere guessing whether you need discovery or not. It is firstly the experience in software development that from the first talk with a client can give answer to the question – does this idea need discovery? Raw projects, the ones with constantly changing requirements due to trends or other conditions, startups are especially recommended to have an expert view over the project idea. If you have ever thought about the next questions, and doubts arose, then it is almost a verified need for discovery service:

How not to miss any requirements for my system?

Do I properly set requirements for the system?

How will my clients use the application in a particular situation when…?

What trends could differentiate my app from other apps?

How many screens would be optimal to have?

How much does it cost to make such an application?

What improvements can be made, but how much will it increase development costs?

Where can I get consultation on my software product?

If you’ve not consulted any business analysts, or software companies, professionals who could apply tools of analytics to learn your customers in a technically right and advantageous way, if these questions resonate for you and you have other specific ones concerning your app, than let’s go deeper into how discovery is conducted and what it will bring to you.

Note on the goal of Product Discovery

Goal of the Discovery phase in software development is to eliminate risks of building an app users won’t need, not to find out the product requirements.

Focus on problem validation, not solution building

Product Discovery Tips, Roman Pichler

This is what Discovery phase really is by the author of “How to Lead in Product Management”, “Strategize” and “Agile Product Management with Scrum”.

It does not say that requirements are not important. It means requirements go after you have validated the problem knowing what product you are building and what the target audience is. Your product features, design, trends, values you input should resonate with needs and values of target audience. UX, user stories, choosing tech stack, drawing architecture should be done after your idea is assessed. Understand firstly what problem you solve with your app. Then, you can smoothly shift to the actual features of the solution and how users would interact with the system.

Whether you need the mobile application for education, cloud web application for logistics or any other industry you will certainly ponder the risks, possibilities and future success of the product.

Your product discovery work should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product — not on writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of building a product nobody wants and needs, not to figure out the product details.

Roman Pichler

How to conduct discovery for your business?

Turn to a software provider. When you address a software development company, do not expect they will start the implementation the next day. They will look at your requirements or documentation if you have any. You can present an already compiled project plan ready for implementation. However, if your requirements are vague and you dimly understand what improvements you could drive, the team would like to get acquainted with you closer. They will challenge your vision and set a variety of questions during discovery meet-ups. 

Conduct enough research yourself. Talk to users, send surveys to people who you think are your target audience and will benefit from the solution the most. Be ready that doing it yourself can take pretty much time. You should have a fine sense of what to ask, have tools to reach your customers, learn a lot about market trends. Test your product strategy with observations, interviews, and prototypes. Namely there are three key elements in product strategy you should pay attention to:

• Market and Needs
• Business Goals
• Key Features

The process of Discovery at software development companies

The first step in app development discovery phase is validating problems. The second focus of Discovery Phase process is on setting, refining and analyzing right requirements to deliver the system with 100% effective performance and high-quality functionality. People involved in delivery are usually involved in the discovery phase to avoid loss of knowledge. In a team there will be UX designers, QA engineers, technical architects, senior engineers, business analysts and lead software developers. Usually, the discovery phase in web development is based on meetings with a client during one-two weeks. However, depending on the size of the project discovery can take more than four weeks.

At the beginning, the product owner explains how the solution should work, how and when users will use it, whether it will be a web and mobile or responsive app, what key features should be there. The client presents the company with the first portion of necessary information. Then the path – from framing the problem to solution building – is dropped into several steps.

The first step would be to research end-users and identify challenges. Here the team nails down real end-users’ problems, learns project stakeholders, sets objectives and learn opportunities. Experts use different methods like swot analysis, business cases, benchmarking and market analysis, canvas. Many teams use root-cause analysis techniques like 5 WHY or fishbone diagram. 

User stories are great to describe product functionality, how users reach the product, where they find it and how they use it. Each user story is a bridge between business and solution requirements. The base of a user story is to:

• Define end-users
• Specify their needs
• Explain the benefits
• Add acceptance criteria

Acceptance criteria is a mandatory part in drawing project requirements. AC translates user needs and client’s non-specific wishes over what the app should do into clear, technically right, understandable by engineers requirements: As a <user role> , I want <goal>, so that <benefit> .

Use case technique is also used as a part of user research, but use cases are more specific as they show how users interact with the system when it is already at his disposal and what way users choose to attain this or that goal. Use cases work well when you want to have a detailed view over usage of the app and if requirements need better investigation to make the app as much convenient for end-users as possible. This is how Roman Pichler explains on user research methods:

You can also use stories to capture non-functional aspects of a product, such as performance, robustness, and interoperability. But when it comes to the user interface and user interaction, user stories are less suitable. Sketches and mock-ups are better at describing the UI design. And scenarios, workflow diagrams, storyboards, and story maps are better suited to capture user interactions that comprise several steps

Roman Pichler

Coming back to your discovery team, they will suggest to improve or add some features if necessary. Then technical lead will define the best tech stack for desired functionality. Thus, both parties can proceed to setting priorities for tasks and developing a project scope. Every change in the solution is discussed with a customer to ensure everybody is on the same page. That’s why there is justified necessity of customers to be involved in the discovery of their app.  Clients should understand that the data they provide should be consistent and clear. It makes no good to keep silent during discussions thinking the team will certainly understand what I mean. Be concise in your demands and open with your questions. 

After, the team and customers work on the project roadmap, which is a compiled document of the project strategic plan: objectives, milestones, deliverables, resources, and timeframes. Final steps are filling the road map with estimations, technical specifications and design sketches.

What tools do companies use for analysis of software development project?

Business analysts apply various approaches and use various handful tools to evaluate the data. Experts’ use the following tools and methodologies for product discovery which is partly a business analysis of the future software:

• Roles & Permissions Matrix, RACI Matrix, Personas for Roles evaluation;
• Scope Modeling and Root Cause Analysis;
• Use Cases (how users interact with the developed software), User Stories (how functionality works to satisfy the end user);
• Functional Decomposition and Prototyping for System Capabilities;
• Data Dictionary, Data Flow Diagrams for gathering information and data structuring;
• Interface Analysis (how software components interact to make interface and system 100% effective);
• Feasibility Analysis (how practical the solution is);
• SWOT Analysis.

The RACI matrix is widely used is software development. It is responsibility allocation map for key activities and decisions which helps to delegate tasks effectively and clearly direct each team member into his or her role in the project.

Types of requirements for software projects. How are requirements set in software development projects?

Modeling of requirements during software product Discovery Phase can include texting, diagrams, descriptions, matrix and other scope modeling methods for systematizing information of:

• Functional/Non functional – subtypes of solution requirements
• Stakeholder requirements
• Business requirements

Business requirements define goals, objectives, and outcomes that are to be achieved for an enterprise or organization in a whole. This can be measured with the help of the SMART system.

Stakeholder analysis describes specific needs of a stakeholder or group of stakeholders, how they will accord with the solution.

Solution requirements include functional requirements which describe the functionality, workflow, performance and logic of the system operations. Non-functional requirements describe “Quality Attributes” of the system and conditions under which the system stays efficient, fast, secure etc.

Transition requirements describe capabilities of the solution needed during transforming the current state of the product to a new one. Data conversion, business continuity can relate to this category of requirements.

Product owners receive a consistent picture of the software project plan

Discovery phase in software project assures high market demand of the product. It guides the team to successful creation of UI/UX, system functionality, architecture and more. Mobile, cloud, progressive web applications thrive tremendously in the Apple Store and Google Play because their product owners have done a huge work on identifying problem area. 

At the end of Discovery stakeholders understand the needs of end users, receive documents with improved requirements, estimation of time and money to be invested in the project development. Matrices, data analytics tools, prototyping, scope modeling and other techniques helps companies present the product owner with the following deliverables of Discovery process:

• Assessed and approved project idea;
• Clearly identified pain-points of end-users and known risks;
• Clarified, negotiated and validated functional, nonfunctional and software requirement;
• Estimated costs and time frames of the project implementation;
• Compiled Documentation highlighting key statements and requirements (Solution Scope, Vision Scope, Software Requirements Specification, Wireframes, Metrics, Business requirement document).

Summarizing benefits of Discovery Phase in software projects

During Discovery software development company assists product owners in making better decisions. The process is critically helpful for product owners because it:

• makes the collaboration with a dedicated team of developers long-term and trusting;
• creates a consistent picture of a software solution;
• offers proficient support of an expert team in idea evaluation and improvement;
• provides all clarified requirements and ensures the relevance of solution for its end-users’;
• ensures technically successful decisions and compiled matrices for measuring business value;
• makes the software solution elegant, compatible with business needs and worthy of investments for the specific field.

So, does Discovery help to build successful software products? Yes, it does. More than both parties win – customer gets a market-ready, fully-functional application, while the team keeps motivated and interested knowing they are building the product users will love.

Interested in the software product discovery phase? Contact us to receive a consultation now. Learn all details to confidently start a project.