Jmis methods

Research Design & Methods (jmis-methods)

When to trigger

• You have a mechanism or propositions but no defensible way to test/evaluate them
• The method may not match the claim (a causal IT-value claim resting on a cross-sectional correlation)
• A reviewer asks "what identifies this effect?" or "how do you know the artifact is useful?"
• You need to decide what evidence fits inside the 50-page complete-manuscript ceiling

Match the design to the JMIS research style and the strength of the claim

JMIS is methodologically broad but the design must earn the causal/economic verb in the claim.

Style	Typical designs	The design must establish
IT business value / firm	Panel econometrics, natural experiment, DiD, IV, matching	Credible identification of IT's causal value against endogenous IT investment
Platform / e-commerce	Quasi-experiments on platform shocks, structural demand, field experiments	The network/two-sided mechanism, controlling for selection on platform data
Behavioral IS	Lab/online/field experiment, multi-wave survey, panel	Internal + construct validity and procedural remedies for common-method bias
Economics of IS	Analytical model; empirical test of a model's prediction	A coherent model with stated assumptions, or a test that maps to the prediction
Design-science / data-science	Build-and-evaluate of an IT/ML artifact	Novelty and managerial utility vs. credible baselines — not "it ran"

IT-value and platform empirics: identify, do not just control

IT investment and platform participation are chosen, not random. Anchor identification in a real source of exogenous variation — a policy change, a staggered system rollout, a platform redesign, a security breach, a pricing shock — and pre-commit the comparison and the assumptions you will defend. With staggered adoption, plan a modern estimator (Callaway–Sant'Anna, Sun–Abraham, de Chaisemartin–D'Haultfœuille) rather than naive TWFE, and design the event-study leads up front. Endogeneity that is only "controlled for" with covariates will draw reviewer fire.

Behavioral IS: design out the threats before you collect data

Build procedural separations against common-method bias — temporal/source/psychological separation, validated and pretested scales, attention and manipulation checks — because statistical fixes (e.g., a marker variable) alone will not convince reviewers later. For experiments, make the IT manipulation realistic and the estimand explicit; report power.

Design-science / data-science: plan the utility evaluation up front

A JMIS artifact paper lives on managerial utility, not algorithmic novelty alone. Decide before building how you will demonstrate utility: held-out benchmarks against credible (not strawman) baselines, a controlled experiment or A/B field deployment, simulation, or expert evaluation — each tied to the artifact's design rationale and to a real managerial decision. State the problem's relevance and the evaluation criteria so reviewers judge rigor and relevance.

Scope the evidence to the 50-page budget

The complete manuscript is capped at ≤50 pages (12pt, double-spaced). Online appendixes are permitted, but the main paper must be self-contained and the core claims established in the body — do not design a study whose key evidence only fits by exporting it. Survey instruments go as separate anonymized attachments. (检索于 2026-06；以官网为准.)

Worked vignette: identifying IT business value (illustrative)

A team wants to claim that an ERP go-live raised plant productivity. A cross-section of ERP-adopters vs. non-adopters cannot carry that claim — adopters differ systematically (larger, better-managed firms self-select). The JMIS design uses the staggered go-live timing across plants as the variation, estimates with Callaway–Sant'Anna (not naive TWFE), pre-specifies the event-study window, and checks that pre-trends are flat before go-live. The identifying assumption — that go-live timing is not driven by anticipated productivity shocks — is argued from the institutional rollout schedule and falsified with a placebo on plants whose go-live slipped. That is the difference between "ERP correlates with productivity" and "ERP go-live raised productivity by X%."

Referee pushback mapped to a design fix

• "Selection — adopters are not comparable to non-adopters." → Switch from cross-section to within-firm timing variation or a defended IV; show balance/pre-trends.
• "How do you know the artifact is actually useful?" (design-science) → Add an evaluation against credible baselines tied to a real managerial decision, not a benchmark of convenience.
• "Common-method bias undermines your survey." → Show the procedural separations you built in ex ante, then the statistical test; do not rely on the test alone.

Execution bridge (StatsPAI / Stata MCP)

For the empirical / causal lane, estimate and audit rather than only specify. Full map: execution-with-mcp. JMIS is empirical IS — survey-based SEM and econometric panels; the chain below serves causal / quasi-experimental designs and many-outcome corrections.

• detect_design → recommend → fit with as_handle=true → audit_result to enumerate the checks the design owes.
• Panel / staggered DiD: callaway_santanna / sun_abraham + bacon_decomposition
  • honest_did_from_result. IV: effective_f_test + anderson_rubin_ci. RDD: rdrobust + mccrary_test.
• Experiments: randomization-based inference and romano_wolf for the many-outcome family-wise correction reviewers expect.

Match the toolchain to the reviewer pool, and report the effect size the venue wants. A run end-to-end (synthetic data, real returns) is in the JF execution walkthrough.

Checklist

• Design matches the style and the strength of the claim
• IT-value/platform: a named source of exogenous variation; modern estimator where TWFE would bias
• Behavioral: validity threats and CMB designed out procedurally, not just measured
• Economic model: assumptions stated; empirical test maps to a model prediction
• Design-science: utility evaluated vs. credible baselines, tied to a managerial decision
• Core evidence fits ≤50 pages; appendix carries only support, not load-bearing claims
• The design section states why this method is the right tool for this specific claim
• Platform designs address two-sided feedback and algorithmic confounding

Platform and e-commerce data: design around its pathologies

Platform and marketplace data — a JMIS staple — carry built-in threats that the design must anticipate, not patch later. Participation and intensity are endogenous (sellers/buyers self-select into features); two-sidedness means a shock to one side feeds back to the other, so a naive one-side regression is mis-specified; ranking/recommendation systems create feedback loops where the outcome you measure was partly caused by the system you study; and platform redesigns are often rolled out non-randomly. Build the identification around a genuine source of exogenous variation (a staged redesign, an exogenous policy or pricing change, a randomized experiment the platform ran) and state explicitly how you handle cross-side feedback and algorithmic confounding. Reviewers on platform papers will probe exactly these points.

Anti-patterns

• A causal IT-value claim resting on a cross-sectional or correlational design
• Endogenous IT/platform choice "handled" only with control variables
• Single-source, single-wave self-report with no procedural CMB remedies
• A design-science artifact benchmarked only against strawman baselines, or with no managerial relevance
• A design that "fits" only by exporting half the evidence to an online appendix
• Method chosen for fashion (deep learning where transparent regression answers the claim better)
• A platform analysis that ignores two-sided feedback or algorithmic confounding in the data
• No statement of why this method is the right tool for this specific claim

Make the method serve the claim, not fashion

JMIS reviewers reward a method chosen because the claim and phenomenon demand it, and they penalize method for method's sake. A flashy deep-learning model where a transparent regression would answer the managerial question better is a liability, not an asset; conversely, a simple OLS where the design clearly calls for a quasi-experiment will not carry a causal claim. State, in the design section, why this method is the right tool for this claim — what it identifies or evaluates that a simpler or fancier alternative would not. Where you combine methods (e.g., an experiment to establish a mechanism plus field data for external validity), say what each leg buys you. The method should read as the inevitable consequence of the question, not a showcase.

Output format

【Style & design】firm econometrics / platform quasi-exp / survey-experiment / analytical / build-and-evaluate
【Identification or evaluation】source of variation OR evaluation plan + credible baselines
【Validity threats handled】endogeneity / CMB / construct validity / external validity
【Fits ≤50pp?】yes / trim
【Next step】jmis-data-analysis