Key Takeaways
- Customer needs should define the decision, delivery deadline, and evidence required from a service.
- Product validation must test measurement accuracy, workflow fit, and the cost of incorrect results.
- Commercial readiness requires a buyer, an operating budget, reliable delivery, and ongoing support.
Earth Observation Product Development Begins With a Decision
The European Space Agency’s completed Live Land feasibility study engaged transport infrastructure users in the United Kingdom, Norway, and the Czech Republic to define requirements for landslide and subsidence services. Its proposed system combined satellite observations with ground measurements and communications. The development question concerned how infrastructure organizations could prioritize maintenance and manage geological hazards, with technical and economic feasibility assessed together. (business.esa.int)
That sequence provides a practical starting point for Earth observation product development. Earth observation means collecting information about the planet through instruments on satellites or other platforms. A customer need gives those measurements a specific purpose: supporting a decision made by an identified organization within a defined period.
A useful development process starts by documenting that decision before selecting imagery or designing an interface. The record should identify who acts, what information is currently available, and what prevents an adequate response. It should also establish the consequence of receiving information too late or accepting an incorrect result.
The distinction between a measurement and a decision matters throughout development. Satellite data may establish that a surface changed, but the customer may need to determine whether an inspection is justified. Translating between those tasks requires knowledge of the asset and the customer’s operating procedures. An accurate change map cannot, by itself, establish the appropriate response.
New Space Economy’s coverage of downstream market segments provides related context for the movement from observations to customer services. For product development, the useful unit of analysis is narrower than an industry category. It is a particular decision made repeatedly under identifiable constraints.
The initial deliverable should be a problem statement that the customer recognizes as an accurate account of its work. It should describe the existing process without assuming that satellite data will improve it. Development can then investigate whether better observations would change the decision enough to justify the cost.
A decision may remain unchanged even after measurement quality improves. Existing procedures may already provide sufficient information, or the organization may lack authority to act on the new result. Discovering either condition early prevents engineering effort from being committed to a benefit the customer cannot obtain.
Customer Discovery Separates Users, Buyers, and Beneficiaries
Customer discovery examines actual behavior and purchasing conditions. Interviews should concentrate on recent decisions, existing records, and the work required to assemble information. Expressions of interest are useful for arranging further investigation, but they do not establish demand.
A development team should ask participants to reconstruct a completed task. Relevant evidence includes the information available at the time and the sequence of approvals. The team can then identify where staff waited, repeated work, or proceeded without adequate evidence. Access to records allows those accounts to be checked against documented practice.
The person using a product may not control its purchase. A technical specialist can assess whether the information is credible, but a department manager may control the operating budget. Procurement staff determine how a purchase can proceed, and information security staff may determine whether the service can connect to organizational systems.
Beneficiaries can sit outside the purchasing organization. Public agencies may buy information to improve public services, with benefits distributed among residents or businesses. A commercial provider may buy data that becomes part of another service. The development plan needs to distinguish the organization paying from the people receiving the eventual benefit.
This distinction is relevant to emergency management user needs. An information requirement can be shared across organizations even when responsibility for purchasing, interpreting, and acting on that information is divided.
Discovery should include participants beyond an eniastic internal sponsor. Staff performing routine work can reveal practical barriers that senior managers overlook. Budget owners can explain whether a proposed purchase replaces existing expenditure or requires a new allocation. Both perspectives affect the product specification.
Customer selection also deserves explicit criteria. A development partner should have a relevant problem, access to usable evidence, and enough staff time to participate. A prestigious organization that cannot provide records or test outputs may contribute less to development than a smaller organization with a defined purchasing route.
The resulting evidence should distinguish confirmed needs from assumptions. Each assumption should have an owner and a planned test. If interviews reveal different decisions within the same market segment, the team should avoid treating those differences as requests for one increasingly complicated product.
Customer Requirements Must Become Measurable Specifications
A request for frequent, accurate information leaves too much room for interpretation. Earth observation product development requires a translation from customer language into measurable conditions. Those conditions should describe what the service must deliver and how acceptance will be judged.
Spatial resolution describes the ground detail represented by an observation. Temporal resolution describes how frequently observations are available. Latency is the delay between observation and delivery. These properties address different needs, and improving one does not guarantee that the others improve.
The specification should separate satellite acquisition opportunities from usable observations. An optical image can be scheduled or collected yet fail a customer’s requirements because of cloud cover. Delivery commitments should account for usable coverage across the customer’s actual operating area, rather than relying only on a satellite’s advertised revisit capability.
Observation time and decision time must also remain separate. A product delivered promptly may still describe conditions that are too old for the intended action. Acceptance testing should measure the age of the underlying observation when the customer receives the result, including delays introduced by processing and review.
Requirements should identify the smallest relevant feature and the geographic extent of the task. They should define what counts as a change and what evidence is needed before an alert appears. Where several measurements contribute to an output, the specification should state how differences in observation dates will be handled.
A requirements record should connect each specification to an operational reason. A demand for finer detail deserves examination if it substantially increases cost. The customer and provider can then determine whether that detail changes the decision or simply improves the appearance of a map.
New Space Economy’s discussion of Earth observation sensors supplies context for the measurement options available. Sensor selection should follow the required information, rather than determining the product before the customer’s task has been understood.
Acceptance criteria also need rules for incomplete information. The service should distinguish a confirmed observation from an estimate and an unavailable result. Treating missing data as evidence that nothing happened can create a misleading record. The customer should approve the wording and operational treatment of each state before implementation.
Data Selection Tests Whether the Service Is Feasible
The United States Geological Survey made archived Landsat products available for download at no cost in 2008. That open data policy provides an established starting point for assessing whether public observations can meet a product requirement. The absence of an imagery purchase price does not remove processing or service delivery costs.
A feasibility assessment should begin with the information needed, then examine available observations. It should assess archived coverage over the intended service area and the conditions under which observations become unusable. Historical availability can expose weaknesses that are not apparent from an instrument specification.
Optical imagery and radar observations measure different properties. The Copernicus Sentinel-1 mission uses radar that can acquire observations through cloud and without daylight. That capability addresses an important acquisition constraint, but it does not make radar a direct substitute for every optical measurement or interpretation.
Commercial observations should be evaluated against the same customer requirements as public data. Procurement may be justified by detail or acquisition control, but the comparison should include actual delivery conditions. New Space Economy’s satellite operator directory offers context for the different product types and supplier models.
A provider should test the complete path from acquisition to delivery before committing to a service. That includes acquiring permitted data and processing it into the proposed output. The assessment should record the staff effort required to correct failures or interpret uncertain results.
Ground information may be necessary to make satellite observations useful. Asset locations and boundaries can connect a measurement to the customer’s records. Local observations can support interpretation and validation. The development agreement should establish who supplies this information and whether it can be used throughout the commercial service.
Data rights need review at the same stage as technical feasibility. The intended product may involve storing imagery, sharing derived results, or providing access to subcontractors. Permission for one activity should not be assumed to cover another. Commercial terms need to match the product that will actually be sold.
The feasibility decision should include a stop condition. If observations cannot support the required timing or reliability, the team should revise the use case or end development. A narrower service with explicit limits is easier to assess than a broad promise whose exceptions appear only after purchase.
Prototypes Test the Complete Customer Task
A working analytical method is only part of a prototype. The prototype should allow a customer to complete the intended task, including interpreting uncertainty and recording a response. This can be tested before the provider builds a full production system.
The initial version can contain manually prepared outputs if the manual work is disclosed and measured. Such preparation can help test the usefulness of the result before automating every processing step. It should not create the impression that a labor-intensive demonstration already operates as a low-cost service.
Prototype testing should use customer records whenever permission and data quality allow. Staff should perform their normal task with the proposed output and explain what additional information they need. Observation of that work can reveal requirements that are difficult to identify through interviews alone.
Interface decisions should follow the workflow. A separate map portal may create an unnecessary step if staff already work in another system. A structured file or application programming interface, which allows software systems to exchange information, may be more appropriate. The relevant test is whether the output reaches the person making the decision in a usable form.
Information structure deserves as much attention as visual presentation. Results need consistent asset identifiers and clearly stated observation dates. Staff should be able to distinguish a new event from an updated interpretation of an existing event. Corrections should remain traceable rather than silently replacing earlier outputs.
Technical standards can reduce some integration work. The Open Geospatial Consortium’s SpatioTemporal Asset Catalog specifications organize descriptions of geospatial assets by location and time. They support data discovery and access, although they do not determine the customer’s decision rules or establish the quality of an analytical result.
Prototype feedback should be linked to observed task performance. A request for another display option may be less important than evidence that users misunderstand the age of an observation. The development team should record what happened during testing and change the design in response to that evidence.
The prototype should also test exceptions. Staff need to recognize when coverage is incomplete, when confidence is inadequate, and when specialist review is required. A service that explains its limits during normal use gives the customer a better basis for deciding how much responsibility to assign it.
Validation Connects Measurement Error to Decision Consequences
OpenET provides a documented example of validation against independent measurements. A 2024 study assessed its satellite-based evapotranspiration estimates against observations from 152 ground stations. Evapotranspiration is the movement of water from land and vegetation into the atmosphere, and the assessment examined how estimates could support water management.
The development lesson concerns the relationship between evidence and intended use. A product needs more than an overall accuracy score. Validation should establish where it performs adequately, where uncertainty increases, and whether those differences matter for the customer’s decision.
Testing should distinguish measurement accuracy from operational usefulness. A product can reproduce an environmental variable accurately yet arrive after the relevant decision. It can also achieve a favorable average result despite unacceptable performance in the locations that matter most to a customer.
Validation data should be independent of the information used to adjust the analytical method. Reusing the same observations for development and evaluation can overstate performance. Geographic separation and testing on later periods help examine whether a method works beyond the conditions used to build it.
Reference observations have limitations too. A ground measurement may describe a smaller area than a satellite pixel, or it may have been collected at a different time. Evaluation should document these differences before interpreting disagreement as an error in the satellite product.
Detection services require separate treatment of false alarms and missed events. A false alarm can consume staff time through unnecessary investigation. A missed event can leave the organization without information it expected to receive. The acceptable balance depends on the action attached to the alert and the consequences of each error.
Thresholds should be agreed with the customer before the pilot results are reviewed. Changing acceptance criteria after seeing performance weakens the test. Where different operating conditions require different thresholds, those conditions should be stated explicitly and evaluated separately.
The OpenET assessment also illustrates why published evidence should retain its scope. Results from an evaluated set of locations and applications should not be presented as proof of identical performance everywhere. Product documentation needs to identify the conditions that have been tested and the uses that remain outside the evidence.
A validation package should preserve the test data description and the method version. It should explain exclusions and include failure cases. Customers can then judge whether the evidence applies to their work, and future product changes can be compared against a reproducible baseline.
Pilots Must Establish Value and a Purchasing Route
A pilot should test an explicit commercial or operational proposition. Its scope needs an agreed service area and a defined period, with responsibilities assigned before work begins. The participants should know what evidence will support expansion, revision, or termination.
Evaluation should compare the proposed service with the customer’s existing process. That process supplies the baseline for judging improvement. Without a baseline, a pilot can establish that the product works technically without showing whether it changes the customer’s costs or decisions.
Useful measures depend on the task. They may include staff time required to review information or the interval between observation and a recorded response. Measures should be selected because they connect to the purchasing decision, rather than because the provider’s software can easily count them.
Activity and value need separate treatment. Logins establish that people accessed a system, but do not prove that the information improved their work. Download counts establish distribution, but do not establish use. A pilot should document what participants did with the output and whether that action differed from established practice.
Attributing financial benefits requires care. A change in operational results may reflect weather or staffing rather than the new service. The evaluation should separate measured outcomes from estimates and identify the assumptions behind any monetary calculation.
The purchasing route should be investigated before the pilot ends. The team needs to identify the budget owner and the applicable procurement process. A successful technical trial does not guarantee that funds are available or that the organization can purchase from the provider under the proposed terms.
Public funding and commercial demand also need separate records. A grant can finance development and reduce the customer’s cost of participation. It does not establish that the same customer will finance continuing operations. Renewal discussions should address the service price without assuming that development subsidies will continue.
Earth observation product development should include a written pilot decision. The customer’s assessment should state whether the agreed criteria were met and what remains unresolved. A purchase commitment carries different evidentiary weight from general support, and the provider should preserve that distinction in its own planning.
If the pilot produces no purchasing decision, the team should identify the reason. Weak measurement performance calls for a different response than an absent budget or an integration barrier. Repeating a pilot without resolving the cause can consume resources without reducing uncertainty.
Pricing and Service Design Must Reflect Delivery Costs
A price should correspond to something the customer can understand and budget for. The charging unit might be monitored area, a defined asset portfolio, or a period of access. The appropriate unit depends on how usage affects cost and how the customer receives value.
The provider should calculate the cost of delivering an accepted result. Imagery and computing are part of that calculation, but analyst review can be equally relevant. Customer onboarding and technical support also consume resources that a demonstration may conceal.
Commercial analysis should distinguish one-time work from recurring work. Connecting a customer’s asset records may require an initial implementation effort. Repeated manual correction indicates a continuing delivery cost. Combining both under a broad development budget can obscure whether the service can operate profitably.
Uncertain data availability can change economics. Additional acquisitions or reprocessing may be necessary to meet a delivery commitment. The provider should estimate costs under ordinary conditions and under periods of increased demand. A price based only on successful processing runs may omit the work required to recover from failure.
Service terms should match demonstrated capability. Availability of the software interface is different from availability of a new observation. A service can remain online even when no usable data have arrived. Contracts and product descriptions should state which condition each commitment addresses.
Support responsibilities need similar precision. The provider should identify how customers report problems and how corrected results are issued. It should define whether the service includes expert interpretation or only data delivery. Those choices affect staffing, liability discussions, and price.
New Space Economy’s coverage of the global Earth observation industry places these services within a broader supply chain. A product provider may depend on external satellite operators and processing infrastructure. Customer commitments need to account for the dependencies the provider cannot directly control.
Customization should be evaluated as a commercial choice. A customer-specific feature may justify a separate implementation fee, but extensive bespoke work can reduce the economics of a standardized subscription. Product managers should identify which requirements recur across customers and which create a separate service obligation.
Pricing tests should present concrete terms. The customer should understand the coverage and the limits attached to the offer. A willingness to discuss a product at an unspecified price provides less evidence than acceptance of a defined service within an identified budget.
Operational Ownership Continues After Deployment
The National Aeronautics and Space Administration’s Application Readiness Level framework uses nine stages to describe progression from an application concept toward operational use. Its readiness framework separates early feasibility from development and validation, then addresses integration into decision-making. This distinction helps explain why a completed prototype does not establish an operational service.
Deployment requires named responsibility for the product after development staff move to other work. Someone must monitor delivery, investigate failures, and communicate changes. The customer also needs an internal owner who maintains access and ensures that operating procedures remain aligned with the service.
Training should cover interpretation and exceptions. Users need to understand the difference between observation time and delivery time, as well as the meaning of confidence indicators. Staff turnover makes this a continuing obligation rather than a single launch activity.
Operational monitoring should include the full delivery chain. Successful processing does not prove that a customer received the output or that it matched the correct asset. Monitoring should check data freshness and completeness alongside system availability. Errors in customer records need a defined correction process.
Method changes require controlled introduction. A revised model may improve performance but also alter historical comparability. Customers should receive notice when a change affects interpretation, and the provider should retain enough information to reproduce previously delivered results.
Customer feedback should remain connected to actual decisions. Periodic reviews can examine ignored alerts and recurring support requests. That evidence can show whether the service is difficult to interpret or whether the original problem has changed. Feature requests should be assessed against those findings before entering the development schedule.
Research on water management technology transfer emphasizes relationships and institutional support alongside technical development. The practical implication is that continued use needs resources on both sides of the service relationship. A supplier cannot compensate indefinitely for the absence of a customer organization responsible for adoption.
Expansion should require new evidence. Performance in an established service area does not automatically establish performance in another climate or operating environment. The provider should reassess data availability and validation needs before extending coverage or adding a new decision type.
An exit plan also belongs in operational design. Customers should know what records they can retain and how exports will work if the service ends. Planning for withdrawal or supplier replacement makes continuity a concrete responsibility rather than an assumption.
Summary
Customer needs should remain traceable throughout Earth observation product development. Each important requirement should connect to a decision, each performance claim to evidence, and each service commitment to an operating capability. That record gives both customer and provider a basis for accepting the product and evaluating later changes.
Development also creates a decision about what should remain outside the product. Some interpretations may require a qualified specialist, and some operating conditions may remain unsupported. Defining those boundaries allows customers to assign responsibility accurately and prevents a validated measurement from being treated as authority for decisions it was never designed to make.
Appendix: Useful Books Available on Amazon
- The Mom Test
- Value Proposition Design
- Testing Business Ideas
- Continuous Discovery Habits
- Remote Sensing and Image Interpretation
Appendix: Top Questions Answered in This Article
What is customer need driven Earth observation product development?
Customer need driven Earth observation product development begins with a decision an organization needs to make. Developers identify the required information and its delivery conditions before selecting data or building software. The process then tests technical performance, operational usefulness, and the customer’s ability to purchase and maintain the service.
Why should development begin with a decision rather than a satellite?
A decision establishes what information matters and when it must arrive. Selecting a satellite beforehand can constrain the product around available measurements without establishing customer value. Starting with the decision also helps identify whether existing information already meets the need or whether satellite observations can improve it.
Who should participate in customer discovery?
Customer discovery should include people performing the work and people responsible for purchasing the service. Technical reviewers and operational managers contribute different evidence about feasibility and adoption. Procurement and security staff may also need to participate where their requirements determine whether a product can enter routine use.
How should customer needs become technical requirements?
Customer needs should become measurable conditions covering the information required and its delivery. Specifications should identify the relevant geographic area, acceptable uncertainty, and the maximum useful age of an observation. Each condition should connect to an operational reason and have an agreed method for determining whether the product meets it.
Can a commercial service use freely available satellite data?
A commercial service can build on public observations when their terms permit the intended use and their characteristics meet customer requirements. Free access to imagery does not eliminate processing or support costs. The provider still needs to establish that its delivered product offers sufficient value to justify the service price.
What is the difference between revisit frequency and delivery latency?
Revisit frequency concerns opportunities to observe a location again. Delivery latency concerns the delay between collecting an observation and making a result available to the customer. Usable observation frequency can be lower than nominal revisit frequency because some acquisitions fail quality requirements or do not cover the required location.
How should an Earth observation product be validated?
Validation should compare product outputs with suitable independent evidence across the conditions in which the service will operate. Testing needs to address measurement error and operational consequences. The assessment should document reference-data limitations, failure cases, and the method version so customers can judge whether the evidence applies to their decisions.
What should a pilot demonstrate?
A pilot should demonstrate whether the product meets agreed requirements and improves a defined customer task relative to the existing process. It should also test delivery and integration under realistic conditions. A separate commercial assessment must establish whether a budget and purchasing route exist for continued use.
How should providers price Earth observation services?
Providers should select a charging unit that customers can relate to their usage and budget. Pricing analysis needs to include recurring delivery costs and customer support, with one-time implementation work identified separately. Service terms should state coverage and limitations so the customer can evaluate a concrete offer.
What changes when a prototype becomes an operational service?
An operational service requires continuing responsibility for delivery, support, and product changes. It also needs customer ownership and procedures for acting on the information. Performance monitoring must extend beyond successful processing to the quality and freshness of delivered results, with an agreed response when the service fails.
Appendix: Glossary of Key Terms
Earth Observation
The collection of information about the planet using instruments on satellites or other platforms. In product development, observations provide measurements that can be processed and combined with other information to support a defined customer task or decision.
Spatial Resolution
The ground detail represented in an observation, often described through the size of an image pixel. Smaller pixels can represent finer detail, but pixel size alone does not determine whether a feature can be reliably detected or interpreted.
Temporal Resolution
The frequency with which observations of a location are available. For a customer service, the useful measure is the frequency of observations that meet the product’s quality requirements, which can differ from the satellite’s nominal revisit capability.
Latency
The time between collecting an observation and delivering it or a derived result. Processing and review can contribute to this delay. Latency must be considered alongside observation age to determine whether information arrives before a customer’s decision deadline.
Application Programming Interface
A defined method that allows software systems to exchange information. An Earth observation service can use such an interface to deliver results into a customer’s existing software, reducing the need for staff to retrieve information through a separate portal.
SpatioTemporal Asset Catalog
A set of specifications for describing and discovering geospatial data associated with locations and times. It helps organize access to data assets, but does not establish their measurement accuracy or decide how a customer should interpret the results.
Evapotranspiration
The combined transfer of water into the atmosphere through evaporation from surfaces and transpiration from vegetation. Satellite-based estimates can support water management, but their suitability depends on the evaluated conditions and the accuracy required for the intended decision.
False Alarm
A product result that identifies an event or condition that is not present under the agreed reference criteria. False alarms can create unnecessary investigation and expense, so validation should measure their frequency and assess their consequences for the customer.
Application Readiness Level
A measure of how far an application has progressed from an initial concept toward operational use. NASA’s framework includes feasibility and validation stages before integration into decision-making, helping distinguish technical development from sustained use by an organization.
