Begin with a decision, not a feature list
A digital product idea often arrives already shaped as a solution: a client portal, mobile application, new platform or automation. The suggestion may be sound, but it does not yet explain why the investment is worthwhile. The first question is what fails today and which change would create real value for users or operations. The issue might be a slow process, frequent corrections, inaccessible information or an inability to offer a new service. If these situations are compressed into a vague objective, a team can build a technically competent product that misses the important problem.
Before development, state the decision the project needs to support. For example: “Should we invest in a client portal because the current manual process delays service and increases corrections?” That sentence contains a problem, a hypothesis and a possible measure. The answer need not be yes. An initial investigation may reasonably recommend a process change or an integration with an existing tool. The UK Government Service Manual describes discovery as a way to understand the problem and constraints before committing to build a service. Its context is government, but the discipline is useful in commercial work too.
Understand the complete user journey
The user is not only the person clicking through the final interface. Support staff, analysts, administrators and partners may need to correct an exception or interpret an outcome. Map the journey from the first request to the actual result, including steps outside the digital interface. Conversations with several roles often uncover informal spreadsheets, repeated data entry and decisions that nobody formally owns. These may matter more than a proposed list of components for a new page.
As you map the journey, include the moments when a client supplies incomplete information, a worker lacks permission, a third-party system fails to respond or a transaction must be reversed. Ask who notices the problem now and how they repair it. Record accessibility and language needs in the real setting where the service will be used. The output should be a clear map of steps and unresolved questions, not an enormous diagram produced for a presentation. Its purpose is to help choose a first version that can actually be assessed.
Measure the starting point
Without a baseline, improvement easily becomes an impression rather than evidence. Choose a few measures for each important problem: time from request to completion, proportion of manual corrections, number of unclear states, cost per case or requests that require support. Perfect analytics are not necessary. Even a manually collected sample with a stated method is better than an unsupported estimate. Record what is being measured and how the data will be collected after the change is introduced.
Metrics must not obscure the outcome. A faster form is not better if it produces more incorrect data. Fewer clicks may not shorten the complete service if later verification becomes slower. Watch for work transferred to another team as well as the quality of the final result. If a valuable change cannot yet be measured, label it as a hypothesis and design a small experiment that could provide evidence. That is more honest than promising a percentage improvement before the project begins.
Decide what to buy, connect and build
Custom development gives control over product behaviour, but it creates a continuing responsibility for security, change and operations. An existing product can shorten time to launch, yet restrict a critical workflow or access to data. Integration keeps familiar systems, while adding dependency on their interfaces and availability. Consider these options for each capability rather than making one decision for the entire project. A company might buy routine billing, build the distinctive client experience and connect the two through a documented contract.
Compare time to first value, the cost of future changes, data export, supplier dependency and operating effort. Account for licence and contractual limits without assuming that every component has to be owned. The boundary between components should be understandable to whoever will maintain the product two years later. If an option is attractive only because an external API is assumed to behave in a particular way, test that assumption with a small integration exercise before committing to a large implementation.
Establish data ownership and quality
Every important field needs a source of truth. Who creates a customer, who can correct an address, where does a payment status originate and which changes propagate elsewhere? When the same information exists in several systems, define update order, conflict rules and a repair process. Otherwise a new product may simply display old discrepancies in a more polished interface. Inspect format, completeness and age of data before fixing a migration date.
For sensitive data, consider who may read it, why they need it and how long it should be retained. Do not copy personal information into logs or analytics merely because that is technically convenient. Legal obligations depend on actual processing and jurisdiction and require separate review. An engineering team can nevertheless produce a precise inventory of data flows and access roles so that the review uses facts. Without that inventory it is difficult to design a secure integration or a meaningful recovery plan.
Work through failure and operations
Architecture is revealed by what happens outside ideal conditions. Explore timeouts, duplicate requests, unavailable services and partially completed steps. A payment operation can have an unknown outcome; retrying without checking must not create another transaction. A data feed can be temporarily behind; users need to understand the age of what they see. These scenarios need answers in the design, tests and operational procedures, not merely a note in a risk register.
Agree on ownership after launch as well. Who watches errors, who can roll back a change, who restores a backup and how are users informed about an incident? The Google Cloud Well-Architected Framework treats reliability, security, operations and cost as parts of system design. For a small product this need not mean elaborate infrastructure. It means proportionate procedures and measurements for the things that are critical to that particular service.
Address security and accessibility early
Frame security requirements as situations the system must handle. Who signs in, who may approve a change, what is recorded when a request fails and how is administration protected? OWASP ASVS provides an open set of verifiable controls for web applications. A small application does not automatically need every control at the highest level. The framework helps teams remember authentication, authorization, input validation and secure configuration, then choose a level appropriate to the risk.
Accessibility belongs in the same early discussion. Retrofitting forms, navigation and error messages is often harder than designing them properly from the start. Check whether the essential journey works with a keyboard and on a mobile screen, whether text is readable and whether people understand how to correct mistakes. These are not decorative concerns: they determine who can use the service. Test the full journey rather than relying on a screenshot or a single automated score.
Choose a small proof instead of a large promise
The first implementation step should test the riskiest assumption. If uncertainty concerns user demand, a prototype and interviews may help. If an integration is the concern, test the real API, timeout behaviour and data quality. If performance is unclear, measure the critical operation with representative data. An MVP is not an arbitrarily shortened feature list. It is the smallest coherent result from which the next decision can be made.
Before each experiment, write down what will be observed and which outcome would change the plan. Without this boundary, any result can be described as a success afterward. A positive result may justify further investment; a negative one can show what to change or stop. Both have value. A short record is enough: assumption, method, data, observation and decision. This discipline protects the budget better than detailed scheduling of untested assumptions.
Estimate with named uncertainty
A time and cost estimate helps only when its basis is visible. Separate confirmed requirements from assumptions that could materially change scope. Integrations, data migration, legal review and dependencies on another team often have conditions a supplier cannot control alone. For these areas, a range and a plan to reduce uncertainty are more credible than one precise number. The estimate can become narrower after discovery, and everyone should understand why it changed.
Decision rights matter just as much. Who accepts the outcome, provides test data, approves a priority change and responds if an external system is not ready? Not every unknown needs a lengthy contractual appendix. Client and supplier do need a shared view of risks and the next step. A compact responsibility map reduces coordination costs during development and makes the eventual handover easier.
What should exist before the first sprint
At the end of the initial work, assemble a concise set of useful artefacts: a problem statement, user and process map, baseline measures, data and integration inventory, major risks, the buy-versus-build boundary, the first stage goal and the owner of each important decision. Every artefact should answer a question. A document with no practical use adds little confidence. The team should be able to explain why the first feature or experiment was chosen.
Missing answers are not a failure of discovery. Pretending they are known is. Mark the open questions, assign someone to investigate them and choose the smallest safe next step. Sometimes the evidence will support building custom software. Sometimes a process change or integration will be enough. A strong beginning gives both outcomes a fair chance and leaves a rationale that can be revisited later.