The most expensive software to build is software that solves the wrong problem. A feature built according to unclear requirements often requires substantial rework once stakeholders see the implementation and realize it does not match their expectations. Good discovery — understanding the problem, constraints, stakeholders, workflows, and risks before writing code — prevents avoidable rework and delivers better outcomes faster.
Unclear requirements create expensive rework
Starting implementation without clear requirements leads to predictable problems:
- Scope creep: new requirements emerge mid-implementation because stakeholders did not articulate their full needs upfront.
- Misaligned expectations: the delivered feature works correctly but solves a different problem than stakeholders expected.
- Missing edge cases: the happy path works but error scenarios, invalid inputs, or unusual workflows were not considered.
- Integration surprises: dependencies on other systems, data sources, or teams were not identified early.
- Performance issues: scale, latency, or throughput requirements were not defined, and the implementation cannot handle real-world load.
Discovering these issues after implementation is far more expensive than identifying them during discovery.
Assumptions are invisible requirements
Teams often make implicit assumptions about how a system should behave without verifying them with stakeholders.
Developer assumptions
Developers may assume they understand business rules, user workflows, or data structures without asking. These assumptions become embedded in the code and are difficult to change later.
Stakeholder assumptions
Stakeholders may assume developers understand the domain context, business constraints, or user needs without explaining them. They may also assume certain behaviours are "obvious" when they are not.
Surfacing assumptions early
Good discovery makes assumptions explicit by asking questions like:
- What happens when this field is empty?
- Who can access this feature?
- What is the expected volume of data?
- How does this integrate with the existing workflow?
- What are the business rules for edge cases?
Conflicting stakeholder expectations
Different stakeholders often have different priorities, and these conflicts do not surface until someone builds a feature that satisfies one group but frustrates another.
Identifying conflicts early
Discovery should involve all relevant stakeholders early to surface conflicting requirements:
- Sales teams may prioritize flashy features that attract new customers.
- Support teams may prioritize reliability, observability, and error messaging.
- Operations teams may prioritize deployment simplicity and monitoring.
- End users may prioritize usability and performance.
When conflicts arise, the team can make informed tradeoff decisions before implementation rather than discovering incompatible expectations later.
Hidden dependencies and constraints
Features rarely exist in isolation. They depend on other systems, data sources, APIs, teams, and infrastructure.
Technical dependencies
- Does the feature require data from another system?
- What APIs or services must be available?
- Are there rate limits, quotas, or performance constraints?
- Does the feature require schema changes or migrations?
Organizational dependencies
- Do other teams need to approve or coordinate changes?
- Are there shared resources, environments, or deployment windows?
- Do regulatory, compliance, or legal requirements apply?
Data dependencies
- Where does the required data come from?
- Is the data clean, consistent, and up-to-date?
- Who owns the data and what are the access controls?
Discovering dependencies early prevents blocked work, emergency escalations, and delayed launches.
Technical constraints inform architecture
Discovering technical constraints before implementation prevents costly rework.
Performance and scale
- How many users will use this feature?
- What is the expected data volume?
- What latency is acceptable?
- What happens under peak load?
Availability and reliability
- What uptime is required?
- What happens if a dependency fails?
- How quickly must the system recover?
Security and compliance
- What data classification and access controls apply?
- Are there audit, logging, or retention requirements?
- Do regulatory standards apply?
These constraints shape architecture decisions. Discovering them mid-implementation often requires refactoring or redesign.
Defining the actual problem
Good discovery starts by understanding the problem before proposing solutions.
Start with the problem, not the solution
Stakeholders often describe desired features rather than underlying problems. A request for "a dashboard with real-time analytics" may actually be solving a problem like "we cannot identify failing transactions quickly enough to prevent customer complaints."
Understanding the core problem allows the team to propose better solutions and avoid overbuilding.
Useful discovery questions
- What problem are we trying to solve?
- Who experiences this problem?
- How do they work around it today?
- What would success look like?
- What constraints exist?
- What are the risks if this is not solved?
Validating workflows and user needs
Features must fit into real user workflows, not idealized ones.
Observe existing processes
Understanding how users currently accomplish a task reveals unstated requirements, workarounds, and integration points. A feature that looks elegant in a design document may be unusable if it does not fit the actual workflow.
Identify pain points
Discovery should surface the most significant user friction points. Solving high-impact problems first delivers more value than building features users do not need.
Validate assumptions early
Mockups, wireframes, or prototypes can validate user experience decisions before writing production code. It is cheaper to revise a design than to refactor a complete implementation.
Identifying risks early
Discovery should identify technical, operational, and business risks before they become blockers.
Technical risks
- Are there unproven technologies or unfamiliar domains?
- What are the hardest parts of the implementation?
- What could cause the project to fail?
Operational risks
- Can the team operate and maintain this feature?
- What are the deployment risks?
- What happens if the feature breaks in production?
Business risks
- What if user adoption is lower than expected?
- What are the competitive or regulatory risks?
- What is the cost of delaying or not delivering?
Identifying risks early allows the team to mitigate them through architecture choices, prototyping, or phased delivery.
Discovery is not waterfall
Good discovery does not mean spending weeks writing lengthy requirements documents before any code is written. Discovery should be lightweight, collaborative, and sufficient to reduce major risks.
Just enough discovery
- For a small, well-understood feature, discovery may take a few hours.
- For a large, complex project, discovery may take days or weeks.
- For prototypes or experiments, discovery may focus on validating assumptions rather than defining complete requirements.
Iterative discovery
Discovery does not end when implementation begins. Teams should revisit requirements as they learn more, encounter unexpected constraints, or receive user feedback. The goal is to reduce avoidable rework, not eliminate all uncertainty.
A practical discovery checklist
Before starting implementation, ensure the team can answer:
- What problem are we solving? Define the core business or user need.
- Who are the stakeholders? Identify everyone affected by the feature.
- What are the functional requirements? List what the feature must do.
- What are the non-functional requirements? Define performance, security, and reliability expectations.
- What are the edge cases? Identify error conditions, invalid inputs, and boundary scenarios.
- What are the dependencies? List systems, data, APIs, and teams the feature depends on.
- What are the constraints? Identify technical, organizational, regulatory, and budget limits.
- What are the risks? Surface technical, operational, and business risks.
- How will we know it works? Define acceptance criteria and success metrics.
- What is the smallest useful version? Identify a minimum viable feature that delivers value.
The goal is to build the right thing
Good code cannot fix a poorly understood problem. Discovery ensures the team builds software that solves real needs, fits actual workflows, and meets stakeholder expectations. The time invested in understanding requirements, validating assumptions, and identifying risks pays for itself many times over by preventing avoidable rework. For guidance on documenting discovery outcomes, see How to Write a Project Brief.
Published by the DSSS Engineering Team. For corrections or topic requests, use the contact page.