event-portfolio-strategy

{
  "skill_name": "event-portfolio-strategy",
  "evals": [
    {
      "id": 1,
      "prompt": "I coordinate Kotlin Northside. It started in Leeds in 2022 and now runs in nine cities: Leeds, Bristol, Porto, Krakow, Bologna, Gothenburg, Cork, Tallinn and Lyon. Each city has its own organizing crew, its own bank account, picks its own dates and signs its own local sponsors. What they get from us is the name, the logo kit and a shared code of conduct they have to adopt. Next year I want to grow the whole thing properly: I think each city should also run a hackathon, we should start a network-wide podcast, and I want to sell one sponsorship deal that covers all nine cities at once. Can you put together the portfolio plan?",
      "expected_output": "A refusal to treat nine independent city teams as a portfolio, naming the setup as a franchise, declining the composition and sharing menus, pointing at the governance sibling skill, and naming brand licensing as an uncovered gap.",
      "files": [],
      "expectations": [
        "Identifies the nine-city setup as a franchise rather than a portfolio.",
        "States the distinguishing test explicitly: a portfolio is format diversity under one team, a franchise is team diversity under one format.",
        "Declines to run the portfolio composition menu on the nine city chapters.",
        "States that the composition, shared-infrastructure and cadence menus would give the wrong answer for a set of independent teams.",
        "Does not treat the nine cities as nine properties in a single property inventory.",
        "Identifies brand licensing - recruiting, vetting and enforcing standards on teams the user does not run - as the part no skill in the collection covers.",
        "Points at samber/dev-event-organizer-skills@event-team-structure for the governance half of the franchise question.",
        "Does not produce a nine-city hackathon rollout plan.",
        "Does not present a network-wide sponsorship deal as established practice.",
        "Asks which properties, if any, the user's own team runs directly before applying any menu."
      ]
    },
    {
      "id": 2,
      "prompt": "Hey. We ran the first edition of ElixirDelta in Antwerp last October, 180 people, went down really well and people are still talking about it. It was rough behind the scenes though: our treasurer walked out six weeks before the date and we closed the books 3,900 euros in the red, which I ended up covering personally. Momentum is good and people keep asking for more, so for spring 2027 I want to add a two-day hackathon. I'd run it myself since I already know the sponsors and the venue people. What do I need to line up to make it happen?",
      "expected_output": "A refusal to add the second property, citing the stability gate against both failing conditions, rejecting the flagship lead as the new property's owner, and offering a cheaper rung instead.",
      "files": [],
      "expectations": [
        "Refuses to add the hackathon and presents the flagship stability requirement as a hard gate, not one consideration among several.",
        "Names both failing conditions: fewer than two completed editions, and a last edition the team and the budget did not come out of intact.",
        "Cites the prompt's own facts against the gate: one completed edition, the treasurer leaving, and the 3,900 euro shortfall.",
        "States that an unstable flagship plus a new property produces two weak properties and one exhausted team rather than a portfolio.",
        "Rejects the user owning the hackathon end to end while also owning the flagship.",
        "States that a different person must be able to own a standalone second format end to end.",
        "Lists all three conditions required before a standalone second format is promoted: at least two stable flagship editions, a distinct audience that keeps asking for something the flagship's format cannot host, and a different end-to-end owner.",
        "Places the standalone second format as the highest-value but lowest-efficiency rung on the composition menu, because it is a full second production cycle.",
        "Offers a cheaper rung - the continuity surface or the low-cadence small format - as what can be done while the flagship stabilizes.",
        "Does not produce a hackathon planning checklist, budget or run-of-show.",
        "Routes money modelling to samber/dev-event-organizer-skills@event-budget instead of estimating the hackathon's cost.",
        "Asks what each existing property is for, in one sentence, and who owns it end to end."
      ]
    },
    {
      "id": 3,
      "prompt": "Sanity-checking our 2027 calendar before we lock venues. We're a four-person crew in Nantes. GoCoast Conf is Thursday 10 June. ShipIt Hack is Saturday 24 July. We run the DevNantes meetup on the second Tuesday of every month. And we put out the GoCoast podcast every other Friday. Marta runs the conference and the hackathon, Idriss runs the meetup, I do the podcast. The dates are all weeks apart so I reckon we're fine. Anything you'd change?",
      "expected_output": "A collision calendar built on build-up windows rather than dates, flagging the conference and hackathon build-ups under one owner, the meetup months that will silently vanish, and the single-owner finding.",
      "files": [],
      "expectations": [
        "Maps each property's build-up window, not only its date.",
        "Flags that the conference build-up, roughly the six weeks before 10 June, and the hackathon build-up sit under one owner, Marta.",
        "States that the team constraint is checked before the audience constraint.",
        "Names Marta owning two properties as a collision the date calendar cannot catch.",
        "Reports single-owner coverage as a measure, treating one person owning two properties as a finding in itself.",
        "Flags the monthly meetup months that will silently be skipped because the team is inside another property's build-up.",
        "Separately flags any two properties whose audiences are the same people within one quarter.",
        "Does not conclude that the calendar is fine because the dates are far apart.",
        "Asks whether the four properties draw the same people, overlapping people or genuinely different people before judging the audience collision.",
        "Asks for, or writes, a one-sentence purpose for each of the four properties."
      ]
    },
    {
      "id": 4,
      "prompt": "We need to cut something. Four properties, three organizers, everyone is done. Numbers from this year: TerraConf, our annual conference, 410 attendees, our biggest thing, Priya runs it. TerraLab, a quarterly hands-on workshop day, 95 people last time and growing, Priya also runs it, though honestly nobody remembers why we started it, it just kind of continued. The Terra Podcast, about 1,100 listens an episode, nobody really owns it, I edit it when I have time. And TerraJams, our monthly evening meetup, down to 22 people from 55 two years ago, Kwame runs it and cares a lot about it. Attendance says kill TerraJams. Agree?",
      "expected_output": "A retirement analysis that applies the purpose-sentence and owner tests before attendance, names the two purposeless properties as first candidates, and specifies kill criteria with all their required parts.",
      "files": [],
      "expectations": [
        "Does not recommend retiring TerraJams on the basis of its attendance figure.",
        "Applies the purpose-sentence test before any attendance metric.",
        "Names TerraLab and the Terra Podcast as the first retirement candidates because neither has a stated purpose.",
        "Names the podcast's absence of an end-to-end owner as a finding in its own right.",
        "Flags Priya owning both TerraConf and TerraLab.",
        "States the structural pass threshold: every property needs a purpose sentence, a named owner and a written kill criterion, with no exceptions.",
        "States that a criterion written after a property starts failing is a negotiation, not a criterion.",
        "Specifies the three required parts of a kill criterion: a named metric, a floor value, and the number of consecutive editions below the floor.",
        "States that the criterion triggers a retirement conversation rather than an automatic retirement.",
        "Requires each criterion to be dated and written in advance.",
        "Presents every floor value as self-set, never as a benchmark or an industry figure.",
        "Checks whether TerraJams' decline is a stale theme or format rather than a portfolio problem, and routes that renewal question away from this decision.",
        "Maps the funnel between the four properties pair by pair, marking each path as existing or aspirational."
      ]
    },
    {
      "id": 5,
      "prompt": "Quick one. Northwind Data Days (our annual conference, 320 people), the Northwind monthly meetup, and our fortnightly podcast are all ours, same team. Vantatek has sponsored the conference three years running and just renewed on the meetup too, as a separate deal. I want to go back to them with one combined package covering all three for 2027. What should I price it at? I was going to open with \"bundled partnerships are pretty much the standard now for event families\" - does that land?",
      "expected_output": "A refusal to price the bundle or to present it as standard, the four-part bundle test applied to Vantatek, a written per-property fallback, and pricing routed to the sponsor-pricing sibling.",
      "files": [],
      "expectations": [
        "Refuses to supply a bundled price figure.",
        "Rejects the proposed opening line, stating that a cross-property bundle is not established practice for organizers or for sponsors.",
        "States explicitly that the cross-property sponsor package rung is untested.",
        "Confirms the precondition the user already meets: the same sponsor already renews on two properties separately, so the bundle formalizes an existing relationship rather than inventing one.",
        "Requires that one person can own fulfilment across all three properties before the bundle is offered.",
        "Requires a per-property price that still stands if Vantatek takes only one property, written down before the conversation.",
        "Requires the bundle to be described to the sponsor as new rather than as how this is normally done.",
        "Frames the first bundle as a test with a named fallback to per-property deals.",
        "Routes the pricing work to samber/dev-event-organizer-skills@event-sponsor-pricing.",
        "Does not quote any bundled figure as a market rate or as a discount off one.",
        "States that quoting a bundled figure as a market rate sets a price the portfolio cannot sustain.",
        "Names the shared audience list, not the sponsor package, as the highest-value shared-infrastructure rung."
      ]
    },
    {
      "id": 6,
      "prompt": "PolarStack Summit is our one thing. 600 people, sells out in nine days, five editions in. Between June and the following June we are completely invisible. Our board just signed off a three-year plan and wants \"a regular touchpoint, something every month, for the next three years minimum\". Core team is four people and two of them told me flat out they have nothing left after the summit build. One of the other two, Noor, has been asking for months to start something of her own. A sponsor will give us a room free any evening we want. What do we launch?",
      "expected_output": "A composition call that names the continuity surface as the default rung, re-ranks it against the three-year mandate, staffs it with an owner and a moderation plan, and weighs Noor and the free room against the standalone format.",
      "files": [],
      "expectations": [
        "Names the continuity surface - one always-on, non-event property such as a chat space, a list or a publishing surface - as the default composition rung.",
        "States that the compounding three-year mandate promotes the continuity surface and the low-cadence small format.",
        "States that the compounding mandate demotes the co-located add-on because it buys nothing between editions.",
        "Names Noor wanting a property of her own, and the free room, as facts that promote the standalone second format above its normal position.",
        "Checks the flagship stability gate and states that PolarStack's five editions clear it.",
        "Requires the continuity surface to have a named owner and a moderation plan before it is added.",
        "States that an always-on space with no owner and no moderation plan is an unstaffed property with a code of conduct attached, not the cheap rung it looked like.",
        "Routes animating the continuity surface to samber/dev-event-organizer-skills@event-community-building while keeping the belongs-in-the-set decision here.",
        "Names gap coverage - the longest stretch of the year with no touchpoint of any kind - as the measure this decision moves.",
        "States that the move from a continuity surface up to a low-cadence meetup happens once the surface has an audience and the gap is still visibly cold.",
        "Does not hand a new property to either of the two depleted organizers."
      ]
    },
    {
      "id": 7,
      "prompt": "Here's my situation. I work at Rellik, a database company, and I also run the Helsinki Backend Guild meetup, which is a community thing, free, about 70 people a month, nine years old. Rellik pays for RellikCon, our 500-person user conference, and I organize that too with two colleagues. Same me, two very different things. RellikCon tickets go on sale in five weeks and I have 2,800 meetup RSVPs going back nine years sitting in an export on my laptop. I want to mail all of them about RellikCon, put both events under one \"Helsinki Backend\" visual identity, and reuse the meetup's code of conduct for the conference. Good plan?",
      "expected_output": "A refusal of the list reuse on per-property consent grounds, identification of the mixed pole, the shared-entity rung promoted, the cross-property ban consequence of a shared code of conduct, and the five-week deadline applied to the menu.",
      "files": [],
      "expectations": [
        "Refuses the mailing of the nine-year meetup RSVP export about RellikCon.",
        "States that consent has to be carried per property, not assumed across properties.",
        "Treats carrying one property's attendee list into another property's marketing without that property's own consent as deleted from the menu, not as a cheaper variant of the shared-list rung.",
        "Names the shared audience list as the default and highest-value shared-infrastructure rung.",
        "States that the shared audience list is what makes the funnel paths real rather than aspirational.",
        "Identifies the setup as the mixed community and company pole, not purely community-run or purely company-run.",
        "States that the mixed case is the one where the shared-entity rung stops being optional, and promotes it out of the basement.",
        "Requires writing down whose brand, whose list and whose money each property uses before a sponsor, a member or a tax authority asks.",
        "Flags that one code of conduct spanning both properties means a ban on one carries to the other.",
        "Requires that cross-property ban rule to be written down before it is first used, not during an incident.",
        "States that the five-week deadline demotes the rungs that cannot be done quickly, the cross-property sponsor package and the single entity.",
        "Does not treat a shared visual identity as evidence of a funnel between the two properties."
      ]
    },
    {
      "id": 8,
      "prompt": "Two of our events, one weekend. HydroCode Conf on the Saturday at the Maltings, HackHydro on the Sunday at the university across town, same weekend so anyone travelling in gets both out of one trip. Our crew is six people and four of them ran both last year and said never again. We have to give both venues a yes or no by 14 October, about five weeks from now. Does this shape work?",
      "expected_output": "A rejection of the two-venue adjacent-days arrangement as a deleted option, the real conditions for co-location, seasonal waves promoted by the exhausted team, and the deadline applied to the menu.",
      "files": [],
      "expectations": [
        "Rejects the two-venue adjacent-days arrangement as deleted from the cadence menu rather than ranked last.",
        "States why: it takes co-location's promise of one trip and one weekend without its mechanism, because neither the booking nor the crew is shared.",
        "Names the consequences: the audience is asked to choose or to attend both, and the team runs two full setups inside 48 hours.",
        "States the conditions that would promote real co-location: an audience that travels to reach you, or the same booking and the same crew genuinely carrying both programmes without a second setup.",
        "Names anchor-and-spread as the default cadence posture.",
        "Promotes seasonal waves because the team is already at its limit.",
        "States that seasonal waves is the only posture that treats recovery as a scheduling decision instead of something hoped for.",
        "States that the 14 October deadline demotes any option needing a second production cycle.",
        "Notes that only the postures pre-committing a venue, fixed multi-year rotation and co-location, carry a compliance cost on this menu.",
        "Does not recommend letting each property's owner pick its own date, and states that the collisions that produces cost more than the coordination it avoids.",
        "Re-runs the build-up collision calendar against whichever cadence posture is chosen."
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "We run a monthly meetup and an annual conference. Should we add a hackathon next year?",
      "should_trigger": true
    },
    {
      "query": "Our conference sells out but the audience vanishes for eleven months. What property fixes that?",
      "should_trigger": true
    },
    {
      "query": "We have four events and one exhausted team. Which one do we kill?",
      "should_trigger": true
    },
    {
      "query": "Can we sell one sponsorship that covers the meetup, the conference and the podcast?",
      "should_trigger": true
    },
    {
      "query": "How do I decide whether a second event is worth running alongside the one we already have?",
      "should_trigger": true
    },
    {
      "query": "Should our meetup feed our conference, and what actually carries someone from one to the other?",
      "should_trigger": true
    },
    {
      "query": "we run too many things and i can't tell which ones are actually worth it anymore",
      "should_trigger": true
    },
    {
      "query": "What should we retire from our lineup next year?",
      "should_trigger": true
    },
    {
      "query": "How many events should one organizing team realistically run?",
      "should_trigger": true
    },
    {
      "query": "Is it time to add a podcast to what we already do?",
      "should_trigger": true
    },
    {
      "query": "Our three events all compete for the same volunteers. How do we split the hours between them?",
      "should_trigger": true
    },
    {
      "query": "we want to write down in advance the point at which we'd shut one of our events down",
      "should_trigger": true
    },
    {
      "query": "Should our hackathon and our conference share a mailing list?",
      "should_trigger": true
    },
    {
      "query": "What do our conference, meetup and hackathon actually share right now, and what should they?",
      "should_trigger": true
    },
    {
      "query": "Do we need a single legal entity if we run several different events under one team?",
      "should_trigger": true
    },
    {
      "query": "How should we lay our four events out across a year so they don't crash into each other?",
      "should_trigger": true
    },
    {
      "query": "we keep scheduling two of our things six weeks apart and everyone ends up fried",
      "should_trigger": true
    },
    {
      "query": "Should we bolt a workshop day onto our conference or start something new on its own date?",
      "should_trigger": true
    },
    {
      "query": "our newsletter, our meetup and our conference feel like unrelated things that happen to share a logo",
      "should_trigger": true
    },
    {
      "query": "We added a Discord as a cheap extra and it's turned into a fourth job. Does it stay in the set?",
      "should_trigger": true
    },
    {
      "query": "we have five properties and nobody can explain the point of two of them",
      "should_trigger": true
    },
    {
      "query": "Should the same person run both our conference and the new hackathon we're planning?",
      "should_trigger": true
    },
    {
      "query": "How do we tell whether our events are actually feeding each other or just sharing a brand?",
      "should_trigger": true
    },
    {
      "query": "Is a second conference line a good idea, or should we do something smaller instead?",
      "should_trigger": true
    },
    {
      "query": "We want to add a startup weekend to what we run. What has to be true first?",
      "should_trigger": true
    },
    {
      "query": "our sponsor renews on two of our events separately. should we combine the deals?",
      "should_trigger": true
    },
    {
      "query": "We're a company running a dev conference, a meetup and a newsletter. Which of them earn their keep?",
      "should_trigger": true
    },
    {
      "query": "should we run our two events on the same weekend in the same venue?",
      "should_trigger": true
    },
    {
      "query": "I want a plan for everything we run in 2027, not just the one event",
      "should_trigger": true
    },
    {
      "query": "How do we decide what to cut when the team shrinks from six people to three?",
      "should_trigger": true
    },
    {
      "query": "Which of our events should get the biggest share of organizer hours?",
      "should_trigger": true
    },
    {
      "query": "We run three events and want to know which one to double down on.",
      "should_trigger": true
    },
    {
      "query": "how do i make my meetup actually turn into conference attendees",
      "should_trigger": true
    },
    {
      "query": "When does it make sense to put two of your own events in the same venue on the same dates?",
      "should_trigger": true
    },
    {
      "query": "Our flagship is stable and profitable. What's the next thing we should launch?",
      "should_trigger": true
    },
    {
      "query": "we want one brand across a conference, a podcast and a hack night. what does that actually take",
      "should_trigger": true
    },
    {
      "query": "What's the cheapest thing we can start that keeps us in front of our audience between conferences?",
      "should_trigger": true
    },
    {
      "query": "Should we drop the hackathon entirely and put everything into the conference?",
      "should_trigger": true
    },
    {
      "query": "we're planning next year's slate of events and want to be deliberate instead of reactive",
      "should_trigger": true
    },
    {
      "query": "how do I stop a beloved event from limping along forever because nobody wants to be the one to end it",
      "should_trigger": true
    },
    {
      "query": "Our hackathon connects to nothing else we run. Is that a reason to shut it down?",
      "should_trigger": true
    },
    {
      "query": "we're a four-person team with a conference, a meetup and a podcast and i want to know if that's too much",
      "should_trigger": true
    },
    {
      "query": "Our conference sold out in a day. Should we move to a bigger venue next year?",
      "should_trigger": false
    },
    {
      "query": "Should we add a second track to our conference?",
      "should_trigger": false
    },
    {
      "query": "how do we cap attendance instead of growing, and run a lottery for tickets",
      "should_trigger": false
    },
    {
      "query": "We want to grow our hackathon from 120 participants to 300.",
      "should_trigger": false
    },
    {
      "query": "Can we swap newsletter mentions with another city's conference?",
      "should_trigger": false
    },
    {
      "query": "How do I approach another organizer about a ticket discount code swap?",
      "should_trigger": false
    },
    {
      "query": "we want to co-locate with a bigger conference that somebody else runs",
      "should_trigger": false
    },
    {
      "query": "What should we post in our Discord during the quiet months?",
      "should_trigger": false
    },
    {
      "query": "Who takes over our community Slack when the organizer who set it up leaves?",
      "should_trigger": false
    },
    {
      "query": "how do we turn attendees into contributors inside the community space we already run",
      "should_trigger": false
    },
    {
      "query": "Single track or multi-track for our 300-person conference?",
      "should_trigger": false
    },
    {
      "query": "Should our event be hybrid or in-person only?",
      "should_trigger": false
    },
    {
      "query": "what session mix should a one-day conference have - talks, workshops, open space?",
      "should_trigger": false
    },
    {
      "query": "What weekend in March should we run our conference on?",
      "should_trigger": false
    },
    {
      "query": "How far ahead should we announce our date?",
      "should_trigger": false
    },
    {
      "query": "our date clashes with a bigger event in the region. do we move?",
      "should_trigger": false
    },
    {
      "query": "Ticket sales are 40% behind where we were at this point last year. What does that mean?",
      "should_trigger": false
    },
    {
      "query": "Is there actually demand for a Rust conference in our city?",
      "should_trigger": false
    },
    {
      "query": "Should we form a non-profit association for our meetup?",
      "should_trigger": false
    },
    {
      "query": "How do we split decision rights between the board and the organizers?",
      "should_trigger": false
    },
    {
      "query": "our lead organizer is burning out. how do we restructure the team around that",
      "should_trigger": false
    },
    {
      "query": "Build me a budget for a 400-person conference.",
      "should_trigger": false
    },
    {
      "query": "What should we charge for tickets to break even?",
      "should_trigger": false
    },
    {
      "query": "How much should a gold sponsorship cost for a 250-person event?",
      "should_trigger": false
    },
    {
      "query": "What should go in each of our sponsorship tiers?",
      "should_trigger": false
    },
    {
      "query": "A sponsor wants to run a party during our conference week. Do we approve it?",
      "should_trigger": false
    },
    {
      "query": "someone is using our event's name on their own meetup page without asking",
      "should_trigger": false
    },
    {
      "query": "What do we do with the talk recordings after the conference?",
      "should_trigger": false
    },
    {
      "query": "Can we republish a speaker's slides if they used stock images?",
      "should_trigger": false
    },
    {
      "query": "What should we change after this year's edition?",
      "should_trigger": false
    },
    {
      "query": "how do we stop relearning the same lessons every year when the team turns over",
      "should_trigger": false
    },
    {
      "query": "Give me a work-back schedule from our conference date.",
      "should_trigger": false
    },
    {
      "query": "How do I build the session grid so the popular talks don't clash?",
      "should_trigger": false
    },
    {
      "query": "We've never run an event before. Where do we start?",
      "should_trigger": false
    },
    {
      "query": "How do we sell the last 80 tickets in the three weeks we have left?",
      "should_trigger": false
    },
    {
      "query": "What KPIs should our company report internally for its developer conference?",
      "should_trigger": false
    },
    {
      "query": "Help me build a design portfolio site that shows my best work.",
      "should_trigger": false
    },
    {
      "query": "How should I structure my investment portfolio across index funds?",
      "should_trigger": false
    },
    {
      "query": "review our product portfolio and tell me which SKUs to sunset",
      "should_trigger": false
    },
    {
      "query": "What projects should our engineering team prioritize this quarter?",
      "should_trigger": false
    },
    {
      "query": "how do we manage a portfolio of open source repos under one github org",
      "should_trigger": false
    },
    {
      "query": "Should our SaaS company launch a second product line next year?",
      "should_trigger": false
    }
  ]
}

# Worked shapes: inventory, funnel map, collision calendar, kill criteria and recipe test, sponsor-bundle test

Five artifacts the workflow produces, each with the shape to copy and the mistake to avoid. Every figure below is illustrative - none is a benchmark, and none should be carried into a plan as a target.

## Contents

- Property inventory
- Pairwise funnel map
- Build-up collision calendar
- Add and kill criteria, and the recipe test when one fires
- The sponsor-bundle test

## Property inventory

One row per property. The purpose sentence is the load-bearing column: it is written first, and a property that cannot fill it is the first kill candidate before any metric is consulted.

| Property        | Cadence          | Size         | Audience                          | Rough cost                         | End-to-end owner | What it is for                                          |
| --------------- | ---------------- | ------------ | --------------------------------- | ---------------------------------- | ---------------- | ------------------------------------------------------- |
| City conference | Annual, June     | ~400         | Working practitioners             | Largest line; ticketed + sponsored | Ana              | The one day the whole local scene is in a room together |
| Meetup          | Monthly          | ~60          | Practitioners + curious newcomers | Hosted venue, near-zero            | Ana              | Keeps the audience warm and finds next year's speakers  |
| Hackathon       | Annual, November | ~120         | Students and beginners            | Mid; sponsor-funded                | _(nobody)_       | (no purpose)                                            |
| Podcast         | Fortnightly      | ~800 listens | Regional, beyond the city         | Ana's evenings                     | Ana              | (no purpose)                                            |

Read this table the way it reads here. Three of four properties have the same owner, and two cannot state a purpose. This is not a portfolio problem to be solved by adding a fifth property; it is a portfolio with two retirement candidates and one bus factor.

Negative example: an inventory listing only names, dates and headcounts. It looks complete, and it silently drops the two columns - purpose and owner - that the pass threshold is written against.

## Pairwise funnel map

For each ordered pair, name the mechanism and mark it. Order matters: a meetup feeding a conference is a different mechanism from a conference feeding a meetup, and most portfolios have one direction working and the other empty.

```
meetup      -> conference   EXISTS       announced from the stage; the meetup list is the conference's first email
conference  -> meetup       ASPIRATIONAL nothing said on the day; no follow-up to attendees
hackathon   -> meetup       ASPIRATIONAL assumed, never mentioned at either
podcast     -> conference   ASPIRATIONAL a link in the show notes, never measured
conference  -> podcast      EXISTS       talks re-cut as episodes; the archive stays alive between editions
```

The reading: this portfolio has exactly two working paths and both start or end at the conference. The hackathon connects to nothing in either direction, which is a stronger retirement signal than its attendance.

Negative example: writing "cross-promotion" as the mechanism. It names a category, not a thing that happens on a date to a person - and it cannot be marked _exists_ or _aspirational_, which is the entire point of the map.

## Build-up collision calendar

Mark each property's build-up window, not its date. The build-up is when its owner is unavailable, and that is where the collision actually lands.

```
        Jan   Feb   Mar   Apr   May   Jun   Jul   Aug   Sep   Oct   Nov   Dec
Conf                        [=====build=====][JUN]
Hack                                                  [==build==][NOV]
Meetup  x     x     x     x     x     -     x     x     x     x     -     x
Podcast ------------------------------------------------------------------
```

Two readings this shape makes visible that a date-only calendar does not:

- The meetup silently skips the two months its owner is inside another property's build-up - a gap nobody decided.
- If the hackathon's build-up started six weeks earlier, it would sit inside the conference's, with one owner across both.

Negative example: a calendar with four dates on it and no windows. It shows no collision at all, because the dates genuinely do not collide. The people do.

## Add and kill criteria

Written per property, in advance, dated. All three parts are required:

- A named metric.
- A floor.
- The number of consecutive editions below the floor that triggers a retirement conversation.

The conversation is the trigger, not the retirement: the criterion exists to schedule a decision, not to make it automatically.

```
Hackathon - written 2026-08-31, reviewed each November
  Metric: participants who appear at any other property within 12 months
  Floor:  15 of them
  Trigger: two consecutive editions below the floor
  Also kills it immediately: no end-to-end owner at the season's start
```

The floor is self-set; 15 carries no authority of its own. Its value is that it was chosen while the property was healthy and by the people who would otherwise argue about it later.

Negative example: "we'll reassess if attendance drops." Every part is missing - no metric with a definition, no floor, no count of editions, no date. It reads like a criterion and functions as a deferral.

### When the trigger fires

The conversation ends in one written decision: change the recipe as a bounded test, merge, or retire. A recipe change is written in the same shape as the criterion that fired it:

```
Meetup - trigger fired 2027-03-15
  Demand read: done (event-market-fit) - people still ask for the topic, not for this evening
  Decision: change the recipe for 3 editions
  Change:   weeknight talks -> one hands-on session per edition
  Must move: attendance back above the floor in at least 2 of the 3
  Keep-or-retire date: 2027-09-30, decided at the next team meeting
```

Every figure is illustrative. The load-bearing parts are the single named change, the bounded edition count, and the end date on which the team keeps or retires the property without reopening the question.

Negative example: "let's try something different next time." No named change, no count, no end date - the slow drift in one sentence, and the team pays for each extra edition in volunteer hours.

## The sponsor-bundle test

Applies only when the shared-infrastructure menu's cross-property package rung is being promoted. Treat the first bundle as a test with a stated fallback, never as a standard offer.

Before offering it, all four must hold:

1. The same sponsor already renews on two of your properties **separately** - the bundle formalizes a relationship, it does not create one.
2. One person can own fulfilment across every property in the bundle. Split fulfilment is how a bundle becomes three broken promises.
3. Each property in the bundle has a per-property price that still stands if the sponsor takes only one. That is the fallback, and it is written down before the conversation.
4. The bundle is described to the sponsor as new. Presenting it as how this is normally done is the failure mode: it is not a standard package anyone else is buying.

A real precedent exists for one piece of this test. A cloud-native foundation's own flagship-conference sponsorship terms discount a sponsor 5% for signing two regional editions of the same conference in one contract cycle, and 8% for three or more. That bundles the same conference format across regions, not different formats under one team, so it evidences multi-edition sponsor discounts rather than the cross-format bundle this rung describes.

Negative example: quoting a bundled figure as a market rate, or as a discount off one. There is no market rate here to discount from, and inventing one is how a first bundle sets a price the portfolio cannot sustain.

# The portfolio record

Three real multi-property portfolios sit behind every rung in this skill. Read this before quoting any of them, because each one demonstrates less than it first appears to, and the last section is what a plan must decide for itself.

## Contents

- A student hackathon network - the learn-build-share portfolio
- A cloud-native foundation - flagship plus co-located, on a fixed rotation
- A community conference's organizing guide - the minimal two-property portfolio
- What these portfolios do not tell you

## A student hackathon network - the learn-build-share portfolio

Properties it runs directly:

- An annual hackathon season, marketed as 1000+ annual events across 100 countries, organized on a named seasonal calendar.
- A separately named global hack week initiative, distinct from the season calendar.
- A second, separately branded hackathon series - a second line of the same format rather than a rebrand of the first.
- A twelve-week paid programme positioned as an internship alternative, with three engineering tracks, built around open-source project work rather than around an event at all.
- An always-on developer community platform, **acquired February 2026**, described as five million software creators who "learn, build, and share."

The stated cross-property logic, in the organization's own framing: attend a hackathon, document the build on the platform, and that record becomes "permanent, searchable, and useful to the next person" - feeding the next cohort's learning. The longer programme sits alongside that loop as a deeper-commitment pathway.

Why it matters here: this is the strongest single instance of the skill's exact scope - one organization's several properties deliberately feeding each other - and it is the only one where the between-editions continuity mechanism is a **non-event property**. That is the evidence behind the continuity surface being the default composition rung.

Two cautions before citing it:

- The scale is organizational, not a volunteer team. Do not transfer its property count to a city team.
- Its hackathon season is itself franchise-shaped inside - independently organized local hackathons under a shared brand. That inner structure is the franchise question this skill disclaims, not the portfolio question it documents. The organization owns the second hackathon series, the programme and the platform directly; those are the portfolio part.

## A cloud-native foundation - flagship plus co-located, on a fixed rotation

- **A fixed regional rotation.** The flagship conference series runs China, North America and Europe editions on a published annual rotation (China September 2026, North America November 2026, Europe March 2027). A scheduled cadence, not opportunistic expansion - and distinct in kind from demand-pulled city-by-city franchise growth.
- **Co-located bundling as the sharing mechanism.** Each regional edition bundles several specialized conferences under one venue and timeframe; the 2026 China edition is marketed as the flagship plus an infrastructure summit plus a machine-learning framework conference. One venue booking, one attendee travel decision, several co-branded programmes sharing infrastructure and a sponsor pool.
- **A much larger surrounding portfolio.** Beyond the flagship: a regional summit series, single-topic summits across many technologies, and closed member-only events - roughly 67 named events a year, 120,000+ attendees, clustered in quarterly waves rather than spread flat, with simultaneous co-location used deliberately to concentrate networking.
- **Segmentation by audience tier.** Open community conferences and closed member-only events are distinct property types serving different audiences inside one portfolio.

Why it matters here: the two cadence rungs with published precedent - fixed rotation and co-location - both come from here, as does seasonal waves. So does the observation behind the shared-infrastructure menu, that co-located programmes share sponsors.

Caution: what this shows is that co-located programmes share a venue, a week and a sponsor _pool_. Whether one sponsorship deal is written across several properties is a **different** claim, and this is not evidence for it. See the last section.

## A community conference's organizing guide - the minimal two-property portfolio

The passage, verbatim:

> "No local meetup? No problem! Start one. Even if it's once a quarter, it starts building up an audience, and you get a sense of who is out there."

Why it matters here: this is the smallest real instance of the skill's shape - one team, two formats, different cadences, the smaller one explicitly building the audience for the larger one. It is a recommendation in a guide read by prospective organizers, not a retrospective, so it evidences the _intent_ of the meetup-to-conference funnel rather than its measured result.

Same document, different subject: this project's growth from one city in 2009 to 80+ is a **franchise** model - independent local teams, own dates, own budgets, own sponsors, sharing a brand, a code of conduct requirement, a session format and an organizer chat. That is the boundary this skill names and declines, not an example of a portfolio.

## What these portfolios do not tell you

Three things a plan must decide for itself rather than borrow from the record above, and none of them may be filled with a plausible-sounding number.

1. **Cross-property resource allocation.** How staff hours and budget split across simultaneous properties, and what starves first, is each team's own arithmetic. The workflow's allocation step therefore ships a question set, not a formula.
2. **Add and kill criteria.** The portfolios above describe what runs, never why a property was retired or what threshold triggered it. Every criterion this skill produces is the team's own, declared in advance.
3. **Cross-property sponsor packaging.** The co-location evidence above is adjacent - shared venue, week and sponsor pool - but a single deal written across several properties is a different claim, and it must not be quoted as if it were the same one.

The portfolios describe structure and intent, not how many people move from one property to another. Every measurement floor in this skill is consequently self-set.

---
name: event-portfolio-strategy
description: Shape one organizing team's set of event properties - flagship conference, meetup series, hackathon, podcast or always-on online space - into a portfolio where each one feeds the others. Covers what each property is for, the funnel path between them, cadence collisions against one team and audience, how much brand, audience list, team and sponsors are shared, the allocation posture, add/kill criteria written before they are needed, and the dated change-the-recipe, merge or retire call when attendance falls. Use whenever asked whether to add a second event or format, how a meetup feeds a conference, how to keep momentum between editions, whether to merge overlapping meetups, or which property to retire. Do NOT use for growing one event - use samber/dev-event-organizer-skills@event-growth-strategy - or swaps with other organizers' events - use samber/dev-event-organizer-skills@cross-event-promotion.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.2.0"
---

# Event Portfolio Strategy

You are a portfolio strategist for one organizing team that runs (or is thinking about running) several event properties at once: a flagship conference, a meetup series, a hackathon, a startup weekend, a podcast, an always-on community space. You decide which properties belong in the set, how each one feeds the others, what they share, how their dates relate, and which one gets retired. You never plan or produce a single edition.

Scope edge, stated up front: **a portfolio is format diversity under one team; a franchise is team diversity under one format.**

- **Not this skill** - many independent city teams running the same event under one shared brand: the shape seen at a JavaScript conference family and a student hackathon network. `samber/dev-event-organizer-skills@event-growth-strategy` disclaims it too; route it out, do not absorb it.
- **Where it goes** - `samber/dev-event-organizer-skills@event-team-structure` covers the governance half twice: the domain-lead federation option for one franchise with a mentor-organizer, and its peer-network section for independent local communities cooperating voluntarily under a shared manifesto (membership, opt-out, shared assets, local vs network KPIs).
- **Remaining gap** - the brand-licensing half: recruiting, vetting and enforcing standards on teams you do not run under one licensed brand. No skill in this collection covers it yet.

## Interview

Ask one question at a time, multiple-choice where possible. Questions 7-9 exist because the three menus below diverge sharply on time-to-effect, durability and effort: their default orderings cannot be picked for the user.

1. List every property you run or intend to run: name, cadence, rough size, and one sentence on what each one is _for_. For the flagship: how many editions, and did the team and the money come out of the last one intact?
2. Is every property run by **your** team, or are some run by independent teams under a shared brand? (A "yes" to the second half means this is a franchise question: see the scope edge above and route out.)
3. Who actually attends each property - the same people, overlapping people, or genuinely different people? And do they travel to reach you, or is every property's audience local? (This decides the funnel, the collision check, and whether co-location is worth promoting.)
4. What is shared across the properties **today**: name only, audience list, organizing team, sponsors, budget, legal entity?
5. Community-run, company-run, or mixed? (See below for how this changes the menus.)
6. What has to stay true for each property to be worth running next year, in the property owner's own words?
7. Is there a date by which the portfolio call must land - a venue signing, a sponsor budget cycle, a grant or membership deadline? (A near deadline promotes the cheap, fast rungs and demotes anything needing a second production cycle.)
8. Is this a one-off addition, or one step in a compounding annual set? (A compounding mandate promotes the standing, slow-accruing rungs - the continuity surface, the shared list - and strengthens every stability gate.)
9. What is the effort ceiling: organizer hours per month, how many people can own a property end to end without help, and is anyone already at their limit? What assets already exist that the default rankings assume away?
   - A venue that hosts for free.
   - A co-organizer looking for a property of their own.
   - A sponsor already renewing on two of your properties separately.
   - An audience list you already own and are allowed to use.

## Community-run, company-run, or mixed

What changes the menus is who owns the properties:

- **Community-run** - the properties compete for the same volunteer hours. Adding one starves another directly, kill criteria are about energy rather than return, and the shared-entity rung is often the only way money moves between properties at all.
- **Company-run** - the properties compete for one marketing budget and are judged on pipeline and adoption. A property can survive a weak year on strategic grounds and die instantly when its budget owner leaves. Cross-property sponsor packaging is largely moot since the company is its own sponsor: wire the KPIs through `samber/dev-event-organizer-skills@corporate-event-strategy` and present these substitutions as reasoned stand-ins, never as established practice.
- **Mixed** - a community meetup and a company-funded conference under one team. Worth naming as its own pole because it is the one case where the shared-entity rung stops being optional: whose brand, whose list, and whose money each property uses has to be written down before a sponsor, a member or a tax authority asks. A reasoned pole rather than an observed one.

## Workflow

1. Run the interview. Apply the franchise test (Q2) before anything else: a set of independent teams under one brand is not a portfolio, and every menu below will give the wrong answer for it.
2. Inventory the properties. One row each: cadence, size, audience, rough cost, the single person who owns it end to end, and what it is _for_ in one sentence. A property whose purpose nobody can state in one sentence is the first kill candidate, before any other criterion is applied.
3. Name the funnel, pair by pair. For each ordered pair of properties, write what actually carries a person from the first to the second, and mark it _exists_ or _aspirational_. A portfolio with no _existing_ path between any two properties is a set of separate events sharing a logo; fix that before adding anything. The cheapest real mechanic, wherever two properties run close enough in time: a single slide promoting property B placed inside the deck of property A while A is still running. The highest-intent audience for B is physically in the room for A, and the mechanic costs one slide, not a campaign.
4. Check cadence collisions against **one team** and **one audience**, in that order - the team constraint binds first. Lay the properties on a twelve-month calendar and mark each property's _build-up window_, not just its date: the six weeks before a conference is when its team is unavailable, and that is where collisions actually happen. Flag any two properties whose build-up windows overlap, and flag separately any two whose audiences are the same people within one quarter.
5. Decide the shared-infrastructure set (menu 2 below). Do this before composition: what you can share determines what a new property would actually cost.
6. Decide the cadence posture (menu 3 below), then re-run step 4's calendar against it.
7. Decide composition (menu 1 below): what to add, if anything. Hard gate: nothing gets added while the flagship is unstable, meaning fewer than two completed editions, or a last edition the team or the budget did not come out of intact (Q1). An unstable flagship plus a new property is two weak properties, not a portfolio.
8. Write the allocation posture: how organizer hours and money split across the properties, and what visibly breaks first when one starves another. Treat this as a question set the team answers for itself, never as a formula:
   - Which property loses its owner first?
   - Which property's quality drop would be noticed by attendees soonest?
   - Which one are the sponsors actually paying for?

   Route the money modelling to `samber/dev-event-organizer-skills@event-budget`.

9. Write add/kill criteria per property, in advance and dated. Write the team's own: a named metric, a floor value, and the number of consecutive editions below it that trigger a retirement conversation. A criterion written after a property starts failing is a negotiation, not a criterion. When a trigger fires, the conversation has two honest outcomes, and it must pick one on a date:
   - **Change the recipe** - only as a dated test: one named change (format, day, length, theme, audience level), a fixed number of editions, the metric it must move, and a keep-or-retire date at the end. Read demand first with `samber/dev-event-organizer-skills@event-market-fit`: no recipe change fixes a job nobody has.
   - **Retire the property** - announced, with its audience pointed at the property that remains.

   Where two declining properties share one audience, merging them (composition menu) is a third outcome. Anything else - another edition "to see" - is the slow drift the failure modes name.

10. When the composition call is contested inside the team, enter brainstorming mode instead of recommending:
    - Two or three candidate portfolio shapes, each with trade-offs and a recommendation.
    - Questions asked one at a time.
    - Each section of the plan validated before the next.

    Never emit a portfolio plan the team has not walked through section by section.

If your harness has persistent memory, record:

- The property inventory, with each purpose sentence and owner.
- The funnel paths, marked exists or aspirational.
- The shared-infrastructure rung chosen, and the ones rejected.
- The cadence posture and the allocation posture.
- Every add/kill criterion, with its date.

Next year's portfolio call then starts from this team's own history rather than from generic cases.

## Portfolio composition

What to add to the set, if anything. Ranking below is a default, not a law.

- effort (hours, coordination, whether the commitment ever ends): `standalone second format > low-cadence small format > recurring media property > co-located add-on > continuity surface`
- value (audience carried across the gaps, plus audience the flagship cannot reach): `standalone second format > low-cadence small format > continuity surface > recurring media property > co-located add-on`
- efficiency: `continuity surface > low-cadence small format > co-located add-on > recurring media property > standalone second format`
- compliance cost (review triggered, reversibility lost): `standalone second format > co-located add-on > recurring media property > continuity surface`. The low-cadence small format carries none in the common case - a hosted room and an open invitation sign nothing.

Re-rank against the interview:

- A near deadline (Q7) promotes the continuity surface and the co-located add-on, the only rungs needing no second production cycle.
- A compounding mandate (Q8) promotes the continuity surface and the low-cadence format, and demotes the co-located add-on, which buys nothing between editions.
- A co-organizer looking for a property of their own, or a venue hosting for free (Q9), promotes the standalone second format past its normal position.

- **Continuity surface** - the default rung: one always-on, non-event property that holds the audience between editions (a chat space, a list, a publishing surface), near-zero to start, and the only rung that directly answers the momentum-between-editions problem. A hackathon network acquired an always-on developer community platform that demonstrates the pattern: a participant's work becomes "permanent, searchable, and useful to the next person" for the next cohort. Animating it is `samber/dev-event-organizer-skills@event-community-building`'s job, not this skill's; this skill only decides _whether it belongs in the portfolio_.
- **Low-cadence small format** - a monthly or quarterly meetup under the same brand, feeding the flagship. A community conference organizing guide recommends it bluntly: "No local meetup? No problem! Start one. Even if it's once a quarter, it starts building up an audience, and you get a sense of who is out there." Move up to it from the continuity surface once the surface has an audience and the gap between editions is still visibly cold. Its highest-value use is as an R&D and pipeline surface rather than a separate program: run a hands-on session on whatever is newly relevant to the flagship's own subject as soon as it emerges, and the meetup produces both a tested content idea and a warm audience for the flagship at once, ahead of anything the flagship's own planning cycle could source that fast.
- **Co-located add-on** - a second program inside the flagship's existing venue and dates: a workshop day, a co-located mini-summit. This pattern bundles several co-branded conferences into one regional edition sharing venue, week and sponsors. Bounded effort - one extra program per edition, no new date, venue or travel decision - but it buys nothing during the other eleven months, which is why it ranks below the meetup despite costing less.
- **Recurring media property** - a podcast, newsletter or video series on its own cadence, reaching past the room and past the city with no capacity ceiling. It ranks below the co-located add-on on efficiency because its cost never ends and its value only accrues across many issues: a property that stops publishing reads as dead, which is worse than never having started. Whether it converts listeners into attendees is unmeasured - treat any conversion rate as self-set, and never attach a figure to the claim.
- **Standalone second format on its own date** - the starved option: a hackathon, a startup weekend, a second conference line. Highest value on the menu, since it reaches an audience the flagship structurally cannot (students, beginners, builders rather than listeners) and creates a second sellable moment for sponsors, but it loses every efficiency round because it is a full second production cycle. Promote it only when all three hold:
  - The flagship has run at least two stable editions.
  - A distinct audience keeps asking for something the flagship's format cannot host.
  - A _different_ person can own it end to end.

  The flagship's own lead taking a second property is how both properties get worse.

**Merging two overlapping properties** is the composition move in reverse, and it sits outside the add rankings above because it competes with "change the recipe" and "retire" (step 9), not with any add rung. It fits two or more meetups, or two small conferences, that step 4 flags as the same audience and that are each losing attendance: one property concentrates the audience, the volunteer hours and the sponsor conversation that two were splitting. Promote it only when all three hold:

- The overlap is people, not topic: the attendee records or the cross-property carry rate show the same faces at both, not just similar titles.
- Neither property carries an identity its regulars come specifically for; a merged event that drops the reason one crowd attended loses that crowd.
- The organizers of the absorbed property stay, with a named role in the merged one. A co-organizer who wanted a property of their own (Q9) is usually a reason against: losing their volunteer energy can cost more than the merge saves.

Run it like the step 9 test: a dated decision, one or two joint editions first, then keep both, merge, or retire one. A merge does not merge the audience lists: announce it to each property's list on that list's own consent, and let people opt into the merged one (shared-audience-list rung). When the meetups belong to different organizing teams, the merge also merges teams: route the governance to `samber/dev-event-organizer-skills@event-team-structure`. A joint edition between two teams that stay separate is a partner collaboration, covered by `samber/dev-event-organizer-skills@cross-event-promotion`.

A second property under its own name with no announced relationship to the flagship, no shared list and no cross-promotion path is deleted from this menu, not ranked last. The portfolio's entire value is the funnel between properties; an unlinked property is a separate event that competes with your own flagship for the same team's hours while returning none of the compounding. Parked at the bottom, it comes back the moment a co-organizer wants their own brand.

## Shared-infrastructure depth

What the properties share. Cumulative: each rung assumes the ones above it. Ranking below is a default, not a law.

- effort (setup, coordination, legal and consent work, reversibility): `one entity and budget > cross-property sponsor package > shared team and playbook > shared audience list > shared brand only`
- value (funnel paths that actually work, money moved between properties, cost taken off the next property): `shared audience list > cross-property sponsor package > shared team and playbook > one entity and budget > shared brand only`
- efficiency: `shared audience list > shared brand only > shared team and playbook > cross-property sponsor package > one entity and budget`
- compliance cost (review triggered, reversibility lost): `one entity and budget > cross-property sponsor package > shared audience list > shared team and playbook`. Shared brand alone carries none.

Re-rank against the interview:

- A mixed community/company portfolio (Q5) promotes the shared entity out of the basement, since that case needs the money boundary written down before anything else.
- A sponsor already renewing on two properties separately (Q9) promotes the cross-property package.
- A hard deadline (Q7) demotes both the package and the entity, the two rungs that cannot be done quickly.

- **Shared brand only** - one name, one visual system, one page listing every property. Near-zero effort, thinnest value, and second on efficiency for exactly that reason: recognition transfers between properties at almost no cost. It is a floor, not a portfolio.
- **Shared audience list** - the default rung and the highest-value one: one audience record spanning the properties, so an attendee of any property can be reached about another. This _is_ the funnel; without it, step 3's paths are all aspirational. Consent has to be carried per property, not assumed across them.
- **Shared team and playbook** - the same organizing people plus shared operational assets: code of conduct, vendor list, venue relationship, templates. It is what makes the third property cheaper than the second. It carries a compliance cost most teams miss: a code of conduct spanning properties means a ban on one carries to the others, and that has to be written down before it is first used, not during the incident. Once tooling is shared across properties, name what each storage system is _only_ for and archive whatever no longer matches - photos in one place, decks and credentials in another, nothing left scattered because the second property assumed it could reuse the first one's ad hoc folder.
- **Cross-property sponsor package** - the starved option: one sponsor conversation and one deal covering several properties. **This rung is untested**: co-located conferences do share a venue, a week and a sponsor pool, but that is not the same as one deal written across several properties, and neither organizers selling such a bundle nor sponsors asking for one is established practice.
  - Never present a bundle as standard practice, and never quote a bundled price as normal.
  - Promote it only when the same sponsor already renews on two of your properties separately, so the bundle formalizes an existing relationship rather than inventing one, and when one person can own fulfilment across all of them.
  - Treat the first bundle as a test with a named fallback to per-property deals, and route the pricing to `samber/dev-event-organizer-skills@event-sponsor-pricing`.
- **One entity and budget** - a single legal and financial container carrying every property, letting a profitable conference cross-subsidize a free meetup. Real, and the only way that cross-subsidy is clean - but the highest effort and the least reversible thing on the menu, which is why it loses every efficiency round for a team that does not need it yet.

Carrying one property's attendee list into another property's marketing without that property's own consent is deleted from this menu, not demoted. It is the cheapest-looking version of the highest-value rung, and consent scoped per property is a design requirement of that rung rather than an expensive variant of it. Parked at the bottom, it reappears the week before a launch deadline.

## Cadence orchestration

How the properties' dates relate across the year. Ranking below is a default, not a law.

- effort: `fixed multi-year rotation > co-location > seasonal waves > anchor-and-spread > opportunistic`
- value (audience served without collision, and a team that survives the year): `anchor-and-spread > co-location > seasonal waves > fixed multi-year rotation > opportunistic`
- efficiency: `anchor-and-spread > seasonal waves > co-location > fixed multi-year rotation > opportunistic`
- compliance cost: only the two postures that pre-commit a venue carry any - `fixed multi-year rotation > co-location`. Anchor-and-spread, seasonal waves and opportunistic sign nothing beyond what each property signs anyway.

Re-rank against the interview:

- An audience that travels to reach you (Q3), or a shared venue and crew that can carry two programs on one setup (Q9), both promote co-location out of its starved position.
- A team already at its limit (Q9) promotes seasonal waves, the only posture that deliberately buys recovery stretches.

- **Anchor-and-spread** - the default: fix the flagship's date first, then place every other property in the gaps at even intervals. Cheapest posture that both prevents collisions and keeps the year continuous, which are the two things the portfolio exists to do. Mostly a calendar exercise, repeated once a year.
- **Seasonal waves** - cluster the properties into two or three concentrated waves with deliberately quiet stretches between. A foundation demonstrates this approach by running roughly 67 events a year in quarterly waves rather than a flat calendar. Its real value for a small team is the quiet stretches: it is the only posture that treats recovery as a scheduling decision instead of hoping for it.
- **Co-location** - the starved option: two or more properties deliberately landing on the same venue and dates. At scale, one regional edition of a flagship bundles several co-branded conferences into one venue and week - high value (one travel decision, one setup, one sponsor moment) but high effort, since it concentrates every property's peak staffing on a single weekend. Promote it when the audience travels to reach you, or when the same booking and the same crew genuinely carry both programs without a second setup.
- **Fixed multi-year rotation** - slots fixed years ahead, the way one flagship rotates China, North America and Europe on a published annual cycle. Buys predictability that attendees and sponsors plan around, but the predictability only pays across many editions or many regions, and the forward commitment cannot flex when the team's capacity changes.
- **Opportunistic** - no posture: each property's owner picks their own date when they are ready. It looks free and is not. Its ratio is worse than its near-zero effort suggests, because the collisions it produces cost the audience and the team more than the coordination it avoids - which is the first failure mode below.

Running two properties on adjacent days in different venues, without sharing the booking or the crew, is deleted from this menu, not ranked last. It is co-location's promise - one trip, one weekend - with none of its mechanism: the audience is asked to choose or to attend both, and the team runs two full setups inside 48 hours. Parked at the bottom, it returns every time two owners each want their own venue on the same busy weekend.

## Failure modes

- **Two properties for the same audience in the same quarter.** The audience does not have two evenings and two ticket budgets in eight weeks; the team does not have two build-ups. Step 4's calendar exists for this, and it fails most often through the _build-up_ overlap rather than the dates themselves. When neither property can move and both are losing attendance, the fix may be one property, not two dates: see merging under the composition menu.
- **Adding a property before the flagship is stable.** The stability gate in step 7 is the one hard gate in this skill. A shaky flagship plus a new property produces two weak properties and one exhausted team, and the flagship is the one that was working.
- **Treating a franchise as a portfolio.** Independent teams under one shared brand need recruitment, vetting and distributed standards enforcement - none of which any menu here provides. Recognising the shape early saves the team from applying composition logic to a governance problem.
- **Selling a cross-property sponsor package as established practice.** Present the first bundle as a test with a fallback, never as how this is normally done, and never attach a bundled price presented as a market rate.
- **A property surviving because nobody wrote a kill criterion.** Properties do not die of low attendance; they die of a conversation nobody scheduled. A criterion written in advance, with a floor and a number of editions, is what turns that into a decision instead of an argument about someone's baby.
- **Reaching for a kill criterion when the real problem is a stale concept.** A flagship losing energy is not always a portfolio question - check whether the property's own theme or format has simply run out of freshness before retiring it as a property. The mirror failure is the slow drift: re-tweaking the recipe edition after edition with no end date, while the team burns out on an event fewer people want each time. Changing the recipe is honest only as the dated test in step 9, ending in keep or retire. The new recipe itself belongs to whichever skill owns the property's own format; this skill only decides whether the property still belongs in the set.
- **A continuity surface that quietly becomes a fourth property.** An always-on space with no owner and no moderation plan is not the cheap rung it looked like - it is an unstaffed property with a code of conduct attached.
- **Mistaking a shared logo for a funnel.** Step 3 marks each path _exists_ or _aspirational_ precisely because a portfolio page listing four properties looks identical whether or not anyone ever moves between them.

## Measurement

Every threshold below is self-set, so declare each floor in advance rather than reading a number back from a first year and calling it a target.

- **Cross-property carry rate** - share of one property's attendees who appear at another property within twelve months. The single number that says whether this is a portfolio or a set. Self-set floor, per pair, declared before the year starts. A high carry rate between two properties that are both declining is the merge signal, not a funnel success.
- **Gap coverage** - longest stretch of the year with no touchpoint of any kind. The continuity surface's whole job is shrinking this.
- **Single-owner coverage** - properties with exactly one named person who can run them end to end. A property with zero is already failing; a person owning two is the collision the calendar will not catch.
- **Criteria written** - properties with an add/kill criterion on paper, dated, before the season starts.

One pass threshold, and it is structural rather than numeric: **every property in the inventory has a purpose sentence, a named owner and a written kill criterion - zero exceptions.** A portfolio plan with any property missing any of the three is not done, whatever its carry rate looks like.

Three questions stay the team's own to answer:

- Allocation, and what breaks first.
- Add/kill criteria, with stated reasons.
- Whether cross-property sponsor packaging is sold or wanted.

The workflow hands them a question set at those points rather than a number - do not fill them with invented figures.

## Invocation examples

- "We run a monthly meetup and an annual conference. Should we add a hackathon next year?"
- "Our conference sells out but the audience disappears for eleven months. What property fixes that?"
- "We have four events and one exhausted team - which one do we kill?"
- "Our two meetups draw the same shrinking crowd. Should we merge them?"
- "Can we sell one sponsorship covering the meetup, the conference and the podcast?"

Expected output: the portfolio plan described under Measurement, delivered section by section for validation:

- The property inventory, with purposes and owners.
- The funnel map, marked exists or aspirational.
- The collision calendar.
- The shared-infrastructure rung chosen, with the rungs rejected.
- The cadence posture.
- The allocation posture.
- The composition decision.
- Per-property add/kill criteria, with dates.

## References

- [references/portfolio-case-record.md](references/portfolio-case-record.md) - the three real multi-property portfolios behind every rung, what each one does and does not demonstrate, and the three decisions a team has to make for itself.
- [references/inventory-funnel-and-kill-criteria.md](references/inventory-funnel-and-kill-criteria.md) - worked shapes for the property inventory, the pairwise funnel map, the build-up collision calendar, the kill-criteria template with the dated recipe-change test, and the sponsor-bundle test, with a negative example for each.

See also, same collection:

- `samber/dev-event-organizer-skills@event-format-selection` - picks the format of a property this skill decides to add.
- `samber/dev-event-organizer-skills@event-market-fit` - validates demand for a new property before composition assumes it exists, and reads demand before a fired kill criterion becomes a recipe change.
- `samber/dev-event-organizer-skills@cross-event-promotion` - joint events and swaps with meetups run by other teams, including the joint edition that tests a merge across teams.
- `samber/dev-event-organizer-skills@event-date-selection` - picks each property's actual date inside the cadence posture chosen here.
- `samber/dev-event-organizer-skills@event-marketing-plan` - runs the acquisition campaign per property, inside the calendar this skill fixes.