EDGE product development: build user-testing evidence

EDGE product development support is designed for a real technological or functional advance that leads towards market use. A persuasive project file therefore needs more than a polished prototype photograph. It should connect the original business problem, the build decisions, user evidence, technical feasibility and the route to commercialisation.

Confirm that the project fits the activity

The current Enterprise Singapore product development activity page supports new products, services and solutions developed through technological innovation. It excludes a company’s first product, routine replacement, standard implementation and incremental upgrades unless they form part of a larger system with clear advancement. Record the existing commercial operation and the market baseline against which the advance will be judged.

Describe the problem in observable terms. Name the users, their current workaround, the measurable limitation and the proposed improvement. Then identify the feature or technical method that is genuinely new for the company and meaningfully beyond ordinary market practice. Marketing adjectives are not evidence of advancement, and a grant application should not rely on them.

Define a testable prototype

Set the prototype boundary before development begins. List the functions that must operate, interfaces that may be simulated, materials or data required and conditions under which the prototype will be tested. Distinguish a proof of concept from a production-ready version so reviewers and management do not interpret an early demonstration as a completed product.

Create acceptance criteria for performance, safety, reliability and usability. Each criterion should have a method, responsible tester and evidence format. When the prototype changes, preserve the version, reason and result. A dated version trail is more useful than a final report that makes every design decision appear obvious in hindsight.

Recruit representative users

Choose participants who resemble the intended customers or operators, not only employees who helped design the product. Record the selection basis, relevant experience and any conflicts. Obtain appropriate consent and protect personal or confidential information. Where the product serves several user groups, make sure the test does not overrepresent the easiest group to reach.

Write tasks that reflect normal use and known difficult conditions. Avoid coaching participants towards the expected answer. Capture completion, errors, time, requests for help and qualitative observations. If an incentive is provided, record it and ensure that it does not encourage favourable feedback. Negative findings are valuable when they lead to a clear design decision.

Separate user validation from technical feasibility

User validation asks whether the proposed solution addresses a real need and can be used successfully. Technical feasibility asks whether the design can meet its requirements under the stated constraints. Maintain separate findings even when the same prototype is involved. High user interest does not prove that performance, security, manufacturing or integration risks have been solved.

The official deliverables call for a project report that includes a user-testing report and/or technical-feasibility report. Treat the Letter of Offer as controlling for the exact project. The report should identify the test method, sample, results, exceptions, limitations and conclusion, with references to the underlying records rather than screenshots pasted without context.

Turn findings into controlled design changes

Create a decision log for every material finding. State whether the team accepted it, deferred it or rejected it, and explain why. Link accepted findings to a requirement, design change and later verification result. Deferred issues need an owner and commercial consequence, especially where they affect safety, accessibility, regulatory compliance or the promised value proposition.

Do not quietly narrow success criteria after a poor result. If a requirement changes, document the evidence and approval. Where the change affects approved scope, cost, vendor or deliverables, check the official route before proceeding. The EDGE project-change guide explains the broader post-award change boundary.

Build the market and commercialisation bridge

Enterprise Singapore lists market viability, product roadmaps, distribution and commercialisation plans among possible supporting reports. Convert the test results into a target segment, price assumption, channel, service model and next investment decision. Show which assumptions were validated and which remain uncertain. A three-year projection should trace back to volumes, pricing, adoption and capacity rather than an unexplained growth percentage.

If certification, patents or freedom-to-operate work is relevant, place it on the same roadmap. Identify markets, owners, decision dates and dependencies. Do not imply that a patent application proves market demand or that user interest proves regulatory acceptance. Each evidence stream answers a different question and should retain its own conclusion.

Reconcile costs and completion evidence

Match approved cost lines to contracts, invoices, payments and actual delivery. All project expenses must be paid in full before claim submission, and only approved expenses are supportable. Keep unsupported enhancements outside the grant schedule even if they improved the final product. Where another party paid an expense, retain the reimbursement trail required by the activity guidance.

Prepare a deliverables index showing the final prototype proof, reports, certifications or patent evidence required by the Letter of Offer. Include document dates, versions and owners. The Singapore business support decision guide provides the site’s broader enterprise-support context, while this index stays specific to the approved product-development project.

Run an independent closeout review

Ask a reviewer who was not responsible for day-to-day development to trace three representative requirements from application to test, result, decision and final deliverable. The reviewer should also compare the approved vendor, period and cost schedule with the actual project. Resolve missing links before the auditor engagement or claim deadline creates pressure.

Keep the review factual. EDGE support does not certify the product, guarantee sales or replace the company’s duties to customers and regulators. The strongest file shows both what worked and what remains limited, because management can then make a responsible launch decision while the claim evidence remains accurate.

A prototype becomes useful grant evidence when another reviewer can see what was tested, what changed and why the final product is commercially and technically credible. Build that chain during development, not from memory after the work has ended.