jmis-methods
GitHub用于为JMIS论文选择并辩护研究设计，匹配IT价值、平台、行为或设计科学等风格与主张。确保在50页限制内建立可信因果识别或效用评估，并将具体数据分析委托给jmis-data-analysis。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill jmis-methods -g -y
SKILL.md
Frontmatter
{
"name": "jmis-methods",
"description": "Use when choosing and defending the research design for a Journal of Management Information Systems (JMIS) manuscript — IT-value\/platform econometrics, a behavioral survey or experiment, an analytical\/economic model, or a design-science\/data-science artifact. Matches the method to the IS claim and the ≤50-page budget; it designs the study and hands estimation\/evaluation to jmis-data-analysis."
}
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 withas_handle=true→audit_resultto enumerate the checks the design owes.- Panel / staggered DiD:
callaway_santanna/sun_abraham+bacon_decompositionhonest_did_from_result. IV:effective_f_test+anderson_rubin_ci. RDD:rdrobust+mccrary_test.
- Experiments: randomization-based inference and
romano_wolffor 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
Version History
- 1839142 Current 2026-07-05 13:46
