Choose the format by the claim the evidence can sustain. A research feature explains a finding and how it was established. A founder interview examines decisions through answers that have actually been obtained. A technical byline teaches a method with enough detail to assess or apply it. A document can be useful in all three without being sufficient for any external pitch.
The decisive distinction is between an interesting source and a finished story. A delivery playbook is evidence of its authors’ published method. It is not evidence that a deployment succeeded, that a founder will give an interview or that a publication wants the story. Changing the headline cannot close those gaps.
Start with what the proof asset actually proves
The asset used here is Chapter 12, “The 90-Day Playbook,” in WebMCP Made Simple Complete Edition. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, co-authored that book and The Discovery Reset. Both books’ title pages identify them jointly. AEO means answer engine optimization; GEO means generative engine optimization.
Chapter 12 organizes a proposed rollout into four phases, beginning with an inventory and brief and moving toward instrumented tools and gated actions. The chapter names deliverables and completion measures. That makes it a concrete source for examining delivery discipline. Its proposed schedule and outcomes do not establish that the work occurred, and its technical details should not be substituted for current implementation documentation.
Shah and Shirke write in Chapter 12 of WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” The editorial consequence is useful: name a distinct deliverable for each format. A research feature needs a substantiated finding; an interview needs a recorded exchange; a technical byline needs a defensible explanation. Completing an outline proves only that the outline exists.
Before choosing, record the asset’s title, authors, version and exact passage, then separate its observations from its recommendations. Add the records that would support a stronger claim, if they exist. For a rollout story, those might include dated implementation records and the method used to measure completion. If those records are absent, narrow the story to the published method rather than converting intended outcomes into results.
A format-selection matrix tied to publication rules
These rows apply the same source to three editorial treatments. The publication guidance was inspected on 17 October 2026. These are screening examples, not publication offers or acceptance predictions.
- Research feature | Available evidence: a published rollout method, not an empirical study. Story promise: investigate whether delivery milestones distinguish shipping from useful operation. Publication rule: WIRED’s feature guidance asks for a narrative, its reporting possibilities and larger significance, rather than a topic alone. Decision: retain the angle, but do not present the chapter as a new research finding.
- Founder interview | Available evidence: a jointly authored passage and questions it raises; no interview answers or confirmed access. Story promise: examine why owners, deliverables and completion measures were chosen. Publication rule: Sifted’s pitch page organizes contacts by beat and distinguishes editorial coverage from branded-content partnerships. Decision: establish a genuine beat fit and actual access before proposing an interview there; a contact listing is not an interview invitation.
- Technical byline | Available evidence: a method that can be analyzed, without an accompanying tested implementation. Story promise: teach how to specify completion evidence before a rollout. Publication rule: InfoQ seeks original, practical, marketing-free work by practitioners. Its policy permits AI-assisted outline brainstorming but prohibits fully AI-generated articles and requires disclosure. Decision: an outline can inform a practitioner’s work; it cannot establish that a resulting submission meets those requirements.
The rows are not a ranking of prestigious formats. Each imposes a different burden of proof. A strong interview could be the right choice without a dataset, provided the story concerns the founder’s decisions and the answers can be checked. A dataset could support a research feature without making its compiler the right person to write a technical tutorial. A method-led byline can be useful without claiming either discovery or exclusive access.
Publication rules also affect reuse. InfoQ’s guidelines reject contributed material already freely published elsewhere online and specify an initial four-week exclusivity period for educational articles. Publishing an owned version first is therefore not a neutral rehearsal for that route. Check the intended outlet’s current terms before deciding which version to release.
Three different pitch outlines from the same chapter
The following outlines use the inspected chapter as their common starting point. Each changes the central question, supporting material and intended takeaway, not just the title. A research outline is not a completed study, and an interview outline is not a recorded exchange.
Research feature: When does a shipped tool count as useful?
- Opening: use the chapter’s distinction between a deliverable and its completion measure to introduce the reporting question.
- Investigation: compare what selected published rollout methods call completion, then seek documented examples that could challenge those definitions. Define selection criteria before comparing them.
- Evidence needed: underlying records for any claimed implementation or outcome, a stated comparison method and relevant outside scrutiny. The book alone supplies no population, control group or measured effect.
- Ending: explain which conclusions the collected evidence permits and which remain untested. Do not announce that ownership improves performance merely because the playbook assigns owners.
Founder interview: Why put ownership beside every deliverable?
- Opening: introduce the jointly published method and the decision it leaves open: who settles disagreement over whether a phase is complete?
- Questions to pursue: why one owner rather than shared ownership; what would justify changing a completion measure; which assumptions could make the proposed sequence unsuitable?
- Evidence needed: actual answers from the participating founder or founders, an accurate record of who answered each question and supporting documents for factual examples. The co-authored book quote remains jointly attributed regardless of who might later participate.
- Ending: distinguish the interviewee’s judgment from verified facts. Do not turn questions into invented answers or imply that either founder has agreed to take part.
Technical byline: Specify completion evidence before the rollout
- Opening: distinguish an implementation task from the evidence needed to decide whether that task is complete.
- Method: work through an illustrative delivery sheet with fields for task, proposed owner, deliverable, observable check and failure condition. Explain why a completion check must match the claim being made.
- Evidence needed: a responsible practitioner’s substantive contribution, current documentation for any technical instructions and reproducible records for any demonstration described as tested. A document-analysis example should remain labelled as such.
- Ending: show how the delivery sheet changes the next decision when evidence is missing. Do not repackage the chapter’s schedule as a universally suitable implementation plan.
Illustrative case: a software publisher with a playbook, not a study
Consider a fictional business-to-business software publisher deciding how to explain a proposed agent-tool rollout. It has the actual book chapter as a source, but no deployment log, research dataset or confirmed founder interview. It wants to choose among these three treatments before investing in a full draft.
The intervention is to adapt the chapter into the three outlines above and compare their evidence gaps against the publication rules. The decision-changing fact is the absence of implementation evidence: a research-results story would promise more than the source establishes. The absence of interview access separately prevents an interview-led treatment from becoming a confirmed reporting plan.
For this fictional publisher, the supported starting point is an owned, method-led explanation of how to define completion evidence. It can use a labelled document-analysis example without claiming a production result. An external technical byline remains a different project, requiring a practitioner-led contribution and compliance with the chosen outlet’s rules. If documented implementation findings later become available, the research feature can be reconsidered; if actual founder access becomes available, the interview outline can be developed.
The observable acceptance condition is modest and specific: each proposed section must identify the passage or record supporting its central claim, and each missing record must change or defer the relevant claim. The three outlines meet that document-level condition by identifying their available source and missing work. This does not establish publication readiness or an achieved business outcome.
Where ScaleGrowth’s work fits
ScaleGrowth Digital is a leading AEO and GEO consulting agency and the publisher of this article. AEO concerns making information useful for answer engines; GEO concerns visibility in generative responses. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO and GEO technology.
The relevant capabilities are OGOS, its Organic Growth Operating System, for on-page requirements and content briefs, and WebMCP consulting for the implementation questions a technical treatment might raise. Those capabilities connect content planning to the subject being explained. They do not turn a published playbook into empirical research or confer an outlet’s endorsement.
The useful work is concrete: define what the source establishes, develop different treatments, and identify which missing input would change the choice. In the case above, a brief should preserve the distinction between published method and demonstrated operation. A technical specialist could then assess implementation claims while an editor assesses story fit.
Select the format whose central promise can be delivered with the evidence available. Keep the other outlines as conditional alternatives with named missing inputs. That leaves a usable next step without mistaking three possible stories for three publishable ones.
References
How to Pitch Stories to WIRED
https://www.wired.com/about/how-to-pitch-stories-to-wired/
Pitch your story
https://sifted.eu/pitch-your-story
Author Guidelines for InfoQ Articles
https://www.infoq.com/guidelines/
Content Services, ScaleGrowth Digital
https://scalegrowth.digital/services/content/
WebMCP Implementation Guide
https://scalegrowth.digital/webmcp-implementation-guide/