Pilot an Energy App by Testing One Household Decision
Before building an energy app, validate whether households can use one simple comparison of when they consume electricity to make a practical planning decision.
Interest in household energy costs and future tariff structures raises a useful product question: can people make a better planning decision when they compare using electricity at different times? Google Trends NL listed a Netherlands signal connecting peak-hour consumption, cheaper off-peak use and proposed changes to how households pay. That signal is context, not proof of demand for a particular app or a reason to build a broad energy platform. For a product team, the practical next step is narrower: test one household decision with clear inputs and a comprehensible result. Validate that workflow before committing to smart-meter connections, device control, forecasts or a large feature set.
Choose the decision before choosing the features
Start with a decision a household can describe in one sentence, such as: “Would moving one flexible activity to a different time be worth considering?” The pilot should help a participant compare two usage periods using information the team can reliably obtain. It should not claim to calculate a complete bill or recommend a change to a user’s contract unless the product has the appropriate data and rules. Write down who makes the decision, what choice is available, and what information could change that choice. If the team cannot state these plainly, the workflow is not yet scoped tightly enough to test.
The distinction matters because a request for an “energy app” can conceal several separate products: a tariff explainer, a consumption dashboard, a device-control system or a household planning assistant. Each has different data, integration and support requirements. For this pilot, exclude automation and hardware integrations. Define the smallest useful comparison: select two periods, enter or review a representative usage amount, and explain what the comparison does and does not include. A participant should be able to understand the result without needing a product manager to interpret it. If they need more information, record what is missing rather than quietly adding features during the test.
- Write the decision as a user question, not a feature name.
- List the minimum inputs, their source and any assumptions the result depends on.
- Set a boundary: the pilot compares a narrow case; it does not promise household savings.
Run a lightweight pilot with explicit assumptions
A first validation can use a clickable prototype or a simple, facilitated test rather than a production app. Recruit people who manage or influence household energy use, and ask them to work through the same scenario. Use clearly labelled hypothetical inputs if real consumption or price data is not available; do not present invented values as a participant’s actual costs. For example, a prototype might ask whether a flexible appliance could run in either of two chosen periods, then show how the supplied assumptions affect a comparison. The test is whether the person understands the choice and can act on the result—not whether a fabricated estimate predicts their bill.
Observe the full task: what the participant thinks the comparison means, where they hesitate, which input they trust, and what they would do next. Ask them to explain the result in their own words before offering help. Note whether they distinguish a relative comparison from a complete bill calculation, and whether the selected periods make sense for their routine. Capture reasons for abandoning the task or requesting another feature. A request for automatic device control, for instance, is evidence of a perceived need to investigate, not yet proof that integration should be in the first release. Keep findings tied to observed behaviour and stated limitations.
- Prepare one scenario and the same instructions for each participant.
- Label hypothetical inputs and show what is excluded from the comparison.
- Record task completion, misunderstandings, missing inputs and the participant’s next intended action.
Use evidence to decide what earns the next build step
Before testing, agree on decision criteria with product, engineering and commercial owners. A useful signal is whether participants can complete the comparison, explain its limits and identify a plausible next action without coaching. Also track which inputs are consistently unavailable or confusing. Do not treat enthusiasm for an idea as evidence that a complex integration will be adopted, or treat a small pilot as proof of market size. The findings should answer a scoped question: is this one workflow understandable and useful enough to justify a more realistic prototype or technical investigation? If not, revise the decision or stop before expanding delivery commitments.
If the workflow passes, plan the next step around the evidence gap. Confirm what tariff information would be needed, who supplies it, how effective dates or changes would be represented, and whether household usage can be entered manually before any meter connection is considered. Estimate integration work only after checking access, data quality, permissions and failure handling with the relevant provider. Keep automation separate until the team has validated both the decision and the safeguards required to act on a household’s behalf. This sequencing produces a more credible scope discussion: the team can explain what it learned, what remains uncertain and why a particular build cost is necessary.
- Advance only when users understand the comparison and its limitations.
- Investigate data access and integration feasibility as a separate decision gate.
- Defer automation until the underlying planning workflow and user safeguards are validated.
The most useful first energy-app pilot is not a smaller version of every feature the team might eventually want. It is a test of one household decision, with inputs the team can explain and a result users can interpret. The Google Trends NL signal about energy use and future tariffs offers timely context, but product scope should follow observed user behaviour and verified data requirements. Validate the comparison first; then decide whether integrations, automation or a broader platform are justified. That order gives leaders clearer evidence for roadmap and development-cost decisions.