Discovery

“A problem defined is a problem half solved”
— Albert Einstein

The goal of the Discovery Phase is to set the product development on course to success by defining project goals, objectives, and stakeholders’ expectations.

Why is this phase important?

Information gathered during this phase impacts product design, architecture, and development & management style. It helps in acquiring realistic project costs from potential technology providers. This phase is required before making any cost forecasts.

A series of 2-3 meetings (at least one in person) with key project stakeholders, focused on building a high-level 360° view of the project context. This usually takes a few days to complete, depending on project scope and domain complexity.

Results

The gathered information is documented in the form of a short high-level specification of the product. After this step, you will receive a document called Project Brief with:

Project stakeholders
High-level business goals
Product/system actors description
System boundaries and responsibilities
Risk factors
Project size assessment (cost category)
Crew composition models for various scenarios

Recommended Next Steps

Start Product Design - conduct detailed system analysis and design to make the estimation more accurate
Start the Product Development in parallel with the Product Design phase
Do a POC first to see if the risky areas are a threat
Limit the scope of the product to adjust the cost to meet budget expectations

Design

Purpose The goal of the design phase is to create a specification, a blueprint for the product so the development team has clear guidelines for the product’s look and behavior.

Results At the completion of the design phase, you will receive a document with:

User stories
User flows and key business processes
Low-fi UI design / UI wireframes
System architecture (physical/logical/technologies)
Risk analysis
Roadmap with MVP and milestones set
Cost estimation on user stories level
Project costs forecasts
Development team composition proposal

Form

Series of interviews and refinements organized in weekly sprints, engaging people with the most knowledge about the product domain. The agenda usually covers story mapping, live UI/UX wireframe design, problem-solving discussions, and client tech department consultations.

Benefits

Saves time during development by providing detailed guidelines about functionalities, interface, and architecture
More accurate cost estimation
Provides a framework for monitoring system costs in the form of a project roadmap

How Does it Work?

We establish your specification goals, which may include:

Realistic project planning (creating an initial project roadmap)
Resource allocation
Realistic cost planning and future tracking
Early risk identification and elimination

The scope of our effort for each stage is negotiable, depending on the materials and information you can provide upfront and the expected level of details we agree on. The design process is non-linear, following the discovery path orchestrated by experienced analysts, and generally consists of the stages and logic described below.

Kickoff

The process starts with a kickoff meeting where we:

Establish, discuss, and confirm specification goals and purpose
Introduce our crew that will participate in the specification development
Define the level of detail for the specification (e.g., depth of use case/user stories description, UI/UX wireframes detail level)
Appoint a Product Owner - a member of your team representing users’ interests
Orchestrate a discussion about available resources (documentation, systems, briefs, points of contact)
Plan the results and scope for the first sprint and checkpoints

After the kickoff, we continue with analysis within the agreed scope and boundaries.

Background Assessment

Our first task is to assess what is already known by you and your team and what elements must be created in the process. We analyze provided materials in detail, which may include:

Requirements lists
UI/UX designs
Briefs
Legacy applications
Reference systems, etc.
Specifications

The goal is to assess what information we can incorporate into the final specification document. We explain what artifacts should be developed to reach specification DoD. This stage usually takes 1 to 3 days to complete.

Result

You receive a specification backlog - the initial scope of our analytical and design work.

Analysis (User Story Mapping)

This aspect of the design process typically starts with a requirements list, project brief, Product Owner review, or workshops. We use an analysis method based on actors, processes, views, and business entities, which produces a list of requirements in the form of User Stories. One technique we use to define user-facing aspects of the system is User Story Mapping.

Example User Story

“As an operator (actor) I can conclude an auction (process) in the auction administration panel (view) so that all bids (entity) are closed with either won or lost status.”

Results

Artifacts created at this stage include:

Description of actors and responsibilities
Documentation of all identified User Stories (US) in the form of an initial Product Backlog
Documentation of mapped processes
Data flows (sequence diagrams)
Algorithms (block diagrams)
APIs Specification (optional)
Business entities list (optional)

Duration

This stage may involve multiple sprints (weeks) and online or stationary workshops, mixed with documentation and synthesis of collected information.

