Start with a problem you can describe in one sentence
Before listing features, write down who the product is for, what they are trying to accomplish and what gets in the way today. “A tool for local tournament organisers to publish fixtures and keep teams informed” gives a team more direction than “a sports platform”.
Gather what you already know: conversations, workarounds, spreadsheets, support requests or existing product feedback. Label assumptions as assumptions. Discovery becomes much more useful when everyone can distinguish evidence from a promising idea.
Choose one complete journey for the first release
A small product should still let someone complete a meaningful task. Write the journey from entry to outcome, then identify the features that make it possible. An organiser might create a competition, add teams, publish fixtures and record a result. Features that do not support the first agreed outcome can wait.
For each essential step, add an acceptance condition. What should a person see after saving? Who can edit a result? What happens if required information is missing? These questions help expose work that a simple screen count would miss.
Decide what the prototype needs to answer
A clickable prototype can test navigation and comprehension. A technical prototype can test an integration or a difficult interaction. A playable prototype can test whether a game mechanic is enjoyable. Choose the smallest experiment that addresses your biggest uncertainty.
Agree what would change your mind. If users cannot complete the core task in a prototype, refining that task may be more useful than adding a second feature. If an external system cannot provide the required data, the product scope may need to change before development starts.
Compare web and mobile against actual requirements
Think about where people will discover the product, how often they will use it and which device features it needs. A link that opens in a browser can make sharing and initial access straightforward. Offline behaviour, notifications or repeated mobile use may justify an app.
There is no single best stack for every brief. Ask a potential development partner to explain the trade-offs in maintenance, platform access, content management and release processes. Include the accounts, services and subscriptions the product will depend on.
Prepare a budget conversation, not just a number
Tell the team the range you are comfortable exploring, the must-have outcome and any real deadline. Explain whether design, content, integrations, migration and ongoing support need to be included. A useful proposal makes the assumptions and exclusions explicit.
At Empyre, project budgets are discussed in pounds. We do not publish a universal MVP price because scope varies. A website with supplied content, a connected mobile product and a simulation with a custom model involve very different work.
Plan the handover before launch
Agree who owns the accounts, source code and content, who can release an update and who is responsible for support. Ask for the configuration notes and operating documentation your team will need after the engagement.
Define what you want to learn after release and how feedback will reach the team. Measurement should answer a real product question. Do not collect personal information or install tracking simply because another product does.
Bring a brief that opens a useful conversation
A good starting brief covers the audience and problem, the main user journey, existing evidence, essential integrations, supported platforms, budget range, timing and who will make decisions. Include links or examples to explain a preference, alongside what you like about them.
You do not need all the answers before talking to a studio. A clear account of what you know and what is still uncertain is enough to start. Our enquiry form helps organise these inputs and send them to the Empyre team.