Define the change for one user
Begin with a user, a recurring situation and a measurable improvement. Replace broad statements such as businesses need better automation with a concrete claim: a catalogue team should be able to publish approved product updates in hours instead of days.
This definition becomes the decision filter for features. If a feature does not help the target user reach the promised outcome or help the team learn whether the promise is valuable, it probably does not belong in the first release.
Map assumptions before features
Every product idea contains assumptions about demand, behaviour, technology, data and economics. Rank them by how damaging they would be if false. A landing page, interview, manual service or interactive prototype can test many assumptions before production code is necessary.
Validation is not a collection of compliments. Strong evidence includes a pre-order, a signed pilot, access to real data, repeated use or a customer changing an existing process to adopt the solution.
Design the smallest complete product
A minimum viable product should be small, but it must complete the core journey. Authentication, payments, error handling and support may be less exciting than the signature feature, yet they often determine whether the product works in real life.
Write acceptance criteria for the main journey and define what will be measured. This creates a shared contract between strategy, design and engineering and reduces expensive interpretation during the build.
Build for learning, then operate
Use short releases and observe real behaviour. Instrument the product from the start so the team can see activation, completion, failure and retention. A launch is the beginning of product development, not its final ceremony.
Wishmakers works from concept to operation because the decisions made after launch are inseparable from the original design. Real products require maintenance, support, infrastructure and a clear rhythm for improvement.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering Contact Wishmakers
Frequently asked questions
Do I need a technical specification before contacting a product company?
No. A clear description of the user, problem, constraints and desired outcome is more useful at the beginning.
How long should an MVP take?
It depends on risk and scope. A focused product can often be tested in weeks, while regulated or integration-heavy systems require more preparation.
Should I protect the idea before discussing it?
Confidentiality can be appropriate, but execution, insight and access to users usually matter more than secrecy alone.