UI/UX Analysis and Design

Purpose

UI design has several goals:

Save time and enable communication between the Product Owner and the development crew
Test ideas and concepts before they are coded
Test user stories by simulating user behavior
Enable more accurate estimation as the dev crew can estimate based on groups of functionalities and views

Form

This stage takes the form of interactive workshops focused on providing simplified views called Wireframes and visualizing processes like a user journey from each actor’s perspective.

Results

System Wireframes provided in AdobeXD or Figma
User Flow diagrams provided in Miro

Duration

The duration depends on the number of system views and their complexity discovered during requirements analysis. Sometimes it is possible to estimate the rough number of views and complexity during the assessment stage.

Architecture Blueprint

The architecture part of the specification explains how the system will be implemented. It includes:

Selected/recommended technology stack: provisioning, languages, libraries, and frameworks
Description of logical system components (e.g., databases, message queues, mailing services, logging infrastructure, authentication components)
Diagram of logical architecture in C4 model
Physical architecture - specification of the physical components on which the logical architecture will be implemented (e.g., on-premise, cloud components, etc.)

Note: The architecture blueprint is not a complete architecture specification; it contains only coarse guidelines necessary for the development crew to assess the complexity and time effort of development.

Security Aspects

Teonite security standards are described in the following document:
Teonite - Security Standards

Risk Analysis

Risk analysis aspects are presented throughout the entire cycle of building solutions. Our focus is mainly on technological risks that are ever-present in deep tech projects. Risks are identified and collected during:

Requirements specification
Roadmap planning
Architecture design

Risk Areas

We focus on identifying risks in the following areas:

Technology feasibility
Performance & SLA
Business - project timeline & budget, third parties involvement
Legal & regulatory
Security

All identified risks are documented and discussed with stakeholders. We make recommendations on mitigating and minimizing risks or designing system elements that increase resilience toward risk.

Roadmap Planning

Planning is possible after previous stages have been completed (or at least are in an advanced stage). During planning, we do the following:

Estimation of defined User Stories, UI, and processes
Identify main chunks of work (Epics forming)
Propose a development crew composition
Propose the order of implementation, including milestones set in time

Notes

The roadmap is the first step toward project kickoff, so it’s optimal to prepare it in project management software like Jira, which allows for easy breakdown of large (Epic stories) chunks of work into smaller User Stories and visualizing them on a Gantt chart (The Roadmap).

Project Budget Forecasting

Having completed all stages of the Specification and Design process, we provide forecasts of potential project costs in the form of a Work Breakdown Structure (WBS). This forecast is unique because it is based on:

Our crew’s compounded experience

The empirical velocity measured during other projects

The full-stack development approach

Our estimations consider the Definition of Done (DoD), which defines what it means for the work to be completed. Each project has its own individual DoD, both on the User Story level and on the Sprint level.

Our estimations also include elements of the Scrum process, which we mostly use as a development framework: sprint planning, review meetings, backlog grooming meetings, and retrospectives.

Note

Complex projects cannot be planned with 100% accuracy. Unexpected obstacles, external provider delays, human factors, and changing requirements should be assumed. The budget should allow compensation for these factors. Additionally, time and complexity estimates are unique to our crew. Other companies and teams might use different techniques for estimating.

Appendix

Specification DoD and Acceptance Criteria

The specification is a contract between the Product Owner and the development team and must be clear and readable for both parties.
One goal of the specification is to allow the team to estimate (at a high level) the amount of effort required to deliver the system.
Requirement documentation should be written in the form of User Stories (so that it’s convertible into a Product Backlog) and meet quality standards like INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
The specification contains an architecture description enabling developers to assess the work effort and time necessary to code stories.

Story Definition of Done (DoD)

Publicly available on Teonite standards - Definition of Done.

Reference Projects and Case Studies

Designing the specification for home.pl MFA application
Designing Product Management system and Offers Management system for international eCommerce holding
Creating Wireframes, User Flows, and requirements for a dietary planning solution
Designing user models (roles and responsibilities), User Flows, and UI/UX for the widestreet NPL/UTP loan portfolio trading system