Validate your app idea with Margaux before building

Between an appealing idea and a confirmed problem, there is often some research to do. Prepare your observations, work on the brief with Margaux and decide what to check before building.

Margaux can help you clarify an application idea and turn it into an understandable brief. She cannot decide on behalf of future users whether their problem deserves new software. A well-written proposal remains a proposal: to validate it, you need to compare it with what actually happens.

Our example is fictional. Lina rents decorations for events. She is considering an application that lets customers track their orders. Her colleague Hugo prepares items going out and coming back. The people, business and observations are invented to explain the method; this is neither a Maestro customer nor research that actually took place.

1. Separate the proposed solution from the problem to check

“A rental tracking application” describes a solution. It does not yet explain why anyone would change their habits to use it. Lina needs to return to an event: a customer asks whether an item is available; she answers using a stock status that does not reflect an incomplete return.

Several problems could lie behind this situation. The customer might lack information. The team might not know whether returned items are ready to go out again. Or no one might be responsible for confirming the return's condition. A customer-facing application would address only some of these possibilities.

Write two separate sentences: “I would like to build…” and “The problem I want to check is…”. For Lina, the second becomes: “We risk promising an available decoration before it has been checked after its return.” She can now investigate whether this problem exists, when it occurs and how it is handled.

In Maestro, Margaux's role is to frame the project: clarify the problem, the people involved, the expected value, the goals and the risks. The team introduction places this step in the process. Use her to organise your questions while keeping business decisions on your side.

2. Take stock of what you actually know

Before asking the AI for an opinion, prepare a note in three parts: observed facts, possible explanations and open questions. This separation prevents a restatement from turning your intuition into certainty. Information can be precise without being representative; always record its origin and the situation it describes.

A fictional fact in our example would be: “After the last return, two decoration items were not ready to go out when the next booking was prepared.” A possible explanation: “Available status was restored too early.” An open question: “Who needs to confirm the check before a new promise is made to a customer?”

Avoid replacing these details with “our management is inefficient”. That phrase could fit several opposing problems. Describe the moment, the missing information and the decision it makes difficult. If you did not witness the situation yourself, mark it as “reported by…” rather than presenting it as a direct observation.

3. Choose the right people to talk to

Lina needs to hear several perspectives. Hugo knows about returns and missing items; whoever confirms bookings knows the commitments made; a customer knows the information they need. In a small business, one person may hold several roles, but their questions remain different.

Start with people who actually encounter the situation. Friends enthusiastic about your project can encourage you without understanding the work. Also look for a case that challenges your intuition: someone who manages returns easily or a customer who does not want another account.

Explain the subject simply: you want to understand a situation, not sell an application already decided upon. Ask for a recent example the person is willing to describe. Suggest a conversation short enough to accept easily, and adapt its length to the story rather than promising complete research in a few minutes.

The GOV.UK interview guide recommends open, neutral questions focused on stories and real examples. In our case, that means asking how a return happened before presenting the screen Lina has imagined.

4. Prepare a conversation that does not suggest the answer

“Would you like an application that saves you time?” invites agreement with a promise. “Tell me about the last equipment return you handled” lets you examine work. The second wording does not guarantee a complete answer; it gives you a situation to revisit in detail.

Lina can prepare the following questions for Hugo. They are reference points, not a questionnaire to run through when an important answer deserves further exploration. The goal is to reconstruct the process and identify what is missing when someone has to make a decision.

• Which items came back after the last event?
• Where did you record what was missing or needed repair?
• Who was told, and how did you know the message was understood?
• At what point were the items considered available?
• What happened when the next booking was prepared?
• What did you do to solve the problem with the tools you already have?

Ask to see a sample document only if the person can show it without exposing confidential information. Take notes relevant to the problem. Recording is not necessary by default; if you plan to record, explain how it will be used and get the person's agreement before starting.

Leave your idea until the end of the conversation. Present it as one possibility, then ask what it would not solve. “That would be useful” is less helpful for choosing the next trial than a specific difficulty: “I won't be able to complete that form while unloading the truck.”

5. Turn feedback into testable hypotheses

Review your notes without forcing everything into the original idea. In our invented scenario, Hugo explains that he knows what is missing, but the information does not reach the person confirming availability. Lina discovers that the first issue might be internal confirmation of returns, before customer tracking.

State a hypothesis with an observable condition: “If a return's status is confirmed only after checking, the person taking bookings will be able to distinguish ready items from those still to be checked.” It remains to be seen whether the team can maintain that rule in everyday work. Wording it does not prove that they will.

Also separate the importance of the problem from willingness to use your solution. A difficulty can be real without justifying a new tool. The team might prefer a common rule, a box in its current file or existing software. Ask what has already been tried and why it was kept or abandoned.

