Define the smallest complete journey
Name a specific user, the job they need to do and what they use today. A first product should carry that person from a clear starting point to a useful outcome. It can leave out many features, but it cannot leave out the essential steps that make the task work. A prototype, a manually supported pilot and a production application serve different purposes; choose deliberately.
Test the assumption that could kill the idea
People saying an idea sounds good is weak evidence. Observe how they solve the problem now. Put the core journey in their hands and look for actual use, repeat interest or a concrete commitment to a pilot. Decide in advance what result would make you stop, change direction or invest further. That makes the first version a learning tool rather than an expensive declaration of belief.
Keep the foundations proportionate
The first version still needs sensible validation, error handling and access controls wherever it handles real users or data. Plan how information can be exported, how mistakes can be recovered from and who will operate the product. Add complexity when the product needs it, rather than copying the architecture of a much larger company.
A public example of HPT product thinking
Poncdash explores a specific problem: keeping contact details and relationships connected as people change numbers, jobs and platforms. Its public site identifies it as an HPT product. It is an example of starting with a human problem and building a focused digital service around it, not a promise that another product will achieve a particular commercial result.
Bring the problem, not a finished specification
For a first conversation, describe who has the problem, how often it happens, the current workaround and the most important unknown. We can then discuss a credible first experiment and what would need to be true for a larger build to make sense.