Custom software discovery is a decision-making exercise, not a pre-project theatre. Its purpose is to reduce the expensive uncertainty that remains after a team says it wants a new application. IT managers need enough evidence to decide whether to change a process, configure an existing product, integrate systems, or build a constrained service. Start by selecting one business outcome that can be observed: reduce an approval backlog, prevent duplicate entry, shorten the time to quote, or make a regulatory decision explainable. Then follow a real case from trigger to completion. The gaps between stated process and actual behavior are the material of discovery. They reveal the hidden spreadsheets, exceptions, data corrections, and informal permissions that a feature list cannot describe.
Key takeaways
- Frame discovery around a measurable business outcome and a representative case.
- Identify system authority, data ownership, user roles, exceptions, and recovery before estimating features.
- Use working artifacts such as state maps, sample records, and contract sketches to expose ambiguity.
- Treat security, accessibility, support, and observability as scope, not late review topics.
- End discovery with decisions and testable assumptions, not a decorative requirements document.
Establish the discovery boundary
A boundary has a trigger, an outcome, named actors, and a small number of systems. For example, a request arrives from a client portal, an operations specialist validates it, a manager approves an exception, and the customer receives a status update. Write that sequence in plain language before discussing services or screens. Ask which record is authoritative at each point, what makes the work invalid, and how a person corrects a mistake. Discovery becomes productive when participants can disagree about a concrete case instead of trading abstract preferences. It also protects the team from accidentally turning a narrow operational need into a broad platform replacement. Leave adjacent workflows visible but out of scope unless they are required for the chosen case to complete safely.
| Discovery question | Evidence to collect | Decision unlocked |
|---|---|---|
| What starts work? | Representative inputs, source, frequency | Where intake validation belongs |
| Who owns truth? | Record owner, identifiers, update rules | Integration and reconciliation approach |
| What varies? | Normal, exception, and failure examples | State model and scope boundary |
| What proves success? | Baseline time, error, or quality measure | Release metric and review cadence |
Observe the work, not the aspiration
Interviews are useful, but observation is where a discovery team sees compensating behavior. Sit with people as they reconcile records, seek approval, or recover from a failed integration. Capture the handoffs, not just the clicks. A specialist may use a private note because the current record cannot express uncertainty; a manager may export a spreadsheet because the report does not identify stale data. These are design signals, not user mistakes. Collect anonymized examples and ask participants to narrate the decision they made, the evidence they trusted, and the moment they knew they were done. The resulting workflow map should show waiting, rework, escalation, cancellation, and correction. A happy path alone cannot support a credible delivery estimate.
Turn assumptions into testable artifacts
Convert important assumptions into artifacts that an engineer, process owner, and support lead can inspect. A state-transition table clarifies when a request may be approved or returned. A data dictionary gives fields a stable meaning. A small API sketch can make identity, pagination, error responses, and idempotency tangible before code is written; the OpenAPI Specification is a useful reference. A clickable prototype may test comprehension, but it cannot prove that permissions, source authority, or retries will work. Keep an assumption register with an owner and a planned test. The point is not exhaustive documentation. It is to stop uncertain choices from being smuggled into development as if they were settled facts.
| Artifact | Question it answers | Review partner |
|---|---|---|
| State map | Which transitions are allowed and reversible? | Process owner |
| Data dictionary | What does each value mean and where does it originate? | Data owner |
| Contract sketch | How do systems request, fail, retry, and evolve? | Integration owner |
| Risk register | What could harm users or delivery, and who reduces it? | Delivery sponsor |
Plan quality and security early
Quality planning belongs in discovery because it changes design choices. Ask how many users act at once, how quickly a result is needed, which information is sensitive, which regions or devices matter, and how long an audit must remain available. Define authorization as an action on an object in a context rather than a generic role label. Use the OWASP Application Security Verification Standard to turn concerns such as access control, logging, and input validation into reviewable requirements. Include accessible interaction requirements when the workflow involves dense forms, status changes, or timed work. These questions are not a compliance appendix; they identify the construction and test work needed to make a first release dependable.
Make operability part of scope
Every proposed service needs an answer to: who sees a failure, who can investigate it, and who can restore a stalled case? Discover the operational signals together with the business flow. Stable identifiers should connect a user-visible item to integration calls and logs. The OpenTelemetry Specification helps teams use compatible traces, metrics, and logs without inventing unrelated conventions. Define the support route for bad data, unavailable dependencies, duplicate messages, and mistaken decisions. If the team cannot describe recovery during discovery, it is likely to discover the issue in production when the affected person is waiting. Operational ownership is a feature of the planned system, even when it does not appear in the navigation.
Use a discovery readout that supports a decision
Run the readout as a working decision session, not a presentation. Give participants the representative case, the unanswered assumptions, and the trade-offs before the meeting so time can be spent challenging evidence. Invite the process owner, technical owner, security or data representative where relevant, and the sponsor who can make a scope choice. Walk from the intended outcome through the observed workflow and stop at each uncertainty: does the policy really work that way, is this system genuinely authoritative, can the integration provide the needed event, and who would recover a failed case? Record decisions, owners, and dates in the room. When a question cannot be answered, label it as a risk with a validation action rather than smoothing it over with optimistic wording. The readout is successful when everyone can explain the first release boundary and the reason it is a responsible next step.
| Readout topic | Question a sponsor should answer | Evidence included |
|---|---|---|
| Outcome | What measurable problem is worth solving now? | Baseline, affected group, and consequence of inaction |
| Boundary | Which workflow starts and ends inside this investment? | Plain-language case map with explicit exclusions |
| Actors | Who performs, approves, supports, and receives the work? | Role scenarios from observed sessions |
| Authority | Which records and policies control each material decision? | System owners, stable identifiers, and conflict rules |
| Exception load | Where does normal work most often break down? | Examples of missing data, reversals, and escalations |
| Integration | What must another system provide or accept? | Contract sketch, ownership, timing, and failure expectations |
| Quality | Which security, accessibility, or reliability failures are unacceptable? | Ranked risks with planned verification evidence |
| Operations | Who will see a stalled item and restore service? | Telemetry needs, runbook owner, and support handoff |
| Scope | What will the first vertical slice deliberately omit? | List of deferred capabilities and rationale |
| Assumptions | Which choices remain unproven but consequential? | Owner, validation method, and decision date |
| Cost shape | What work drives delivery effort and uncertainty? | Dependencies, environments, data migration, and test needs |
| Recommendation | What decision is requested from the sponsor? | Options, trade-offs, preferred path, and next checkpoint |
Close with a decision-ready brief
A strong discovery conclusion records what was learned, what remains uncertain, and what the sponsor must choose. It should name the bounded outcome, users and roles, trusted systems, major interfaces, nonfunctional requirements, delivery risks, and first-release acceptance evidence. It should also state what will not be built yet. Use a thin vertical slice to test the most consequential assumptions end to end, then decide what expands next. NIST SSDF offers a useful reminder to plan secure development and verification activities alongside features. Judge discovery by whether it lets a team make a responsible commitment, not by how many slides it produces.
Frequently asked questions
How long should custom software discovery take?
It should take long enough to examine representative work, test the riskiest assumptions, and make a scoped decision. Duration follows uncertainty, not a fixed workshop count. A regulated integration or unclear data owner often deserves more investigation than a well-understood replacement of a manual step.
Is a requirements list enough to begin development?
No. A list rarely explains authority, exceptions, performance expectations, recovery, or acceptance evidence. Pair user needs with state behavior, sample data, role rules, contracts, and measurable outcomes. Those materials give development and testing teams something they can challenge and verify.
Conclusion
Custom software discovery creates a shared, testable understanding of a bounded change. Observe the actual work, expose decisions and risks, and leave with evidence that supports a real delivery choice. That is how a project begins with useful constraints instead of a hopeful pile of features.