Name the client and the decision you need to settle, and get a programmer-ready question bank, the sample size that makes the answer mean something, and the rules for reading the results written down before any data comes in.
Name the client, their site, and the decision the research has to settle. Juma reads the brand's own product pages, published reporting, and public claims to ground the concepts being tested, then builds the full survey design around the decision rather than around a topic. What comes back is a branded PDF protocol plus an editable CSV question bank, with exact respondent-facing wording, response scales, skip logic, and the analysis variables already named.
The part teams usually skip is the part that makes the answer defensible: the sample size the decision needs, and the decision rules written down before fieldwork opens. 400+ marketing teams use Juma, and the research work that survives a stakeholder meeting is the work where nobody can reinterpret the numbers after seeing them. Strategy, taste, and judgment stay human. The protocol just removes the room to argue.
Most survey drafts fail quietly. A leading question inflates agreement, a double-barrelled item makes an answer uninterpretable, and an unbalanced scale pushes respondents toward the positive end without anyone noticing. Run the bias audit as a separate pass and the question bank comes back with each rejected version printed next to its repair and the failure mode named: leading, double-barrelled, unbalanced scale, acquiescence, or vague frequency wording. The rejected wording stays in the CSV as its own column, so the team reviewing the instrument can see what was caught rather than taking it on trust.
Now audit your own question bank for bias. Go item by item and flag leading questions, double-barrelled items, unbalanced scales, acquiescence risk, and vague frequency wording. Show the rejected wording next to the repaired version with the failure mode named, and keep the rejected text as a column in the CSV.
"We got 200 responses" means nothing until someone says what difference 200 responses can detect. Ask for the sample plan and the Flow computes the completes the decision requires, prints the formula and every input, and converts that into an invitation count at a stated response rate and exclusion rate. It also names the assumption the number is most sensitive to, which is usually the discordance rate in a paired design or the baseline rate in a two-group one. Every assumption comes labelled as an assumption, so the research ops team can swap in the client's real panel figures and recompute.
Now size the sample. Print the power formula and every input you used, state whether the design is paired or two independent groups and why that changes the calculation, and give me the completes we need plus the invitations that implies at a stated response rate and exclusion rate. Label each assumption as an assumption and name the one the sample size is most sensitive to.
A 2-point gap becomes a mandate the moment someone wants it to. The fix is a decision table written while the result is still unknown: the primary metric, the threshold that counts as a real win, what happens when neither option clears it, and the tie-break rule when a secondary number disagrees with the primary one. Ask for it and the protocol comes back with the exclusions set before analysis, the quality rules fixed, and a short list of what cannot change once fielding starts. The team keeps the judgment call. What it gives up is the room to move the goalposts.
Now write the analysis plan as a locked decision contract. Give me the primary endpoint and its exact cut point, the practical threshold that counts as a win, a decision table covering every outcome including "no winner", the tie-break rule when a secondary metric disagrees, the exclusions applied before anyone sees the comparison, and a list of what cannot change once fieldwork opens.
Stated intent is not behaviour. A survey can establish which direction customers say they want and how strongly, which is enough to choose where the next build goes. It cannot show that the feature changes retention or revenue. Ask for the boundary and the Flow states it on the first page, then specifies the in-product experiment that follows: the behavioural outcome to pre-register as primary, the secondary measures, the guardrail metrics that would stop a rollout, and the point at which spend should scale. The survey picks the bet. The experiment settles whether the bet paid.
State plainly what this survey can and cannot establish, then specify the in-product experiment that has to follow it. Name the behavioural outcome to pre-register as primary, the secondary measures, the guardrail metrics that would halt a rollout, and the evidence threshold at which we scale spend.
Run one project per client and the survey design stops starting from zero. Add the things that shape what is fieldable and what has already been asked, and every study built in that project inherits them. The second survey for a client is faster than the first, and the fifth is faster again, because the constraints only get entered once.
Research constraints
Panel access, the eligible customer base, languages and markets, consent requirements, and how often the client is willing to contact a customer. These decide whether a sample plan is realistic or just arithmetic.
Prior studies and their questions
Past surveys, the wording used, and the results. Repeating a question verbatim gives a trend line. Changing it quietly breaks one, and nobody notices until the readout.
Published claims and product reporting
The client's own public numbers, product pages, and filings. Concepts grounded in what the brand has actually said hold up in the room better than concepts invented from scratch.
Decision owners and thresholds
Who signs off and what size of difference would change their mind. The practical threshold in the decision table should come from them, not from a default.
Each knowledge item takes a short description. One line is enough, and it tells Juma when to reach for that item instead of guessing.
Two files. A branded PDF protocol covering the decision being settled, the concepts or topics tested, the sample plan with its arithmetic shown, the full question bank, the analysis plan, and the fieldwork quality rules. Alongside it, an editable CSV with every question in programmer-ready form.
The CSV carries the respondent-facing text, response type, response options, display order, randomization, skip logic, programming notes, and the analysis variable each item maps to. It imports into a survey platform without retyping, and the team can edit wording in place before it goes anywhere near a respondent.
It depends on the size of difference that would change the decision, and the Flow computes it rather than quoting a round number. The protocol prints the formula, every input, and the resulting completes, then converts that into invitations at a stated response rate and exclusion rate.
The design matters as much as the number. A paired design, where one respondent evaluates both options, needs materially fewer people than two independent groups, because each respondent acts as their own control. Getting that distinction wrong is the most common way a sample-size estimate ends up off by roughly half.
Every assumption is labelled as an assumption. Swap in the client's real panel figures and the arithmetic recomputes.
Yes. Ask for the bias audit and the Flow goes item by item against named failure modes: leading questions, double-barrelled items, unbalanced scales, acquiescence risk, and vague frequency wording. Each rejected version is printed next to its repair with the fault named.
The rejected wording stays in the CSV in its own column. A researcher reviewing the instrument can see what was caught and disagree with any of it, which is the point. Human review on every output.
The gain is in the parts that normally get skipped under deadline. Teams write good questions. What slips is the sample-size arithmetic, the bias pass, and the analysis plan written before the data lands, because each one takes an afternoon and none of them feel urgent until the readout goes wrong.
Juma augments the team, it doesn't replace it. The researcher still chooses the decision to test, sets the threshold that counts as a win, and signs off on the wording. What changes is that the unglamorous rigour arrives in the first draft instead of never.
Yes. The structure holds for any decision with two or more defensible options and a population that can be sampled: pricing-tier preference, positioning, feature prioritisation, or churn-driver research. What changes is the sample arithmetic, because B2B populations are smaller and the Flow applies a finite-population correction rather than pretending the base is infinite.
Small eligible populations sometimes cannot support the difference a team wants to detect. The protocol says so directly instead of producing a number that looks authoritative and is not.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