Do not turn a few conversations into a market percentage. Record recurring points, differences between roles and counterexamples instead. A group of people you already know does not automatically represent all rental businesses. The first goal is to choose a relevant trial, not announce proven commercial demand.

6. Give Margaux a short, honest set of information

At this point, you have material more useful than a feature list. You can provide a context summary, a few anonymised facts, your hypotheses and the research limitations. Avoid complete transcripts when an extract is enough. The data guide explains the difference between a project kept locally and context sent to an AI assistant.

Here is a request prepared for our example: “I rent decorations. I was thinking about creating customer tracking, but the first conversations suggest a problem with confirming returns. We do not yet know whether an application is necessary. Help me distinguish what was observed, what is assumed and what needs checking.”

Add the material: “Reported situation: items were promised before the return was checked. Hypothesis: the person taking bookings lacks a reliable status. Another possible explanation: the rule exists, but no one is responsible for keeping it up to date. Limitation: we have only explored our organisation, not the rental market.”

Finish with the expected result: “Propose a short brief with the problem, the people involved, an initial experiment, the risks and what remains out of scope. Do not invent time savings or customer demand. Mark the decisions that need my judgement.” This directs the thinking without turning the AI into a witness to events.

7. Review the brief as a proposal to correct

The brief Margaux produces must be checked against your notes. First look for changes in meaning. “Customers demand real-time tracking” would be false if no one requested it. “The team lacks reliable confirmation before promising items” remains closer to the problem described in our example.

Then check the roles. Who records the return? Who can confirm that an item is ready? Who checks that information before answering the customer? A word such as “user” can hide three different responsibilities. Ask for a restatement in your everyday language before that ambiguity becomes an application rule.

Also look at additions: payments, signatures, automatic messages, statistics. A suggested feature may be interesting without being necessary for the first trial. Put it among future possibilities if no observation makes it essential. This protects the question you are actually trying to answer.

A complete correction contains the sentence to change, the reason and the expected wording. For example: “Replace ‘the customer confirms the return’ with ‘Hugo records the return, then Lina confirms availability after checking’. The customer does not check item condition in our organisation.” Then reread the whole document for any contradictory sentence left behind.

8. Choose an experiment before building more

The brief may lead to a trial without an application: for a few returns, the team explicitly distinguishes received, to be checked and ready to go in its usual tool. It examines whether this distinction helps the person taking bookings. This is a proposed method for the fictional case, not an achieved result.

Lina can also prepare a simple screen with invented decorations. She asks Hugo to find what can go out, then handle an incomplete return. If she has to explain every label, the wording and logic need more work before features are added. An attractive mockup alone does not address that difficulty.

Write the criterion before the trial. For example: “The person confirming a rental must distinguish checked items from those still awaiting checks without asking Hugo.” Specify when and with which examples you will observe that behaviour. If you want to measure time savings, start by measuring the current situation.

Also keep a stopping criterion: if updating takes effort the team cannot sustain, review the workflow. Adding automatic reminders does not necessarily solve an absent responsibility. The next lesson may involve changing the organisation before choosing software.

9. Decide whether to continue, revise or set the idea aside

Gather the facts learned, the remaining difficulties and the options. Continuing may mean building a small version; it can also mean talking to another role or trying an existing tool. State which uncertainty each option helps reduce. You will avoid confusing progress with producing more screens.

Revising the idea is normal. Lina began with customer tracking and is now exploring internal confirmation of returns. The first idea opened the discussion. If the problem is rare, already well handled or has too little consequence, setting it aside may be the most useful decision.

For an application intended for sale, add a separate question: who would decide to buy it, and from which budget? The person who enjoys using a tool is not necessarily the person authorised to buy it. Agreement to try does not prove a commitment to pay; keep those levels separate in your conclusion.

10. Keep a decision the team can find again

Your final note can fit on one page: the chosen problem, the people involved, facts supporting the decision, remaining hypotheses, the first experiment and a review date. Add the features set aside and why. This record helps avoid reintroducing an abandoned idea without noticing it has already been discussed.

For Lina, the result is not “our application is validated”. It is: “We will check a return-confirmation rule before building a customer area. Hugo shows how a return is handled; Lina observes the availability decision; we then examine the difficulties encountered.” Each person knows what they need to contribute.

Once the need is clear enough, the non-technical requirements guide helps describe what must be built and checked. The guide to creating without coding follows the next steps. You move from a decision about the problem to work on the solution.

You can start this research without waiting for Maestro. Write down a concrete event and ask someone involved to tell it from their perspective. To then work on framing with Margaux, Maestro access is by invitation, on Mac. The application is free during the beta; AI usage remains a cost to consider with your chosen provider.

Back to contents