Case study · A tenant on Intelligent Operations
Ben Niehues IV
Systems-first product thinking, and a sports-card research console built card by card.
Ben Niehues IV is a product architect and UX leader in Kansas City, Manager of User Experience at CommunityAmerica Credit Union. His tenant runs his twelve-post LinkedIn campaign and Card Market, a private research console where each of fifteen graded rookie cards has its own profile. Signing in lands on those cards.
- 49screens
- 20prompt libraries
- 260column prompts
- 1,099variables filled
The business
- Card Market: fifteen graded rookie cards, five each in baseball, basketball and football, from Mike Trout and Shohei Ohtani to LeBron James and Patrick Mahomes. Each card is a profile with its identity, player, season stats and market status.
- LinkedIn campaign: twelve posts on Tuesdays and Thursdays, approved each Monday, with a Friday review of the signals feed.
- Member Insights Playbook: coordinated 75+ team members across 7 departments to ship a Salesforce experience surfacing personalized member insights at CommunityAmerica Credit Union.
- 2023 Email Pilot: the first measurable test of personalized member insights; the pilot group was 2x more likely to qualify for Cashback Checking than the control.
- College Cost & Compare Calculator: used by 10,000+ families, with a 3x increase in monthly planner meetings.
- Audience: product, UX and digital-experience peers, especially in credit unions and community financial institutions.
- Voice: first person, plain and candid, short declarative sentences, no hype. Brand: burnt orange on paper and ink, IBM Plex, square corners.

/
/tenant/ben-niehues-iv/foundation/profiles?type=cards
/tenant/ben-niehues-iv/foundation/profiles/cards/2011-topps-update-us175-mike-trout-psa-10
/tenant/ben-niehues-iv/foundation/profiles/cards/2003-topps-chrome-111-lebron-james-psa-9
/tenant/ben-niehues-iv/foundation/profiles/cards/2017-panini-prizm-269-patrick-mahomes-psa-10
/tenant/ben-niehues-iv/foundation/profiles/cards/2020-panini-prizm-307-joe-burrow-raw
/tenant/ben-niehues-iv
/tenant/ben-niehues-iv/foundation/overview
/tenant/ben-niehues-iv/content/cms
/tenant/ben-niehues-iv/content/shells
/tenant/ben-niehues-iv/content/feed
/tenant/ben-niehues-iv/articles/gallery
/tenant/ben-niehues-iv/products/table
/tenant/ben-niehues-iv/knowledge/all
/tenant/ben-niehues-iv/foundation/profiles
/tenant/ben-niehues-iv/intel/competitors
/tenant/ben-niehues-iv/database/tables
/tenant/ben-niehues-iv/database/schema
/tenant/ben-niehues-iv/database/crm
/tenant/ben-niehues-iv/intel/pipeline
/tenant/ben-niehues-iv/config/voice
/tenant/ben-niehues-iv/calendar/month
/tenant/ben-niehues-iv/calendar/week
/tenant/ben-niehues-iv/calendar/approvals
/tenant/ben-niehues-iv/calendar/previews
/tenant/ben-niehues-iv/consoles/campaign-os
/tenant/ben-niehues-iv/consoles/campaign-dashboard
/tenant/ben-niehues-iv/consoles/content-calendar
/tenant/ben-niehues-iv/consoles/content-publisher
/tenant/ben-niehues-iv/consoles/prompt-library-workflows
/tenant/ben-niehues-iv/consoles/creative-board
/tenant/ben-niehues-iv/foundation/design
/tenant/ben-niehues-iv/foundation/brand-assets
/tenant/ben-niehues-iv/foundation/brand-studio
/tenant/ben-niehues-iv/config/tokens
/tenant/ben-niehues-iv/consoles/brand-io
/tenant/ben-niehues-iv/consoles/image-feed
/tenant/ben-niehues-iv/foundation/briefs
/tenant/ben-niehues-iv/consoles/libraries-io
/tenant/ben-niehues-iv/foundation/variables
/tenant/ben-niehues-iv/foundation/variables?tab=outputs
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=founder-and-origin-story
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=digital-persona-and-entity-profile
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=mission-vision-and-values
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=brand-positioning
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=value-proposition
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=author-voice
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=topic-ownership
/tenant/ben-niehues-iv/foundation/variables?tab=outputs&lib=main-messaging#c0431aBen's path from a Kansas farm town to front-end developer to UX leader is the backbone of his LinkedIn program and About page.
- Founder Interview Questions
- Origin Timeline
- Founder Profile
- Story Arc
- Story Truth Standards
- Signature Origin Story
- Short-Form Versions
- Founder Bio Set
- Story Resonance Review
- Story Deployment Map
A personal brand needs one canonical record so LinkedIn, bennieiv.xyz and AI answers agree on who Ben is.
- Entity Fact Intake
- Current Entity Footprint Audit
- Entity Disambiguation
- Canonical Entity Record
- Entity Description Set
- Identifier and Profile Register
- Entity Relationship Map
- Structured Data Specification
- Answer-Ready Fact Pages
- Consistency Validation
- Entity Maintenance Process
His stated mission and the rules he already practises (show the basis, never overclaim) become the Monday draft checklist.
- Purpose Discovery Questions
- Culture Evidence Review
- Mission Statement
- Vision Statement
- Core Values Set
- Value Behaviour Standards
- Values in Practice
- Public Mission Page Copy
- Alignment Check
- Rollout and Reinforcement Plan
Positions Ben as the sourced, practitioner voice on product architecture in financial services.
- Market Category Definition
- Target Audience Positioning
- Competitive Positioning Matrix
- Value Proposition Statement
- Brand Benefits Hierarchy
- Points of Difference Framework
- Points of Parity Framework
- Brand Promise Statement
- Positioning Statement Structure
- Positioning Testing Framework
- Positioning Evolution Timeline
- Category Disruption Strategy
States what peers get from following Ben when nothing is for sale.
- Primary Value Proposition
- Audience-Specific Value Statements
- Problem Definition
- Solution Statement
- Unique Benefits Description
- Competitive Differentiation Points
- Evidence and Proof Points
- Value Quantification Framework
- Emotional Value Components
- Rational Value Components
- Value Delivery Timeline
- Value Proposition Testing Framework
Every post is first person as Ben, so his voice rules must be explicit for drafting agents.
- Voice Sample Collection
- Speech Pattern Analysis
- Voice Attribute Definition
- Narrative Stance Framework
- Signature Vocabulary List
- Sentence Rhythm Rules
- Voice Do And Avoid Guide
- Sample Passage Rewrite
- Author Review Questions
- Voice Match Scoring
- Voice Guide Summary
The 11 playbook positions need to be grouped into a few topics Ben can own.
- Expertise Territory Questions
- Topic Landscape Assessment
- Owned Topic Statement
- Topic Pillar Framework
- Point Of View Positions
- Subtopic Question Map
- Signature Framework Concept
- Content Anchor Plan
- Topic Boundary Rules
- Authority Signal Measures
- Topic Ownership Summary
Keeps the system-before-screen message consistent across 12 posts and the site.
- Main Value Proposition
- Main Result
- Main Impact
- Main Outcome
- Main Function
- Main Purpose
- Main Objective
- Main Rationale
- Main Use Case
- Main Hook
- Main Jobs to Be Done
- Main User Story
- Main Benefit
- Main Feature
- One-liner
- Summary
- Description
- Overview
- Synopsis
- Excerpt
- Definition
- Explanation
Defines the product and UX peers, mainly in credit unions, the program is written for.
- Target Market Overview
- Ideal Customer Profile
- Primary Target Segment
- Target Market Segments
- Customer Personas
- Target Market Industry, Companies, & Job Titles Overview
- Customer Insights & Behaviors Overview
- Customer Goals, Desires, & Motivations Overview
- Customer Communication & Engagement Overview
- Customer Problems & Pain Points Overview
- Customer Personalities & Archetypes Overview
- Customer Transformation Overview
- Storybrand Script
LinkedIn posts live or die on the first line; the LI-01 to LI-12 hooks need a system.
- Anecdotal Hook
- Four Us Hooks
- PAS Hooks
- AIDA Hooks
- 5 Ws Hook
- Story Hook
- Bridge Hook
- Value Proposition Hooks
- Cliffhanger Hook
- Testimonial Hooks
- How-to" Hooks
- Shock Factor Hook
- Statistical Hook
- Question Hook
- Comparison Hook
- FOMO Hook
- The Guarantee Hook
- The Scarcity Hook
- The Authority Hook
- The Social Proof Hook
The LinkedIn posts expand into Notebook essays and Studio case pages on bennieiv.xyz.
- Exploring Emerging Trends in Industry
- H1 Heading: Title as a Problem-Solution Hook
- The Impact of Technology on Social Change
- H1 Subheading: Preparing for Future Success and Transformation
- Strategies for Effective Leadership in a Digital Age
- H1 Body Text Introduction: Problem, Solution, and Context
- The Role of Innovation in Business Growth
- H2 Heading Section 01: Framing Past Struggles
- Building a Sustainable Future: Challenges and Opportunities
- H2 Body Text Section 01: Historical Problems and Market Shifts
- Navigating the Complexities of Global Markets
- H3 Heading Section 01: Early Struggles to Innovate
- The Importance of Diversity and Inclusion in the Workplace
- H3 Heading Section 01: Why Traditional Solutions Failed
- Harnessing Data for Strategic Decision Making
- H3 Heading Section 01: Market Demand Driving New Solutions
- The Future of Work: Adapting to New Realities
- H2 Heading Section 02: Showcasing Current Innovation and Impact
- Engaging Communities Through Corporate Social Responsibility
- H2 Body Text Section 02: Trends, Innovations, and Value
- H3 Heading Section 02: Emerging Trends
- H3 Heading Section 02: Technological Disruption
- H3 Heading Section 02: Urgency of Adoption
- H2 Heading Section 03: Opportunities and Challenges
- H2 Body Text Section 03: Opportunities, Obstacles, and Solutions
- H3 Heading Section 03: Competitive Advantage Through Early Adoption
- H3 Heading Section 03: Overcoming Cost Barriers
- H3 Heading Section 03: Preparing Teams for Innovation
- H2 Heading Section 04: Conclusion and Action Steps
- H2 Body Text Section 04: Summary, Call to Action, and Final Thoughts
Each post is briefed from sourced research before drafting; the brief names the reader, one objective, a target, the evidence and the CTA.
- Brief Intake Questions
- Audience Reader Profile
- Objective And Success Measure
- Core Message And Angle
- Search Intent And Keyword Plan
- Content Outline
- Tone And Style Direction
- Sources And Evidence Plan
- Call To Action Design
- Brief Quality Checklist
- Distribution And Repurposing Notes
The Friday signals review and the twelve posts feed a scored topic pipeline across Ben's four pillars.
- Content Discovery Questions
- Audience Question Mining
- Search Demand Review
- Competitor Content Gap Scan
- Topic Pillar Framework
- Topic Idea Generation
- Topic Scoring Model
- Topic Brief Template
- Angle and Hook Development
- Format and Channel Mapping
- Topic Pipeline Schedule
- Topic Performance Review
The program runs a fixed Tuesday/Thursday rhythm with Monday approvals.
- Current Output Baseline
- Audience Consumption Patterns
- Cadence Objectives
- Production Capacity Assessment
- Channel Frequency Plan
- Day & Time Slotting
- Content Mix Ratios
- Batch Production Schedule
- Buffer & Backlog Rules
- Frequency Test Plan
- Cadence Performance Measures
- Cadence Adjustment Report
Live Miniflux categories (banking and fintech, credit union trade press, Startland News) feed the signals review.
- Monitoring Purpose
- Topic and Entity Watchlist
- Feed Source Curation
- Collection Setup
- Filtering and Scoring Rules
- Classification Scheme
- Routing and Delivery
- Feed Health Review
- Weekly Intelligence Digest
- Feed Value Measures
Card Market runs on a Notion Worker writing Card Profiles and Card Price History databases.
- Database Purpose And Record
- Source Data Assessment
- Property Schema
- Relation Map
- Rollups And Formulas
- View Set
- Database Templates
- Data Entry Rules
- Schema Test Scenarios
- Database Import And Launch
- Database Usage Review
Card Market depends on ESPN, eBay and PriceCharting connectors, three of which are not yet connected.
- Connector Purpose
- API Surface Review
- Capability Mapping
- Tool Definitions
- Resource Definitions
- Auth and Transport Design
- Error and Limit Handling
- Security Review
- Connector Test Plan
- Release and Versioning
- Connector Adoption Measures
His site's measured --va-* tokens (burnt orange, IBM Plex, radius 0) must carry into every tenant surface.
- Hard Coded Value Audit
- Token Tier Model
- Token Naming Convention
- Primitive Token Set
- Semantic Token Map
- Theme And Mode Strategy
- Component Token Aliases
- Token Source And Build Pipeline
- Token Usage Rules
- Token Migration Plan
- Token Coverage Measures
bennieiv.xyz has an agent-readable version, and AI answers about Ben need to be accurate.
- Question Universe Discovery
- Answer Opportunity Assessment
- Answer Architecture
- Answer Writing Rules
- Direct Answer Drafts
- Structured Data Plan
- Voice and Conversational Fit
- Answer Readiness Audit
- Answer Visibility Measures
- Answer Refresh Cycle
The 12-post program needs baselines and a week-6 review without invented results.
- Reporting Scope and Goals
- Metric Hierarchy
- Attribution and Data Notes
- Funnel Performance Summary
- Channel Performance Breakdown
- Campaign Results Review
- Content and Engagement Signals
- Performance Diagnosis
- Next Period Allocation
- Marketing Report Summary
{{01_Founder_Interview_Questions}}- The origin interview for Ben Niehues IV is built around one question: how a front-end developer from a 164-person farm town in Kansas came to practise product architecture, the shaping of systems people have to live inside. The questions ask why he left the build work for UX leadership, what he learned in study four of a digital banking migration, when he first saw a tool change a conversation rather than sell something, and why he built a private card console he chose not to publish. Every answer is checked against his LinkedIn profile and his own site, bennieiv.xyz, and CommunityAmerica Credit Union results are taken from his LinkedIn profile, where they are public and credited to CACU and the team. New internal results still need the employer's OK. Questions about revenue, clients or audience size are left out because there is no business behind the brand.
{{FOUNDING_MOTIVE}}- Ben's stated motive is the work itself: "Before a wireframe or a feature, there's a system someone has to live inside, and my work is shaping that system to be simple, useful, and worth trusting." The personal brand exists to make that practice visible to peers.
{{MARKET_INSIGHT}}- Most product conversations start at the screen; the expensive problems sit one layer down, in the system, the data and the people who have to use it. His career shows the same pattern repeatedly: the tool that answers a real question changes behaviour more than the tool that sells.
{{EARLY_STRUGGLES}}- Proposed interview topic: moving from builder to leader, including managing his first two direct reports in 2024 and learning to lead through research rather than code. No specific struggle is on record, so this answer must come from Ben.
{{FIRST_CUSTOMER}}- Not applicable in the commercial sense; there are no clients. The first users of his work were credit union members and families using the College Cost & Compare Calculator, a CommunityAmerica Credit Union project.
{{NEAR_FAILURE}}- No near-failure is on record. Proposed question for Ben: which project came closest to not shipping, and what scope decision saved it (the six-month Credit Score and Lending Recommendation build is a likely candidate).
{{ENDURING_BELIEF}}- Systems should be simple, useful and worth trusting, and every number should say what it is based on. He treats restraint, including deciding not to publish something, as a product decision.
{{02_Origin_Timeline}}- The timeline runs from a crop farm in Corning, Kansas, through a Management Information Systems degree at Kansas State University (2007-2011) and a web development certificate at Johnson County Community College (2011-2012). He built more than 300 solutions at Elemeno Design (2012-2016), ran direct-to-consumer ecommerce at FEWDM (2016-2017), and joined CommunityAmerica Credit Union in November 2017 as a senior front-end developer. He moved through senior product architect (2021) and product experience and innovation manager (2024) to Manager, User Experience (December 2025). The Card Market side project collected its first week of data in 2026-W39, and the LinkedIn program starts on September 29, 2026.
{{BACKGROUND_EVENTS}}- Grew up on a crop farm in Corning, Kansas (population 164); B.S. Management Information Systems, Kansas State University, 2011; Web Development Graduate Certificate, JCCC, 2012; User Experience Design Program, General Assembly, 2018.
{{FOUNDING_DATE}}- No founding date applies; the brand is the person. The earliest dated milestones for the current program are the brand tokens measured from bennieiv.xyz on 2026-09-22 and the first LinkedIn post, LI-01, scheduled for 2026-09-29.
{{EARLY_MILESTONES}}- Elemeno Design, Liberty MO: junior to lead web developer, 300+ solutions (2012-2016); FEWDM: head of ecommerce responsible for $1.2M in DTC revenue (2016-2017); CACU: College Cost & Compare Calculator used by 10,000+ families (2017-2021).
{{MAJOR_CHANGES}}- Front-end developer to senior product architect at CACU (December 2021); first direct reports and the Member Insights Playbook launch (2024-2025); Manager, User Experience leading research for the digital banking platform migration (December 2025).
{{EVENT_SOURCES}}- Ben's LinkedIn profile PDF (Experience, Education, Summary); bennieiv.xyz; the Card Market dataset (market.json, generated 2026-09-22). Dates after September 2026 must be confirmed with Ben before they appear in past tense.
{{03_Founder_Profile}}- Ben Niehues IV is a product architect and UX leader in Kansas City who leads user experience at CommunityAmerica Credit Union. He started there as a front-end developer, which is why he trusts systems over screenshots and describes himself as a generalist by conviction, most useful in ambiguity. His CACU work spans the Member Insights Playbook, the Credit Score and Lending Recommendation experience and research for a digital banking platform migration. Outside work he builds a private sports-card research console on the same principle he applies at work: every number says what it is based on.
{{FOUNDER_BACKGROUND}}- Kansas farm upbringing, MIS at Kansas State, 14 years across agency web development, ecommerce and credit union product and UX work.
{{FOUNDER_EXPERTISE}}- Product architecture; experience strategy; UX research for digital banking; cross-functional leadership; front-end development; experimentation and measurement.
{{FOUNDER_VALUES}}- Simple, useful, worth trusting; evidence before claims; restraint as a decision; credit to the team.
{{FOUNDER_VOICE}}- First person, plain and candid, short declarative sentences, no hype. States unknowns openly and closes with a low-pressure invitation to peers.
{{CUSTOMER_CONNECTION}}- His audience is people like him: product, UX and digital-experience builders, many in credit unions. He connects through shared work problems, not through selling anything.
{{04_Story_Arc}}- The arc begins with a builder who could make any screen but kept meeting the same problem underneath it: the system someone had to live inside. At CommunityAmerica Credit Union he saw tools that answered real questions, like the College Cost & Compare Calculator, change behaviour more than tools that pushed products. That pushed him from code into product architecture and then into leading UX research, where he learned to find a migration's costs in study four rather than on launch day. Today he applies the same discipline everywhere, including a private card console that refuses to call an asking price a sale.
{{WORLD_BEFORE}}- A front-end developer shipping pages, calculators and ecommerce builds, judged on what appeared on screen.
{{PROBLEM_NOTICED}}- Screens were being designed before anyone had shaped the system, the data and the decisions behind them, so good interfaces sat on top of confusing experiences.
{{DECISION_TO_ACT}}- He moved into product architecture at CACU in 2021 to work on the system first, starting with the Life Plans Personalization Engine.
{{STRUGGLE}}- Proposed, to confirm with Ben: learning to lead through research and cross-functional agreement rather than through his own code, including building an insights program that 75+ people across 7 departments would actually use.
{{TURNING_POINT}}- The 2023 Email Pilot, run against a control group, returned 2x Cashback Checking qualification: evidence that shaping the system around members' real questions moves outcomes.
{{PRESENT_PURPOSE}}- To shape systems that are simple, useful and worth trusting, and to share the practice openly with peers who are building something worth inhabiting.
{{05_Story_Truth_Standards}}- Every fact in Ben's story must trace to his LinkedIn profile, his own site or a dated file, and CommunityAmerica Credit Union results are always credited to CACU and its teams. Awards and press mentions (EdTech Awards Finalist, CUNA Award, coverage in Forbes, USA Today and the Kansas City Business Journal) are repeated only after Ben verifies the wording. Nothing is rounded up: unproven work, such as the Cellopack beta or the unpriced card console, is described as unproven. Ben approves every version before it is published.
{{VERIFIABILITY_RULE}}- Each claim cites a source line from the LinkedIn profile, bennieiv.xyz or a dated project file; unsourced claims are cut.
{{DIALOGUE_RULE}}- No reconstructed dialogue or invented quotes; only Ben's own published words are quoted.
{{CREDIT_RULE}}- Employer outcomes are attributed to CommunityAmerica Credit Union and the teams involved, with Ben's role stated precisely.
{{EXAGGERATION_RULE}}- No superlatives, no rounding up and no implied commercial traction; unknowns are named as unknowns.
{{APPROVAL_OWNER}}- Ben Niehues IV approves all story versions; results from his LinkedIn profile are public and credited to CACU, while new internal work gets the employer's OK before it is mentioned.
{{06_Signature_Origin_Story}}- Ben Niehues IV grew up on a crop farm in Corning, Kansas, a town of 164 people, and started his career writing front-end code. At CommunityAmerica Credit Union he built tools like the College Cost & Compare Calculator, used by more than 10,000 families, and noticed that the tools that changed behaviour were the ones that answered a real question. He moved into product architecture to work on the system before the screen, and now leads UX research for the credit union's digital banking migration. The through-line is one sentence he uses to describe the work: before a wireframe or a feature, there is a system someone has to live inside.
{{OPENING_SCENE}}- A farm town of 164 people in north-east Kansas, where things are built to be used for a long time.
{{PROBLEM_SECTION}}- As a developer he could build any screen, but the hard problems sat underneath: data, decisions and the people who had to live with them.
{{STRUGGLE_SECTION}}- Moving from code to leadership meant trading control of the build for agreement across teams, including 75+ people in 7 departments for the Member Insights Playbook.
{{TURNING_POINT_SECTION}}- A controlled email pilot returned 2x Cashback Checking qualification, and a calculator tripled planner meetings: proof that system-first work moves outcomes.
{{PRESENT_DAY_SECTION}}- He leads UX at CACU, writes about product architecture on LinkedIn and bennieiv.xyz, and keeps a private card console as a working example of evidence-first design.
{{07_Short_Form_Versions}}- The short forms keep one idea: a builder who learned to shape the system before the screen. The one-sentence version is for LinkedIn headers and introductions, the paragraph is for event bios and the bennieiv.xyz About page, and the spoken version is for podcast and panel introductions. All three may use the results on his LinkedIn profile, credited to CACU and the team, and all three end on the same invitation.
{{ONE_SENTENCE_VERSION}}- Ben Niehues IV is a Kansas City product architect who shapes the systems people live inside so they are simple, useful and worth trusting.
{{BIO_PARAGRAPH}}- Ben Niehues IV leads user experience at CommunityAmerica Credit Union in Kansas City. He started there as a front-end developer and moved into product architecture, shaping member-facing systems such as the Member Insights Playbook and the College Cost & Compare Calculator. He writes about systems-first product work at bennieiv.xyz.
{{SPOKEN_VERSION}}- Ben grew up on a farm in Corning, Kansas, started as a front-end developer, and now leads UX at CommunityAmerica Credit Union. His rule is simple: before a wireframe or a feature, there is a system someone has to live inside.
{{08_Founder_Bio_Set}}- The bio set gives Ben one consistent identity across LinkedIn, bennieiv.xyz, speaker listings and agent-readable pages. The third-person versions lead with role and practice, the first-person profile uses his own words, and all versions name CommunityAmerica Credit Union as employer with outcomes credited to CACU. No headshot is on file, so the caption is written for a photo still to be supplied.
{{THIRD_PERSON_SHORT}}- Ben Niehues IV is a product architect and Manager, User Experience at CommunityAmerica Credit Union in Kansas City.
{{THIRD_PERSON_LONG}}- Ben Niehues IV is a product architect and UX leader in Kansas City, currently Manager, User Experience at CommunityAmerica Credit Union, where he leads research and design strategy for its digital banking platform migration. Over nearly nine years at CACU he moved from senior front-end developer to product architecture and product experience leadership, working on the Member Insights Playbook, the Life Plans Personalization Engine and the College Cost & Compare Calculator. He holds a B.S. in Management Information Systems from Kansas State University.
{{FIRST_PERSON_PROFILE}}- I practice product architecture. Before a wireframe or a feature, there's a system someone has to live inside, and my work is shaping that system to be simple, useful, and worth trusting. If you're building something worth inhabiting, or just curious, reach out.
{{HEADSHOT_CAPTION}}- Ben Niehues IV, product architect, Kansas City. (No headshot on file; caption ready for when one is supplied.)
{{09_Story_Resonance_Review}}- Proposed review: after the first six LinkedIn posts, Ben and two or three trusted peers read the signature story and note what they remember, what they doubt and what they would cut. The test is whether readers recall the system-before-screen idea and the farm-to-front-end path without prompting. Credibility feedback focuses on whether CACU outcomes read as team results and whether the card console reads as a side project, not a product. Revisions are made once, before the bennieiv.xyz About page is updated.
{{RECALLED_ELEMENTS}}- Target: readers recall the line "a system someone has to live inside" and the move from front-end developer to UX leader.
{{CREDIBILITY_FEEDBACK}}- Proposed checks: do CACU numbers feel attributed and verifiable; does anything read as self-promotion or hype.
{{VALUE_CLARITY}}- Target: a peer can say in one sentence what Ben does and why it matters to their own product work.
{{REVISIONS}}- Proposed: tighten the farm opening if it distracts, and drop any award mention Ben cannot verify.
{{10_Story_Deployment_Map}}- The story is deployed where peers meet Ben: his LinkedIn About section and featured posts, the bennieiv.xyz About page and Studio case pages, and speaker bios for panels or podcasts. There is no sales use, because nothing is sold; the story supports conversations, not pipeline. Ben owns every placement, and the Intelligent Operations console tracks which version is live where.
{{WEBSITE_PLACEMENT}}- bennieiv.xyz About page (paragraph version) and the opening of each Studio case page (one-sentence version).
{{PRESS_PLACEMENT}}- Speaker and podcast bios (third-person long); no press program is planned.
{{SALES_PLACEMENT}}- Not applicable; there is no offer. The equivalent is the /contact page and LinkedIn DMs, which use the closing invitation.
{{PROFILE_PLACEMENT}}- LinkedIn headline and About section (first-person profile); Instagram and X bios (one-sentence version).
{{PLACEMENT_OWNERS}}- Ben Niehues IV owns all placements; Intelligent Operations maintains the approved versions in the tenant console.
{{01_Entity_Fact_Intake}}- The entity is a person, Ben Niehues IV, a product architect and UX leader based in Kansas City, Missouri. His official web presence is bennieiv.xyz, his LinkedIn profile is linkedin.com/in/bennieiv, and he uses the handle @bennieiv on Instagram and X. His current role is Manager, User Experience at CommunityAmerica Credit Union, and his side projects are the private Card Market console and Cellopack, an early-beta trust profile for collectors. There is no legal entity, founding date or business address on record, and none is needed for a personal brand.
{{LEGAL_NAME}}- Ben Niehues IV (individual; no registered business entity on record).
{{TRADING_NAMES}}- BenNieIV (site wordmark and page titles); @bennieiv (social handle).
{{FOUNDING_DETAILS}}- Not applicable; personal brand. bennieiv.xyz is registered through Namecheap (registration date not on record).
{{LOCATIONS}}- Kansas City, Missouri (city only; no public address).
{{LEADERSHIP}}- Ben Niehues IV, sole owner of the brand and its projects.
{{OFFICIAL_PROFILES}}- bennieiv.xyz; linkedin.com/in/bennieiv; instagram.com/bennieiv; X @bennieiv.
{{02_Current_Entity_Footprint_Audit}}- Ben's footprint today is his own site, bennieiv.xyz, his LinkedIn profile and Instagram (2,431 followers on 2026-09-25), plus mentions of CommunityAmerica Credit Union projects in trade and local press. The tenant site ben-niehues-iv.intelligentoperations.ai is registered but not built and returns 404, so it should not be listed anywhere. The main risk is inconsistency between an older product-architect title and his current Manager, User Experience title across profiles. AI answer accuracy has not been tested and is the first audit task.
{{LISTED_SOURCES}}- bennieiv.xyz; LinkedIn; Instagram @bennieiv; X @bennieiv; CACU project coverage (Forbes, USA Today, Kansas City Business Journal, to verify).
{{DISPLAYED_FACTS}}- Name; Kansas City location; product architect and UX leader role; CommunityAmerica Credit Union employer; LinkedIn headline "Product Architect | UX & Digital Experience Leader at CommunityAmerica Credit Union".
{{FACT_CONFLICTS}}- Title varies between Product Architect, Senior Product Architect and Manager, User Experience across sources; the site's front page for the card console was still titled {{NAME}} in one local copy.
{{MISSING_PRESENCE}}- No headshot on file; no speaker or publication profiles; tenant site not live; no structured data confirmed on bennieiv.xyz.
{{AI_ANSWER_ACCURACY}}- Not yet tested. Proposed: ask four assistants "Who is Ben Niehues IV?" at week 0 and record whether role, employer and city are correct.
{{03_Entity_Disambiguation}}- The name Ben Niehues is shared with his father's line (he is the fourth) and possibly with other people named Niehues in Kansas and Missouri. The suffix "IV", the handle bennieiv and the role at CommunityAmerica Credit Union are the distinguishing signals. Every profile should use the full name with the suffix and link back to bennieiv.xyz. A short disambiguation phrase is used in bios and structured data.
{{CONFUSABLE_ENTITIES}}- Other people named Ben or Benjamin Niehues, including earlier generations of his own family; unrelated Niehues businesses in the region.
{{CONFUSION_SIGNALS}}- Name searches without the suffix; profiles that omit employer or city.
{{DISTINGUISHING_FACTS}}- The suffix IV; Kansas City; CommunityAmerica Credit Union; the bennieiv handle; product architecture as his stated practice.
{{DISAMBIGUATION_PHRASE}}- Ben Niehues IV, product architect and UX leader at CommunityAmerica Credit Union in Kansas City.
{{04_Canonical_Entity_Record}}- The canonical record names Ben Niehues IV as a person whose primary category is product architecture and user experience leadership. His home page is bennieiv.xyz, and his public contact point is the site's contact page rather than a personal email or phone. His location is given as Kansas City, Missouri, without a street address. The record is kept in the Intelligent Operations console and every profile is updated from it.
{{CANONICAL_NAME}}- Ben Niehues IV
{{ALTERNATE_NAMES}}- BenNieIV; bennieiv; Ben Niehues.
{{PRIMARY_CATEGORY}}- Person: product architect and UX leader (financial services).
{{CANONICAL_ADDRESS}}- Kansas City, Missouri (no street address published).
{{CONTACT_POINTS}}- bennieiv.xyz/contact; LinkedIn messages at linkedin.com/in/bennieiv.
{{SERVICE_AREA}}- Not applicable; no services are offered. Audience is national product and UX peers, with a Kansas City base.
{{05_Entity_Description_Set}}- The description set gives the same facts at four lengths so profiles, bios and AI answers match. Each version names the person, the practice and the employer, and none implies a business or service for sale. The paragraph version adds the side project only as a personal research tool. All are written in the third person for use by others.
{{ONE_LINE_DESCRIPTION}}- Ben Niehues IV is a product architect and UX leader in Kansas City.
{{SHORT_DESCRIPTION}}- Ben Niehues IV leads user experience at CommunityAmerica Credit Union and writes about shaping the systems people live inside.
{{PARAGRAPH_DESCRIPTION}}- Ben Niehues IV is a product architect and UX leader in Kansas City, currently Manager, User Experience at CommunityAmerica Credit Union. He started as a front-end developer and now leads research and design strategy for digital banking. He writes at bennieiv.xyz and keeps a private sports-card research console as a personal project.
{{CATEGORY_STATEMENT}}- Ben Niehues IV belongs in product architecture, UX leadership and digital banking experience, not in sports-card sales or services.
{{06_Identifier_and_Profile_Register}}- Ben has no registry identifiers such as a company number, because there is no business entity. The register lists his owned profiles and their claim status, with bennieiv.xyz as the anchor. Knowledge-base entries such as Wikidata are not recommended for a private individual at this stage. Business listings such as Google Business Profile do not apply.
{{REGISTRY_IDENTIFIERS}}- None; no business entity. Domain bennieiv.xyz registered at Namecheap.
{{KNOWLEDGE_BASE_ENTRIES}}- None on record; not proposed.
{{BUSINESS_LISTINGS}}- Not applicable (no business, no storefront).
{{SOCIAL_PROFILES}}- LinkedIn linkedin.com/in/bennieiv; Instagram instagram.com/bennieiv; X @bennieiv.
{{CLAIM_STATUS}}- All three social profiles and the domain are owned by Ben; the tenant subdomain is registered by Intelligent Operations and not live.
{{07_Entity_Relationship_Map}}- Ben's main organisational relationship is employment at CommunityAmerica Credit Union, with a working relationship with Unify Credit Union through the 2026 digital banking work. His education links him to Kansas State University, Johnson County Community College and General Assembly. His projects, Card Market and Cellopack, are personal and relate to him alone. Each relationship is stated only where a source supports it.
{{PEOPLE_RELATIONSHIPS}}- Ben is the sole person on the record; family details are kept out of public entity data.
{{ORGANISATION_RELATIONSHIPS}}- Employee: CommunityAmerica Credit Union (since 2017); collaborator: Unify Credit Union; alumnus: Kansas State University, JCCC, General Assembly; former: Elemeno Design, FEWDM.
{{LOCATION_RELATIONSHIPS}}- Based in Kansas City, Missouri; from Corning, Kansas.
{{OFFERING_RELATIONSHIPS}}- Creator of Card Market (private research console) and Cellopack (early beta); no commercial offerings.
{{SUPPORTING_SOURCES}}- LinkedIn profile PDF; bennieiv.xyz; Card Market README and dataset.
{{08_Structured_Data_Specification}}- The site should carry schema.org Person markup on the bennieiv.xyz home and About pages. Core properties are name, jobTitle, worksFor, address locality and url, with sameAs links to the social profiles. Because there is no business, there is no Organization or LocalBusiness markup; project pages can use CreativeWork. Markup is validated with a rich-results tester after each change.
{{ENTITY_TYPE}}- schema.org Person
{{CORE_PROPERTIES}}- name "Ben Niehues IV"; jobTitle "Manager, User Experience"; worksFor CommunityAmerica Credit Union; address addressLocality "Kansas City", addressRegion "MO"; url https://bennieiv.xyz; alumniOf Kansas State University.
{{SAME_AS_LINKS}}- https://www.linkedin.com/in/bennieiv; https://www.instagram.com/bennieiv/; X profile @bennieiv.
{{FOUNDER_PROPERTIES}}- Not applicable as an organisation founder; project pages list Ben as creator (CreativeWork creator).
{{PUBLISHING_PAGES}}- bennieiv.xyz home and About; Studio case pages as CreativeWork; Notebook essays as Article with author Ben Niehues IV.
{{09_Answer_Ready_Fact_Pages}}- Answer-ready pages let assistants and readers get the facts in one place. The About page states who he is, what he does and where, in plain sentences. A short FAQ answers the questions peers actually ask, such as what product architecture means and whether the card console is for sale. Quotable facts are limited to ones that are sourced, such as the results on his LinkedIn profile, credited to CACU and the team.
{{ABOUT_PAGE_STANDARD}}- Opens with the one-line description, then role, employer, practice and projects, each in one sentence; no marketing language.
{{LEADERSHIP_PAGE_STANDARD}}- Not applicable for a single person; the About page covers it.
{{LOCATION_PAGE_STANDARD}}- Not applicable; location is stated as Kansas City on the About page only.
{{FAQ_STANDARD}}- Each answer is two or three sentences, starts with the direct answer and names its source; includes "Is Card Market a service?" (No, it is private research).
{{QUOTABLE_FACTS}}- Leads UX at CommunityAmerica Credit Union; 14 years in web, product and UX work; started as a front-end developer; B.S. MIS, Kansas State University.
{{10_Consistency_Validation}}- Consistency is checked quarterly against the canonical record. The check compares name, title, employer and city across the site and three social profiles, reviews AI answers to set questions and validates the Person markup. Results are logged in the console with the date.
{{LISTING_MATCH_RATE}}- Target: 4 of 4 owned profiles match the canonical name, title and city by the end of October 2026 (baseline not yet measured).
{{PANEL_ACCURACY}}- Not applicable yet; no knowledge panel on record. Check quarterly.
{{AI_ANSWER_TESTS}}- Proposed questions: "Who is Ben Niehues IV?", "What does Ben Niehues IV do?", "Where does Ben Niehues IV work?" Target: correct role, employer and city.
{{MARKUP_VALIDATION}}- Person markup validated with zero errors after each site change.
{{11_Entity_Maintenance_Process}}- The record changes when Ben's role, employer or projects change, or when a project such as Cellopack changes status. Updates go to bennieiv.xyz first, then LinkedIn, then the other profiles and structured data. A quarterly audit catches drift. Ben owns the record, with Intelligent Operations keeping the canonical copy.
{{CHANGE_TRIGGERS}}- Title or employer change; new Studio case page; Cellopack status change; tenant site going live.
{{UPDATE_ORDER}}- bennieiv.xyz and its markup; LinkedIn; Instagram and X; the IO console record.
{{AUDIT_CADENCE}}- Quarterly, first audit proposed for the week of October 5, 2026.
{{RECORD_OWNER}}- Ben Niehues IV, with Intelligent Operations maintaining the console copy.
{{01_Purpose_Discovery_Questions}}- The purpose questions ask why Ben's public practice exists, who it is for and what would be lost without it. His own answer is on record: architecture as a way of shaping the systems people live inside, applied to a life and to the products he builds. The questions also ask what he refuses to do, which is already clear from his work: he will not publish licensed data, present an ask as a sale or claim traction he has not earned. Aspirations are left to Ben to state and are framed here as proposals.
{{REASON_FOR_EXISTING}}- To make systems-first product work visible and usable for peers: "shaping that system to be simple, useful, and worth trusting."
{{PEOPLE_SERVED}}- Product, UX and digital-experience builders, especially in credit unions and community financial institutions.
{{LOSS_IF_CLOSED}}- A candid, sourced practitioner voice on product architecture in financial services would be missing; peers would lose worked examples.
{{REFUSALS}}- No publishing of licensed vendor data; no asks presented as sales; no claims of traction for unproven work; no new internal employer results without the employer's OK.
{{ASPIRATIONS}}- Proposed: to be the peer product and UX leaders in credit unions think of when they face a platform migration or an insights program.
{{02_Culture_Evidence_Review}}- The evidence for Ben's values comes from decisions he has already made. He built an insights program for 75+ people rather than keeping insight in one team, ran an email pilot against a control group rather than assuming success, and kept his card console private because the price data is licensed for internal use. His site uses one accent colour and square corners, both deliberate. What he practises matches what he states.
{{DEFINING_STORIES}}- Member Insights Playbook rolled out to 75+ people across 7 departments; the controlled 2023 Email Pilot; the Card Market rule that an ask is never a sale.
{{DEFINING_DECISIONS}}- Keeping Card Market private; using sanctioned eBay APIs only and never scraping; waiting for two priced weeks before showing any trend.
{{OBSERVED_BEHAVIOURS}}- States unknowns openly ("1 week on file, none priced yet"); credits team work; ends with an open invitation rather than a pitch.
{{STATED_VS_PRACTISED}}- Consistent: the stated promise of simple, useful and trustworthy systems is visible in both his employer work and his side projects.
{{03_Mission_Statement}}- Ben's mission, in his words, is architecture as a way of shaping the systems people live inside, applied to a life and to the products he builds. For the public program, that becomes sharing how system-first product work is done so peers can build things that are simple, useful and worth trusting. The people served are product, UX and digital-experience builders, and the outcome is clearer, more trustworthy products. The mission names no business goal because there is none.
{{MISSION_SENTENCE}}- Architecture as a way of shaping the systems people live inside. Applied to a life, and the products I build.
{{PEOPLE_SERVED_STATEMENT}}- For people building products and systems, and anyone curious about how they are made.
{{OUTCOME_CREATED}}- Products that are simple, useful and worth trusting.
{{04_Vision_Statement}}- Proposed vision: a world where product teams, especially in financial services, shape the system before the screen and label every number with its basis. Over five years, Ben's practice would be a recognised reference point for system-first product work among credit union and fintech peers. The change described is cultural, from interface-first delivery to architecture-first thinking. It is a direction, not a claim of current influence.
{{FUTURE_STATE}}- Proposed: product teams routinely map the system someone has to live inside before they draw a screen.
{{TIME_HORIZON}}- Proposed: five years (to 2031).
{{CHANGE_DESCRIBED}}- From screen-first delivery and unsourced metrics to system-first design and evidence that names its basis.
{{05_Core_Values_Set}}- Four values capture how Ben works: Simple, Useful, Worth trusting and Show the basis. The first three are his own words for what the work should achieve; the fourth is his rule that every number says what it is based on. When they conflict, trust wins over speed, which is why the card console waits for two priced weeks before showing a trend. Four values are enough to remember and apply.
{{VALUE_NAMES}}- Simple; Useful; Worth trusting; Show the basis.
{{VALUE_MEANINGS}}- Simple: remove what the person living in the system does not need. Useful: answer a real question. Worth trusting: never overclaim. Show the basis: every number says where it comes from.
{{TRADEOFFS_RESOLVED}}- Trust over speed; privacy over reach (the console stays private); team credit over personal credit.
{{VALUE_COUNT}}- Four.
{{06_Value_Behaviour_Standards}}- Each value has visible behaviours. Simple means one idea per post and square, uncluttered design. Useful means every post ends with something a peer can apply. Worth trusting means no hype, no exclamation marks and no claims about unproven work. Show the basis means citing the source of every figure and labelling estimates as estimates.
{{VALUE_BEHAVIOURS}}- One idea per post; sources named; unknowns stated; team credited; open invitation at the close.
{{VALUE_ANTI_BEHAVIOURS}}- Hype words; rounding up; presenting an ask as a sale; publishing card values; claiming CACU results as solely his.
{{EXAMPLE_DECISIONS}}- LI-10 says "one week on file, none priced yet" rather than guessing a trend; LI-11 explains why the card tool stays private.
{{BEHAVIOUR_OWNERS}}- Ben Niehues IV; Intelligent Operations checks drafts against these standards on Mondays.
{{07_Values_in_Practice}}- The values guide every stage of the program. They shape which drafts are approved on Mondays, how results are reported and how Ben answers peers who reach out. There is no hiring or staff review in a one-person brand, so those uses are marked not applicable. Decisions about new projects, such as whether Cellopack content goes public, are tested against the four values.
{{HIRING_APPLICATION}}- Not applicable; no team. If collaborators join, they are briefed on the four values.
{{REVIEW_APPLICATION}}- Monday draft approval checks each post for a named basis, one idea and no overclaiming.
{{CUSTOMER_APPLICATION}}- Peers who reach out get a direct, honest reply and no pitch.
{{DECISION_APPLICATION}}- New public content is tested against "Worth trusting" first; if it overclaims, it does not ship.
{{08_Public_Mission_Page_Copy}}- The mission page on bennieiv.xyz states the mission in Ben's own words, a short vision line and the four values with one example each. The copy is first person and plain, matching his site's voice. Each value example points to real work, credited correctly. The page ends with his standing invitation.
{{MISSION_COPY}}- Architecture as a way of shaping the systems people live inside. Applied to a life, and the products I build.
{{VISION_COPY}}- I want more teams to shape the system before the screen, and to say what every number is based on.
{{VALUES_COPY}}- Simple. Useful. Worth trusting. Show the basis.
{{VALUE_EXAMPLES}}- Useful: a college cost calculator 10,000+ families used (CACU). Worth trusting: a card console that never calls an ask a sale. Show the basis: an email pilot measured against a control group (CACU).
{{09_Alignment_Check}}- Proposed: at week 6, Ben reviews the 12 posts against the four values and notes any drift. The check asks whether peers can repeat the mission, whether each post showed its basis and whether any decision cited a value. Results are recorded in the console.
{{MISSION_RECALL}}- Target: peers who comment or DM can restate the system-before-screen idea (tracked informally from comments).
{{VALUES_PRACTISED_SCORE}}- Target: 12 of 12 posts pass the Monday checklist (named basis, one idea, no overclaiming).
{{DECISION_CITATIONS}}- Log each draft cut or edited for a values reason; target at least one logged decision per month.
{{CUSTOMER_ALIGNMENT}}- Proposed: review DM themes monthly to check peers engage with the practice, not with the side projects as products.
{{10_Rollout_and_Reinforcement_Plan}}- The mission and values roll out with the LinkedIn program starting September 29, 2026. Ben signs off the wording first, the mission page goes live on bennieiv.xyz and the values become the Monday draft checklist. They are reinforced each week through the approval routine and each month through a short review of decisions.
{{LEADERSHIP_SIGNOFF}}- Ben Niehues IV approves mission, vision and values before LI-01 (September 29, 2026).
{{STAFF_LAUNCH}}- Not applicable; one-person brand. Intelligent Operations is briefed through the tenant console.
{{ONBOARDING_UPDATE}}- Values added to the tenant voice rules used by every drafting agent.
{{PROCESS_CHANGES}}- Monday approval uses the four values as a checklist; Friday signals review asks which value a new post would demonstrate.
{{RECOGNITION_ROUTINE}}- Monthly note of the post or decision that best showed the values, kept in the console.
{{01_Market_Category_Definition}}- Ben competes for attention in the category of practitioner thought leadership on product and UX, with a specialism in financial services and credit unions. He is not in the sports-card market commercially; Card Market is a private example of his method. The category is crowded with generic UX advice and vendor content, which makes a sourced, practitioner voice distinct. His frame is product architecture: the system before the screen.
{{MARKET_CATEGORY}}- Practitioner thought leadership on product architecture and UX in financial services.
{{02_Target_Audience_Positioning}}- The primary audience is product, UX and digital-experience leaders at credit unions and community financial institutions who face migrations, insights programs and lending experiences. The secondary audience is product and design peers elsewhere and the Kansas City tech community. They value evidence, candour and feasible advice. Ben meets them as a peer, not a vendor.
{{TARGET_AUDIENCE}}- Product, UX and digital-experience leaders in credit unions and community financial institutions; secondarily product and design peers and the Kansas City tech community.
{{03_Competitive_Positioning_Matrix}}- On one axis, content ranges from interface-level tips to system-level thinking; on the other, from unsourced opinion to sourced evidence. Generic UX influencers sit at interface-level opinion, and fintech vendor content sits at system-level but promotional. Ben's position is system-level and sourced, with no product to sell. That quadrant is thinly occupied in credit union UX.
{{COMPETITIVE_POSITIONING}}- System-level, sourced and non-commercial, compared with interface-level UX advice and promotional fintech vendor content.
{{04_Value_Proposition_Statement}}- For product and UX leaders in financial services, Ben Niehues IV shares how to shape the system someone has to live inside before designing screens. Unlike generic UX advice, his lessons come with sourced results from nearly nine years of credit union work and a builder's sense of what can ship. Readers get methods they can use, from someone who is not selling anything.
{{VALUE_PROPOSITION}}- Systems-first product thinking, with sourced results, from a builder turned UX leader in financial services.
{{05_Brand_Benefits_Hierarchy}}- The functional benefit is reusable methods for research, enablement and measurement. The emotional benefit is the reassurance of hearing from an honest peer. The self-expressive benefit is belonging to a group of builders who care about systems that are worth trusting. All three rest on the evidence discipline at the base.
{{BRAND_BENEFITS}}- Functional: reusable, sourced methods. Emotional: an honest peer voice. Self-expressive: building things worth inhabiting.
{{06_Points_of_Difference_Framework}}- Ben's points of difference are builder roots, provenance by default and financial-services depth. Each is backed by his record: front-end developer to UX leader, the rule that every number says its basis, and credit union work on migrations and lending. Together they are hard for a generalist commentator or a vendor to copy.
{{POINTS_OF_DIFFERENCE}}- Builder-to-leader path; every number names its basis; credit union depth (migration research, Member Insights Playbook, lending experience).
{{07_Points_of_Parity_Framework}}- To be taken seriously, Ben needs what any credible UX voice has: a clear profile, consistent publishing, readable design and proof of shipped work. He has the record and the design discipline; consistency is what the 12-post program adds. A headshot and a live, structured About page are the remaining parity gaps.
{{POINTS_OF_PARITY}}- Regular publishing cadence; professional profile and About page; shipped, measured work; clean visual identity. Gaps: headshot, analytics.
{{08_Brand_Promise_Statement}}- Ben promises that what he shares will be simple, useful and worth trusting. Every number will say what it is based on, and what is unproven will be called unproven. There will be no pitch at the end, only an open invitation.
{{BRAND_PROMISE}}- Simple, useful and worth trusting, with every number showing its basis.
{{09_Positioning_Statement_Structure}}- The positioning statement follows a standard structure: audience, category, difference and reason to believe. It keeps his own line as the idea at the centre. It is used internally to judge drafts, not published verbatim.
{{POSITIONING_STATEMENT}}- For product and UX leaders in financial services, Ben Niehues IV is the practitioner voice on product architecture who shapes the system before the screen, because he has built and led credit union products for nearly nine years and shows the basis of every number.
{{10_Positioning_Testing_Framework}}- Proposed: test the positioning through the first 12 posts by tracking which pillar drives substantive comments and DMs from the primary audience. Ben also asks two or three peers to describe him in one sentence at week 6. If descriptions match the positioning, it holds; if they default to generic UX, the credit union depth is made more prominent.
{{POSITIONING_TESTING}}- Proposed: pillar-level engagement across LI-01 to LI-12, plus a peer one-sentence description test at week 6.
{{11_Positioning_Evolution_Timeline}}- Now to November 2026, the position is established through the 12-post LinkedIn program. From November, the strongest posts become Studio case pages on bennieiv.xyz. In 2027, proposed, the position extends to talks or podcasts once the CACU migration story can be told after launch. Each step builds on results from his LinkedIn profile, credited to CACU and the team; the migration story waits for CACU's release.
{{POSITIONING_EVOLUTION}}- Phase 1 (Sep-Nov 2026): LinkedIn program; Phase 2 (Nov-Dec 2026, proposed): Studio pages; Phase 3 (2027, proposed): talks after the CACU migration.
{{12_Category_Disruption_Strategy}}- Ben's small disruption is to make provenance the norm in product writing: every number labelled with its basis, and unknowns stated plainly. He demonstrates it in his own posts and in the card console, rather than arguing about it. The aim is to raise the standard peers expect, not to create a new category.
{{CATEGORY_DISRUPTION}}- Model provenance-first product writing, where every figure carries its basis and unknowns are named, until peers expect it.
{{01_Primary_Value_Proposition}}- For product, UX and digital-experience leaders, Ben Niehues IV offers a practical view of product architecture: shaping the system someone has to live inside before designing the screens. His writing draws on nearly nine years of credit union product work, including research for a digital banking migration and a member insights program used across 7 departments. The value is a way of working that makes products simple, useful and worth trusting, shared openly by someone who has built as well as led. Nothing is sold; the return for readers is clearer thinking and a peer worth talking to.
{{VALUE_STATEMENT}}- Systems-first product thinking from a builder turned UX leader, so your product is simple, useful and worth trusting.
{{02_Audience_Specific_Value_Statements}}- For credit union and community-bank product and UX leaders, Ben's value is lived experience of the problems they face now: platform migrations, member insights and lending experiences. For product and design peers in other industries, it is a transferable method, the system before the screen and evidence before claims. For the Kansas City product and technology community, it is a local practitioner who shares how he works. For hiring leaders, it is a clear record of shipped, measured work.
{{AUDIENCE_TYPE}}- Primary: product, UX and digital-experience leaders at credit unions and community financial institutions. Secondary: product and design peers in other industries; the Kansas City tech community.
{{VALUE_DESCRIPTION}}- Practical, sourced lessons on product architecture, research-led digital banking and evidence-first measurement, from someone who has done the work.
{{03_Problem_Definition}}- Product teams, especially in financial services, often design screens before anyone has shaped the system underneath, so the costs surface late: at launch, in support queues or in data nobody trusts. Platform migrations make this worse because the old system's hidden rules move with it. Much of the public writing on UX stays at the interface level or leans on claims without evidence. Peers lack plain, sourced accounts of how system-first work is done inside a regulated, member-owned institution.
{{PROBLEM_STATEMENT}}- Teams design the screen before the system and find the real costs on launch day rather than in research.
{{04_Solution_Statement}}- Ben's content shows the method in practice: research early enough to find the cost in study four, programs built so 75+ people can use them, and measurement against a control group. Each post pairs a position with a sourced example from his CACU work or the card console. Readers get patterns they can apply the next week, without a pitch attached.
{{SOLUTION_DESCRIPTION}}- Short, sourced posts and case pages that show system-first product work step by step, each ending with an open invitation to compare notes.
{{05_Unique_Benefits_Description}}- Three benefits set the content apart. It is written by someone who still understands the build, so advice is feasible. It is grounded in dated, sourced results rather than opinion. And it models restraint, showing what not to publish and what not to claim, which is rare in public product writing.
{{BENEFIT_1}}- Builder credibility: advice from a front-end developer turned UX leader, so it respects what can actually be shipped.
{{BENEFIT_2}}- Evidence you can check: every number names its basis, from the 2x email pilot result to the 0 of 15 cards priced.
{{BENEFIT_3}}- Financial-services context: lessons from credit union migrations, lending and member insights that generic UX writing lacks.
{{06_Competitive_Differentiation_Points}}- Against general UX thought leadership, Ben's difference is the depth of one institution's work over nearly nine years, told with numbers and their sources. Against vendor content in fintech, his difference is that he is not selling anything and says so. Both points rest on the same habit: every number says what it is based on.
{{DIFFERENTIATION_POINT_1}}- Practitioner, not vendor: no product, service or course is attached to the content.
{{DIFFERENTIATION_POINT_2}}- Provenance by default: claims carry their source and basis, and unknowns are stated.
{{07_Evidence_and_Proof_Points}}- The proof comes from CommunityAmerica Credit Union work, credited to CACU: the Member Insights Playbook in use by 75+ people across 7 departments; the 2023 Email Pilot, where the pilot group was 2x more likely to qualify for Cashback Checking than control; and the College Cost & Compare Calculator, used by 10,000+ families with a 3x increase in monthly planner meetings. The Card Market console adds a personal example of evidence discipline. These results come from his LinkedIn profile, are public, and are credited to CACU and the teams involved, with Ben's role stated precisely.
{{EVIDENCE_TYPE}}- Dated project outcomes from his LinkedIn profile (employer work, attributed to CACU) and his own project files.
{{PROOF_POINT}}- 2023 Email Pilot: pilot group 2x more likely to qualify for Cashback Checking than control, plus 1,400+ eStatement enrollments (CACU).
{{08_Value_Quantification_Framework}}- Value is measured in reader behaviour, not revenue. The proposed measures are saves and substantive comments per post, and conversations started through bennieiv.xyz/contact or LinkedIn DMs. Baselines are not on record and are captured at week 0 of the program.
{{VALUE_METRIC_1}}- Proposed: substantive comments and saves per LinkedIn post (baseline captured at LI-01, September 29, 2026).
{{VALUE_METRIC_2}}- Proposed: conversations started with product or UX peers via /contact or DMs per month (baseline: not on record).
{{09_Emotional_Value_Components}}- Readers feel they are hearing from a peer rather than being sold to. The candour about unknowns, such as a console with no prices yet, builds trust. The closing invitation makes it easy to reach out without pressure.
{{EMOTIONAL_BENEFIT}}- Reassurance that careful, evidence-first product work is possible and worth the patience.
{{10_Rational_Value_Components}}- Readers get specific patterns: when to research in a migration, how to make an insights program usable across departments, how to test with a control group and how to label a number's basis. Each is tied to a real example they can cite.
{{RATIONAL_BENEFIT}}- Reusable methods for research timing, cross-functional enablement and evidence labelling, each with a worked example.
{{11_Value_Delivery_Timeline}}- Weeks 1-4 deliver the product architecture and credit union case posts (LI-01 to LI-08). Weeks 5-6 deliver the evidence and craft posts (LI-09 to LI-12). After week 6, the strongest posts become Studio case pages on bennieiv.xyz.
{{DELIVERY_PHASE}}- Phase 1 (Sep 29-Oct 22, 2026): LI-01 to LI-08; Phase 2 (Oct 27-Nov 5): LI-09 to LI-12; Phase 3 (proposed, November): Studio pages.
{{12_Value_Proposition_Testing_Framework}}- Proposed: test the value proposition by comparing engagement on system-first posts against case-result posts across the first 12 posts. Comments are read for whether peers repeat the idea in their own words. Ben reviews the pattern at week 6 and adjusts the mix for the next cycle.
{{TESTING_METHOD}}- Proposed: compare saves and substantive comments by topic pillar across LI-01 to LI-12, and log DM themes weekly.
{{RESULTS_ANALYSIS}}- Proposed: a week-6 review that ranks pillars by substantive engagement and keeps the top two as the core of the next cycle.
{{01_Voice_Sample_Collection}}- Ben's voice is collected from three written sources on record: the Summary and Experience sections of his LinkedIn profile, the essays and Studio pages on bennieiv.xyz, and the copy of his private Card Market console. No recorded talks, podcasts or interviews are on file, so spoken samples are a gap to fill with one short recorded conversation. The most authentic sample is his LinkedIn opening, "I practice product architecture," because it states a position before any credential. The collection shows a writer who prefers plain statements, names his limits, and closes with an open invitation rather than a pitch.
{{SPOKEN_SAMPLES}}- None on file. Proposed: record one 20-minute conversation with Ben about the digital banking migration research and transcribe it before LI-02 is finalised.
{{WRITTEN_SAMPLES}}- LinkedIn Summary ("Before a wireframe or a feature, there's a system someone has to live inside"); LinkedIn Experience entries for CommunityAmerica Credit Union; bennieiv.xyz Notebook essays and Studio case pages; Card Market console copy ("Every number says what it is based on"; "Trends start after two priced weeks.").
{{ADMIRED_WRITERS}}- Not on record. Proposed intake question for Ben; until answered, the reference points are the plain, evidence-first style of the Nielsen Norman Group articles already in his RSS feeds.
{{DISLIKED_STYLES}}- Inferred from his writing and brand rules: hype and superlatives, exclamation marks, growth-hack listicles, corporate "we" for work that is his alone, and numbers presented without a basis.
{{MOST_AUTHENTIC_SAMPLE}}- "I practice product architecture. Before a wireframe or a feature, there's a system someone has to live inside, and my work is shaping that system to be simple, useful, and worth trusting."
{{02_Speech_Pattern_Analysis}}- Ben writes in short declarative sentences that carry one idea each, often in pairs where the second sentence sharpens the first. He opens with a position or an observed fact rather than a question or a story set-up. He closes with a low-pressure invitation to peers, most clearly "If you're building something worth inhabiting, or just curious, reach out." Humour is dry and rare, and spoken patterns cannot yet be compared with written ones because no spoken sample is on file.
{{SENTENCE_PATTERNS}}- Short declarative statements; paired sentences where the second narrows the first; lists of three when describing a standard (simple, useful, worth trusting); plain subject-verb order with few clauses.
{{OPENING_HABITS}}- Opens on a position ("I practice product architecture.") or a stated fact from the work ("One week on file, none priced yet."), never on a rhetorical question or a hype line.
{{CLOSING_HABITS}}- Ends with an open invitation to peers ("If you're building something worth inhabiting, or just curious, reach out.") or with the lesson in one line; no hard call to action.
{{HUMOUR_USE}}- Dry and understated, used sparingly through self-aware lines such as "The furniture is square." Never jokes at the expense of members, colleagues or collectors.
{{SPOKEN_WRITTEN_DIFFERENCES}}- Unknown; no spoken sample is on file. Proposed: compare one transcribed conversation with his LinkedIn Summary and note any warmer or looser phrasing to carry into comments.
{{03_Voice_Attribute_Definition}}- Ben's voice rests on four attributes: architectural, candid, restrained and generous. Architectural is primary: he describes the system someone has to live inside before he describes screens or features. Candid means he states limits and unknowns openly, restrained means no hype and one idea per beat, and generous means he closes by inviting peers in rather than selling. Each attribute is drawn from lines already in his LinkedIn profile and his card console copy.
{{VOICE_ATTRIBUTES}}- Architectural; candid; restrained; generous.
{{ATTRIBUTE_BOUNDARIES}}- Architectural, not abstract (always ground the system in a real project); candid, not self-deprecating; restrained, not cold; generous, not salesy.
{{SUPPORTING_EVIDENCE}}- Architectural: "there's a system someone has to live inside." Candid: "1 week on file, none priced yet." Restrained: "The furniture is square." Generous: "If you're building something worth inhabiting, or just curious, reach out."
{{PRIMARY_ATTRIBUTE}}- Architectural: every piece leads with the system people live inside before it discusses artifacts, screens or features.
{{04_Narrative_Stance_Framework}}- Ben writes as a practitioner talking to peers who build products and systems, not as a guru addressing followers. He uses first person singular for his own practice and his card project, and "we" only when describing CommunityAmerica Credit Union team work, which is always credited to the team. He is open about what is unproven or unfinished, such as a console with no priced cards yet, and treats uncertainty as information rather than weakness. He never takes the stance of a vendor, a market caller or an investment adviser.
{{READER_RELATIONSHIP}}- Peer to peer: product, UX and digital-experience builders, especially in credit unions and community financial institutions, addressed as colleagues working on similar problems.
{{FIRST_PERSON_USE}}- "I" for his own practice, opinions and the Card Market side project; "we" only for CACU team work, with the team credited; never corporate "we" for anything that is his alone.
{{VULNERABILITY_LEVEL}}- Moderate and work-focused: he admits unknowns, unfinished data and unproven products, but personal and family details stay brief (the Corning, Kansas farm upbringing is the outer limit).
{{UNCERTAINTY_HANDLING}}- States the unknown plainly and says what would resolve it, as in "Trends start after two priced weeks." Never rounds up or implies a result that has not happened.
{{FORBIDDEN_STANCES}}- Market caller or card-price tipster; investment adviser; vendor pitching a service; spokesperson for CommunityAmerica Credit Union; claiming team results as solo wins; claiming traction for Cellopack.
{{05_Signature_Vocabulary_List}}- Ben's vocabulary comes from building: system, architecture, material, whole, inhabit, basis and evidence. His signature phrases are "a system someone has to live inside," "simple, useful, and worth trusting," and "every number says what it is based on." Metaphors come from architecture and furniture rather than war or sport. Hype words are banned and replaced with plain verbs that describe what was actually done.
{{SIGNATURE_PHRASES}}- "Before a wireframe or a feature, there is a system someone has to live inside"; "simple, useful, and worth trusting"; "every number says what it is based on"; "an ask is not a sale"; "Architecture begins with understanding"; "something worth inhabiting".
{{RECURRING_METAPHORS}}- Architecture and building (foundations, rooms, furniture, living inside a structure); the farm (seasons, patience before harvest) used sparingly.
{{PREFERRED_TERMS}}- System; product architecture; member (not customer) for credit unions; research study; basis; evidence; history; whole; inhabit; ship.
{{BANNED_WORDS}}- Game-changer; revolutionary; disrupt; synergy; hack; crush; unlock; 10x; guru; ninja; must-see; any exclamation mark.
{{PLAIN_SUBSTITUTES}}- "Leverage" becomes "use"; "unlock value" becomes "make useful"; "disrupt" becomes "change"; "best-in-class" becomes a named, sourced fact or is cut.
{{06_Sentence_Rhythm_Rules}}- Ben's rhythm is short and square, mirroring the square furniture of his site. Most sentences run 6 to 16 words, with one longer sentence allowed per paragraph to carry an explanation. Paragraphs on LinkedIn are one to three sentences, and fragments are used only for a deliberate beat. Emphasis comes from placement and white space, not from capitals, bold type or exclamation marks.
{{SENTENCE_LENGTH_RULES}}- Target 6-16 words per sentence; one sentence up to 25 words per paragraph when explaining a mechanism; never two long sentences in a row.
{{PARAGRAPH_LENGTH_RULES}}- LinkedIn: 1-3 sentences per paragraph with a blank line between; bennieiv.xyz essays: up to 5 sentences per paragraph.
{{FRAGMENT_USE}}- Allowed once per post for a beat that lands the point, for example "Not a trend. One point."
{{PUNCTUATION_HABITS}}- Full stops and colons; em dashes sparingly; no exclamation marks; no ellipses for suspense; quotes used to cite exact source lines.
{{EMPHASIS_DEVICES}}- Placement (last line of a paragraph), white space and a single accent idea per post; no all-caps, no emoji, no bold runs.
{{07_Voice_Do_And_Avoid_Guide}}- Do lead with the system, name the basis of every number and credit the CACU team for team results. Do close with an open invitation to peers. Avoid hype, market calls on cards, investment language, and any claim that a side project is a business or has traction. The most common drift is turning a candid observation into a promotional line, and the before-and-after examples show how to pull it back.
{{DO_GUIDANCE}}- Open with a position or a fact; describe the system before the screen; say what each number is based on; credit the team; state what is still unknown; end with an invitation to peers.
{{AVOID_GUIDANCE}}- Hype words and exclamation marks; card values or price predictions; investment advice; new internal employer results that are not on his LinkedIn profile; presenting Card Market or Cellopack as a service with users.
{{COMMON_VOICE_ERRORS}}- Promotional closings ("DM me to learn more"); corporate "we" for his own project; rounding "2x more likely to qualify" into "doubled revenue"; past tense for the Q4 2026 migration before it happens.
{{BEFORE_AFTER_EXAMPLES}}- Before: "I built a game-changing card pricing tool that tracks the market!" After: "I built myself a private console that builds a profile for every card on a list. It has no prices yet, and it says so."
{{08_Sample_Passage_Rewrite}}- The sample rewrite takes a neutral description of the College Cost & Compare Calculator and puts it in Ben's voice. The neutral version reads like a press release and leads with awards. The voiced version leads with the question families were trying to answer, credits CommunityAmerica Credit Union, and keeps the sourced numbers exact. The annotations explain each change so writers can repeat the moves on other projects.
{{NEUTRAL_PASSAGE}}- The award-winning College Cost & Compare Calculator was developed to help families plan for college and has been used by over 10,000 families, resulting in increased engagement with financial planners.
{{VOICED_PASSAGE}}- The tool didn't sell anything. It answered a question families were already asking: what will this school actually cost us? More than 10,000 families used the College Cost & Compare Calculator we built at CommunityAmerica, and monthly planner meetings tripled.
{{CHANGE_ANNOTATIONS}}- Opened on the family's question instead of the award; replaced "increased engagement" with the sourced "monthly planner meetings tripled"; used "we" and named CommunityAmerica to credit the team; dropped "award-winning" pending verification of wording.
{{PASSAGE_TOPIC}}- College Cost & Compare Calculator at CommunityAmerica Credit Union (LI-06, "A calculator that changed the conversation").
{{09_Author_Review_Questions}}- Ben reviews the voice guide by marking which drafted lines sound like him and which do not. The review uses the first four LinkedIn drafts, LI-01 to LI-04, as test material because they cover his core positions. Any line he does not recognise is rewritten or cut, and any new word he rejects is added to the banned list. Answers are recorded before LI-05 is approved.
{{RECOGNISED_LINES}}- Pending Ben's review. Proposed test lines: "Before a wireframe or a feature, there is a system someone has to live inside."; "An insights program that lives in one team's head isn't a program. It's a bottleneck."
{{UNRECOGNISED_LINES}}- Pending Ben's review; the reviewer records any line he marks as not his, with the draft code (for example LI-02) it came from.
{{AUTHOR_CORRECTIONS}}- Pending Ben's review. Proposed questions: Is "member" or "user" right for public posts? Is "product architect" the title he wants to lead with? Which CACU projects beyond the three on his LinkedIn profile does he want to name?
{{NEW_BANNED_WORDS}}- Pending Ben's review; any word he rejects is added to BANNED_WORDS before the next draft batch.
{{10_Voice_Match_Scoring}}- Each draft is scored 1 to 5 on the four attributes, with architectural weighted highest. Vocabulary compliance counts banned words and missing sources, and rhythm compliance checks sentence and paragraph length. A draft scoring below 4 on average, or with any banned word or unsourced number, goes back for revision. Drift is checked across each two-week batch of posts rather than within a single piece.
{{ATTRIBUTE_SCORES}}- Score 1-5 each for architectural (double weight), candid, restrained and generous; record the scores on the draft in the approval queue.
{{VOCABULARY_COMPLIANCE}}- Zero banned words; every number carries its basis or source; "member" used for credit-union contexts; no hype adjectives.
{{RHYTHM_COMPLIANCE}}- At least 80% of sentences at 16 words or fewer; LinkedIn paragraphs no longer than three sentences; no exclamation marks.
{{REVISION_THRESHOLD}}- Revise if the weighted average is below 4.0, if any banned word appears, or if any number lacks a basis.
{{CHAPTER_DRIFT}}- Compare each two-week batch (for example LI-01 to LI-04) against the voice essence; flag if closings drift toward sales language or openings drift toward questions.
{{11_Voice_Guide_Summary}}- Ben Niehues IV writes like an architect talking to peers: plain, candid, and focused on the system people have to live inside. He speaks in first person, credits his CommunityAmerica team for team work, and states what he does not yet know. Every number says what it is based on, and nothing is hyped. The one error to avoid above all is turning an honest observation into a sales line.
{{VOICE_ESSENCE}}- An architect talking to peers: plain, candid, system first, worth trusting.
{{STANCE_SUMMARY}}- Practitioner among peers; "I" for his own work, "we" for credited team work; open about unknowns; never a vendor, adviser or market caller.
{{KEY_VOCABULARY_RULES}}- Use system, basis, evidence, member and inhabit; ban hype words and exclamation marks; replace jargon with plain verbs.
{{PRIMARY_ERROR_TO_AVOID}}- Overclaiming: presenting a team result as a solo win, an ask as a sale, or a side project as a business with traction.
{{01_Expertise_Territory_Questions}}- Ben's deep expertise sits where product architecture meets research-led digital experience in financial services. Fourteen years moving from front-end developer to UX manager at CommunityAmerica Credit Union give him first-hand answers to questions peers keep asking: how to research a platform migration, how to make member insights usable across departments, and how to ship end to end in months. He argues consistently that the system comes before the screen and that evidence must name its basis. He names his own territory in his LinkedIn opening line: product architecture.
{{DEEP_EXPERTISE}}- Product architecture; UX research for digital banking platform migrations; Salesforce-based member insight programs; personalization and experimentation with control groups; front-end build of financial education tools.
{{RECURRING_QUESTIONS}}- How do you research a core digital banking migration before launch? How do you get 75+ people across 7 departments to use an insights tool? How do you ship a credit product end to end in six months? What does product architecture mean in practice?
{{RECURRING_ARGUMENTS}}- The system comes before the wireframe; research findings arrive in study four, not on launch day; an insights program in one team's head is a bottleneck; every number should say what it is based on.
{{FIELD_DISAGREEMENTS}}- Disagrees with screen-first design reviews, with reporting a single data point as a trend, and with treating asking prices or estimates as measured results.
{{SELF_NAMED_TOPIC}}- Product architecture: "I practice product architecture."
{{02_Topic_Landscape_Assessment}}- The candidate topics are product architecture, credit-union digital banking UX, evidence and data provenance, and design craft. UX and product strategy are crowded with established voices such as Nielsen Norman Group and large product-management newsletters, but few practitioners write from inside a credit union's digital banking migration. Audience demand is inferred from the credit union trade press and banking and fintech feeds in his Miniflux categories, which cover platform change regularly. The most open territory is product architecture applied to credit-union digital experience, told by someone doing the work.
{{CANDIDATE_TOPICS}}- Product architecture; research-led digital banking; evidence and provenance; craft and restraint; sports-card market research (side project only).
{{ESTABLISHED_VOICES}}- Nielsen Norman Group and UX Collective (uxdesign.cc) for general UX; credit union trade press and America's Credit Unions for the industry; card-data services such as Card Ladder and Market Movers for card pricing.
{{AUDIENCE_DEMAND}}- Inferred, not measured: his Miniflux categories collected 12 banking and fintech articles and 10 credit union trade press articles in the first weeks, showing steady coverage of platform and member-experience change. No search-volume data is on file.
{{OPEN_ANGLES}}- A practitioner's view from inside a live credit-union digital banking migration; product architecture as a named discipline in financial services; provenance rules borrowed from a side project and applied to product metrics.
{{MOST_OPEN_TERRITORY}}- Product architecture for credit-union digital experience, written by a practitioner currently leading the research.
{{03_Owned_Topic_Statement}}- Ben Niehues IV owns product architecture for digital experience in credit unions and community financial institutions. His angle is that the system someone has to live inside must be shaped before any wireframe or feature, and that every number used to judge it must say what it is based on. The audience is product, UX and digital-experience leaders who carry responsibility for systems members and staff use every day. He introduces the topic in one line: "Before a wireframe or a feature, there is a system someone has to live inside."
{{OWNED_TOPIC}}- Product architecture for credit-union and community-finance digital experience.
{{TOPIC_AUDIENCE}}- Product, UX and digital-experience leaders at credit unions and community financial institutions, plus cross-functional peers who share the systems they build.
{{DISTINCTIVE_ANGLE}}- System before screen, evidence with a stated basis, told from inside an active digital banking migration.
{{INTRODUCTION_LINE}}- Before a wireframe or a feature, there is a system someone has to live inside.
{{04_Topic_Pillar_Framework}}- The owned topic is supported by four pillars. Product architecture covers systems before screens; research-led digital banking covers migrations, member insights and credit-union UX; evidence and provenance covers the rule that every number names its basis; craft and restraint covers the design decisions behind his own site and tools. Each pillar answers its own core question and ties back to the premise that systems should be simple, useful and worth trusting.
{{PILLAR_NAMES}}- Product architecture; Research-led digital banking; Evidence and provenance; Craft and restraint.
{{PILLAR_SCOPES}}- Product architecture: shaping systems before features. Research-led digital banking: migration research, member insights, credit-union UX. Evidence and provenance: basis for every number, asks versus sales, history versus single points. Craft and restraint: one accent, square furniture, deciding not to publish.
{{PILLAR_QUESTIONS}}- What system will people live inside? What will this migration cost members, and when do we learn it? What is this number based on? What should we leave out?
{{PREMISE_CONNECTIONS}}- Each pillar serves the promise that systems are simple (craft and restraint), useful (research-led digital banking), and worth trusting (evidence and provenance), with product architecture as the frame for all three.
{{05_Point_Of_View_Positions}}- Ben takes clear positions against common practice in product and UX work. Where teams start with screens, he starts with the system; where launches are treated as the moment of truth, he argues the cost is discovered in research study four. Where dashboards report a single number, he insists it name its basis and that one week of data is not a trend. Some positions, such as the business value of product architecture as a discipline, still need evidence beyond his CACU projects.
{{CONVENTIONAL_VIEWS}}- Design starts with wireframes; launch day reveals what works; an insights tool succeeds when it ships; one strong data point is enough to call a trend; publishing everything you have is transparency.
{{AUTHOR_POSITIONS}}- Start with the system someone has to live inside; you discover a migration's cost in study four, not on launch day; an insights program in one team's head is a bottleneck; one week of data is not a trend; sometimes the best product decision is not to publish.
{{SUPPORTING_EVIDENCE}}- Four research studies on the Q2 digital banking migration; Member Insights Playbook used by 75+ people across 7 departments; 2023 Email Pilot versus a control group (2x Cashback Checking qualification); Card Market's rule that trends start after two priced weeks; PriceCharting internal-use licence.
{{POSITIONS_NEEDING_EVIDENCE}}- That product architecture reduces rework or cost across projects (no measured data on file); that the migration research changed launch outcomes (Unify launch Aug 2026 and CACU migration Q4 2026 outcomes not yet reported).
{{06_Subtopic_Question_Map}}- Each pillar maps to questions peers actually ask, drawn from the credit union trade press, UX feeds in his RSS list, and the recurring questions in his own career. Questions are recorded in the audience's wording, such as "How do we get staff to actually use member insights?" Ben's answers differ because they come from named, dated CACU projects rather than general advice. The map feeds the LinkedIn schedule and later bennieiv.xyz Notebook essays.
{{PILLAR_QUESTIONS_MAP}}- Product architecture: what is product architecture; where does it sit next to UX and product management. Digital banking: how to research a core platform migration; how to roll out insights to 7 departments. Provenance: how to report numbers honestly; when is data a trend. Craft: how to make fewer, better design decisions.
{{QUESTION_SOURCES}}- Miniflux categories (Banking and fintech; Credit union trade press; Startland News); nngroup.com and uxdesign.cc feeds; LinkedIn comments on LI-01 to LI-12 once published.
{{AUDIENCE_WORDING}}- "How do we get staff to actually use this?"; "What should we test before a platform conversion?"; "Is this number real?"; "What does a product architect do?"
{{DIFFERENTIATED_ANSWERS}}- Answers cite dated CACU team work (Member Insights Playbook, 2023 Email Pilot, migration studies) and his own side-project rules, not generic frameworks, and each states what is still unknown.
{{07_Signature_Framework_Concept}}- Proposed: Ben's signature framework is "Simple, Useful, Worth Trusting," a three-part test for any system before it is designed in screens. Simple asks what the person must understand to live inside the system, useful asks what job it does for them, and worth trusting asks what every number and promise is based on. The framework solves the problem of teams shipping features into systems nobody shaped. The name comes straight from his LinkedIn summary, and availability as a published framework name still needs a check.
{{FRAMEWORK_NAME}}- Proposed: Simple, Useful, Worth Trusting.
{{FRAMEWORK_COMPONENTS}}- Simple: what must a person understand to live inside this system? Useful: what job does it do for them? Worth trusting: what is each number and promise based on?
{{PROBLEM_SOLVED}}- Teams design features and screens before anyone has shaped the system people will live inside, then discover the cost after launch.
{{APPLICATION_STEPS}}- Describe the system in plain words before any wireframe; test each part against the three questions; research until the answers hold (study four, not launch day); name the basis of every number used to judge success.
{{NAME_AVAILABILITY}}- Unchecked. Proposed: search LinkedIn, trademark records and common UX sources for prior use before the name appears in a post.
{{08_Content_Anchor_Plan}}- Each pillar gets one anchor asset on bennieiv.xyz that LinkedIn posts point back to. The first anchors are a Notebook essay on product architecture, Studio case pages for the Member Insights Playbook and the College Cost & Compare Calculator, and a Studio page for Card Market framed as private research. Anchors that mention CACU work use results from his LinkedIn profile, credited to CACU and the team; the product architecture essay is produced first. The LinkedIn series LI-01 to LI-12 runs alongside and links to each anchor as it goes live.
{{ANCHOR_ASSETS}}- Notebook essay "Before a wireframe" (product architecture); Studio case page Member Insights Playbook; Studio case page College Cost & Compare Calculator; Studio page Card Market (private research); Field Note "The furniture is square."
{{PILLAR_ANCHORS}}- Product architecture: "Before a wireframe" essay. Research-led digital banking: Member Insights Playbook case page. Evidence and provenance: Card Market Studio page. Craft and restraint: "The furniture is square" Field Note.
{{ASSET_DEPENDENCIES}}- CACU case pages use LinkedIn-profile results credited to CACU, and anything new needs the employer's OK; award mentions need verified wording; migration dates need confirmation before past tense; Card Market page must show no card values.
{{PRODUCTION_ORDER}}- 1. Product architecture essay (supports LI-01); 2. Card Market Studio page (LI-08 to LI-11); 3. Craft Field Note (LI-12); 4. CACU case pages built on his LinkedIn-profile results (LI-03 to LI-06).
{{09_Topic_Boundary_Rules}}- Ben declines topics that would turn him into a market caller, an adviser or an employer spokesperson. Requests to price cards, predict player or card values, or comment on CommunityAmerica business matters are redirected to his principles on evidence and systems. Every candidate topic must pass a fit test against the four pillars. The only allowed exceptions are personal milestones he chooses to share and credited team announcements already public.
{{DECLINED_TOPICS}}- Card values, price predictions or investing in cards; CACU financial results, strategy or unreleased product news; politics; general career-coaching listicles.
{{REDIRECT_RULES}}- A card-price question becomes a post about value basis and evidence; a question about CACU plans becomes a post about the research method, not the result.
{{FIT_TEST}}- Does it serve product architecture, research-led digital banking, evidence and provenance, or craft and restraint, and can Ben speak from work he did himself?
{{ALLOWED_EXCEPTIONS}}- Public, credited CACU team announcements; personal milestones Ben chooses to share; the Card Market side project described as private research.
{{10_Authority_Signal_Measures}}- Authority is measured through invitations, citations and search signals rather than follower counts alone. Invitations include requests to speak, write or advise from credit-union and product communities; citations include reshares and mentions by peers. Baselines are mostly not on record, so week-zero readings are captured when LI-01 publishes on Sep 29, 2026. Signals are reviewed monthly and summarised at the end of the 12-post series.
{{INVITATION_SIGNALS}}- Speaking, podcast, panel or guest-writing invitations; inbound conversations started via bennieiv.xyz/contact or LinkedIn messages that reference a post.
{{CITATION_SIGNALS}}- Reshares or quotes of his posts by product, UX or credit-union peers; links to bennieiv.xyz essays from other sites.
{{SEARCH_SIGNALS}}- Proposed: track search impressions for "Ben Niehues" and "product architecture credit union" once analytics are set up on bennieiv.xyz; no analytics on record today.
{{BASELINE_READINGS}}- Instagram @bennieiv 2,431 followers (2026-09-25); LinkedIn followers, site sessions and invitation count not on record, to be captured at week 0.
{{REVIEW_CADENCE}}- Monthly review of signals, plus a full read-out after LI-12 on Nov 5, 2026.
{{11_Topic_Ownership_Summary}}- Ben Niehues IV owns product architecture for credit-union and community-finance digital experience. Four pillars carry it: product architecture, research-led digital banking, evidence and provenance, and craft and restraint. His defining position is that the system someone has to live inside comes before any wireframe, and that every number must say what it is based on. The proposed "Simple, Useful, Worth Trusting" framework gives peers a way to apply it.
{{TOPIC_SUMMARY}}- Product architecture for credit-union and community-finance digital experience, from a practitioner doing the work.
{{PILLAR_SUMMARY}}- Product architecture; Research-led digital banking; Evidence and provenance; Craft and restraint.
{{POSITION_SUMMARY}}- System before screen; migration costs surface in research, not on launch day; every number names its basis; one week of data is not a trend.
{{FRAMEWORK_SUMMARY}}- Proposed "Simple, Useful, Worth Trusting": three questions every system must answer before it is drawn as screens.
{{01_Main_Value_Proposition}}- Ben Niehues IV helps product, UX and digital-experience leaders shape the system people have to live inside before a single wireframe is drawn. He brings fourteen years of building, from front-end developer to UX manager at CommunityAmerica Credit Union, where his teams' work reached 75+ staff across 7 departments and 10,000+ families. The promise is systems that are simple, useful and worth trusting, with every number stating what it is based on. His writing on LinkedIn and bennieiv.xyz shares that practice openly with peers.
{{VALUE_PROPOSITION}}- Product architecture that shapes the system people live inside, so what ships is simple, useful and worth trusting.
{{02_Main_Result}}- The result of Ben's approach is a system that people actually use, not a feature list that ships and stalls. At CommunityAmerica Credit Union that looked like a Member Insights Playbook used by 75+ people across 7 departments and a Credit Score plus Lending Recommendation shipped end to end in six months. The same discipline shows in his side project, where the console says plainly that no card is priced yet. Results are always credited to the CACU team where the work was shared.
{{RESULT}}- Systems people use: a Member Insights Playbook adopted by 75+ people across 7 departments at CACU, and a credit product shipped end to end in six months.
{{03_Main_Impact}}- The impact is felt by the members and staff who live inside the systems. In CACU's 2023 Email Pilot, members who received personalized insights were 2x more likely to qualify for Cashback Checking than the control group, and 1,400+ enrolled in eStatements. The College Cost & Compare Calculator helped 10,000+ families answer what school would really cost, and monthly planner meetings tripled. For peers reading his work, the impact is a clearer method they can bring to their own institutions.
{{IMPACT}}- Members and staff get systems that help: 2x Cashback Checking qualification versus control in the 2023 Email Pilot and 10,000+ families using the college calculator (CACU team results).
{{04_Main_Outcome}}- The outcome Ben works toward is trust: members trust the numbers they see, staff trust the tools they use, and teams trust the research before launch. He gets there by researching early, as in the four studies behind the Q2 digital banking migration, and by insisting every figure names its basis. For readers, the outcome is a shared vocabulary for product architecture in financial services. Target: by Nov 5, 2026, all twelve LinkedIn posts in the series published and each linked to a bennieiv.xyz anchor.
{{OUTCOME}}- Systems members and staff can trust, built on research done before launch and numbers that say what they are based on.
{{05_Main_Function}}- Ben's practice functions as product architecture: defining the system, its parts and how people move through it before design and development begin. In practice that means leading research strategy, shaping the member and staff experience, and aligning teams across departments. His front-end background lets him judge what is buildable, and his Card Market console shows the same thinking applied to data provenance. The public function of this program is to share that practice with peers through LinkedIn and bennieiv.xyz.
{{FUNCTION}}- Product architecture: shaping the system, research and cross-functional alignment before screens and code.
{{06_Main_Purpose}}- The purpose, in Ben's words, is "architecture as a way of shaping the systems people live inside. Applied to a life, and the products I build." He wants the systems he touches to be simple, useful and worth trusting. The thought-leadership program exists to make that practice visible to people building similar systems. It is not a sales effort and it offers no service for hire.
{{PURPOSE}}- Architecture as a way of shaping the systems people live inside, applied to a life and the products he builds.
{{07_Main_Objective}}- The objective of the program is to establish Ben as a recognised practitioner voice on product architecture for credit-union and community-finance digital experience. Proposed: publish all twelve posts LI-01 to LI-12 on schedule between Sep 29 and Nov 5, 2026, and stand up four bennieiv.xyz anchor pages. Baselines for LinkedIn followers and site sessions will be captured at week zero. Success is judged by invitations and peer conversations, not by volume alone.
{{OBJECTIVE}}- Proposed: become a recognised practitioner voice on product architecture in credit-union digital experience, starting with 12 posts on schedule by Nov 5, 2026.
{{08_Main_Rationale}}- The rationale is that few practitioners write from inside a credit union's digital banking work while it is happening. Ben has the projects, the research and the build history to speak with specifics rather than general advice. His habit of naming the basis of every number sets his writing apart in a field full of rounded claims. Sharing the method openly also makes it easier for peers to reach out, which his LinkedIn summary already invites.
{{RATIONALE}}- He has specific, dated, team-credited work to draw on and a rare habit of stating the basis for every claim.
{{09_Main_Use_Case}}- The main use case is a product or UX leader at a credit union preparing for a digital banking platform migration. They read Ben's post on research before a migration, follow the link to his essay on bennieiv.xyz, and take away the idea that the migration's real cost appears in research, not on launch day. They apply the "Simple, Useful, Worth Trusting" questions to their own plan. If the problem is close to theirs, they reach out to compare notes.
{{10_Main_Hook}}- The main hook is Ben's opening line from his LinkedIn summary, which frames every post in the series. It challenges the habit of starting with screens and invites the reader to picture the system instead. It is short, concrete and in his own voice. It opens LI-01 on Sep 29, 2026.
{{HOOK}}- Before a wireframe or a feature, there is a system someone has to live inside.
{{11_Main_Jobs_to_Be_Done}}- Peers come to Ben's writing to get a job done: plan a system before designing it, research a migration before it reaches members, and report results honestly. They want practical, credit-union-specific examples rather than generic frameworks. They also want reassurance that someone else has faced the same cross-departmental problems. The Card Market posts add a smaller job: seeing how to build provenance into data tools.
{{JOBS_TO_BE_DONE}}- Shape a system before designing screens; research a digital banking migration before launch; get insights used across departments; report numbers with their basis.
{{12_Main_User_Story}}- The user story centres on a UX lead at a community financial institution with a platform conversion on the calendar. Before, their team was designing screens against a date and hoping launch would go well. After reading Ben's series, they plan a sequence of research studies and write down the system members will live inside first. They know the method came from a practitioner doing the same work, which makes it easier to bring to their leadership.
{{USER_STORY}}- As a UX lead facing a platform migration, I want to know what the system will cost members before launch so that I can fix it in research rather than on launch day.
{{13_Main_Benefit}}- The main benefit for readers is a working method they can use on Monday morning. They get product architecture explained through real credit-union projects, not abstractions. They also get a model for honest reporting, where every number says what it rests on. And they get a peer they can reach, since each post ends with an open invitation to talk.
{{BENEFIT}}- A practical, credit-union-tested method for shaping systems before screens, and for reporting results honestly.
{{14_Main_Feature}}- The defining feature of Ben's writing is evidence with a stated basis. Every post cites a dated project, a named source or an explicit unknown. The Card Market console carries the same feature into software with a Value Basis column that says whether a number is a guide value, sold comps or an ask. That consistency between what he writes and what he builds is the feature readers can check for themselves.
{{FEATURE}}- Every number says what it is based on, in his posts and in the tools he builds.
{{15_One_liner}}- The one-liner states who Ben is and what he does in a single breath. It pairs his discipline with his location and his promise. It is used in LinkedIn intros, bennieiv.xyz metadata and speaker bios. It avoids titles that belong to his employer so it stays valid if his role changes.
{{ONE_LINER}}- Ben Niehues IV is a Kansas City product architect who shapes the systems people live inside to be simple, useful and worth trusting.
{{16_Summary}}- The summary gives a short account of Ben's background and focus. It moves from the Corning, Kansas farm to front-end development, then to leading UX at CommunityAmerica Credit Union. It names the kind of work he does and how he measures it. It ends with his open invitation to peers.
{{SUMMARY}}- Ben Niehues IV grew up on a crop farm in Corning, Kansas, started his career as a front-end developer and now leads user experience at CommunityAmerica Credit Union in Kansas City. He practices product architecture, shaping the systems members and staff live inside before any wireframe is drawn. If you're building something worth inhabiting, or just curious, reach out.
{{17_Description}}- The description is the fuller third-person account used on bennieiv.xyz and in bios. It names his discipline, his employer and his signature team projects. It keeps team results attributed to CommunityAmerica Credit Union. It mentions the Card Market console only as private research.
{{DESCRIPTION}}- Ben Niehues IV is a product architect and UX leader in Kansas City with fourteen years of experience, now Manager, User Experience at CommunityAmerica Credit Union. His teams' work includes the Member Insights Playbook, the 2023 Email Pilot and the College Cost & Compare Calculator; he also runs a private sports-card research console as a side project.
{{18_Overview}}- The overview sets out the thought-leadership program as a whole. It runs on LinkedIn from Sep 29 to Nov 5, 2026, with posts on Tuesdays and Thursdays and anchor pages on bennieiv.xyz. It covers four pillars: product architecture, research-led digital banking, evidence and provenance, and craft and restraint. Drafts are approved every Monday and checked against source research before they publish.
{{OVERVIEW}}- A 12-post LinkedIn series (LI-01 to LI-12, Sep 29 to Nov 5, 2026) across four pillars, each linked to anchor pages on bennieiv.xyz.
{{19_Synopsis}}- The synopsis compresses Ben's story into its arc. A builder became an architect by learning that systems matter more than screens. He tested that idea on real credit-union products and a private side project. Now he shares what he learned with peers who are building similar systems.
{{SYNOPSIS}}- A front-end developer turned UX leader shows how shaping the system first makes products simple, useful and worth trusting.
{{20_Excerpt}}- The excerpt is a short passage drawn from the LI-10 draft that shows his voice on evidence. It uses his own console's state as the example. It is suitable for pull quotes on bennieiv.xyz and share images. It contains no card values.
{{EXCERPT}}- My own console tells me: one week on file, none priced yet. Trends start after two priced weeks. It would be easy to draw a line through a single point. I built the tool so I couldn't.
{{21_Definition}}- Product architecture needs a plain definition because readers will meet the term for the first time. Ben's definition focuses on the system rather than the deliverable. It separates the discipline from visual design and from project management. It is used at the top of the "Before a wireframe" essay.
{{DEFINITION}}- Product architecture is the work of shaping the system someone has to live inside, its parts, rules and flows, before any wireframe or feature is designed.
{{22_Explanation}}- The explanation shows why product architecture matters in credit-union digital experience. Members and staff live inside systems such as digital banking platforms and Salesforce workflows every day. When those systems are shaped late, cost shows up after launch; when they are shaped early, research catches it. Ben explains this through his teams' migration research and member insight work.
{{EXPLANATION}}- When the system is shaped first, research finds the problems (in study four, not on launch day), and the screens that follow are simpler, more useful and easier to trust.
{{01_Target_Market_Overview}}- Ben's target market is the professional community that builds digital experiences in financial services, with credit unions and community financial institutions at the centre. These readers are product, UX and digital-experience leaders who carry systems that members and staff use every day. A secondary market is cross-functional peers and the Kansas City product and tech community, including readers of Startland News. The market is defined by shared problems, not by purchasing, because the program sells nothing.
{{TARGET_MARKET_OVERVIEW}}- Product, UX and digital-experience leaders in credit unions and community financial institutions; secondarily cross-functional peers and the Kansas City product community.
{{02_Ideal_Customer_Profile}}- The ideal reader is a UX, product or digital-experience manager or director at a credit union or community bank. They are preparing for or living through a digital banking platform change, or trying to get member insights used across departments. They value evidence and plain language over trend pieces. They are likely to comment, compare notes and, in time, invite Ben to speak or collaborate.
{{IDEAL_CUSTOMER_PROFILE}}- UX, product or digital-experience manager or director at a credit union or community bank, facing a platform migration or insights rollout, who values plain evidence.
{{03_Primary_Target_Segment}}- The primary segment is digital-experience leaders at credit unions going through core or digital banking platform migrations. Ben's current research on CACU's Q2 migration and the working relationship with Unify Credit Union make this the segment he can speak to most specifically. They read credit union trade press and follow peers on LinkedIn. Posts LI-02 to LI-05 are written for them first.
{{PRIMARY_TARGET_SEGMENT}}- Digital-experience and UX leaders at credit unions planning or running digital banking platform migrations.
{{04_Target_Market_Segments}}- Four segments make up the audience. Credit-union digital-experience leaders are primary; product and UX practitioners across industries are second; Kansas City's product and tech community is third; hiring and partnership leaders are fourth. Collectors trading across platforms would be a fifth segment only if Cellopack comes into scope. Each segment maps to at least one pillar of the content plan.
{{TARGET_MARKET_SEGMENTS}}- Credit-union and community-finance digital-experience leaders; product and UX practitioners generally; Kansas City product and tech community; hiring and partnership leaders; collectors (only if Cellopack is in scope).
{{05_Customer_Personas}}- Three personas guide the writing, all proposed and unvalidated. The Migration Lead is a UX or digital manager at a credit union with a platform conversion on the calendar. The Insights Owner runs a member-insights or CRM program and struggles to get adoption beyond one team. The Builder is a designer or developer moving toward product leadership who sees Ben's path from front-end developer to UX manager as a model.
{{CUSTOMER_PERSONAS}}- Proposed: the Migration Lead (credit-union UX or digital manager facing a platform conversion); the Insights Owner (runs a CRM or member-insights program); the Builder (designer or developer moving toward product leadership).
{{06_Target_Market_Industry_Companies_Job_Titles_Overview}}- The core industry is credit unions and community financial institutions, with fintech and digital banking providers alongside. Organisations include credit unions of CommunityAmerica's scale and the digital banking platforms they run on, though no named target companies are on record. Job titles include UX Manager, Director of Digital Experience, Product Manager, Product Owner, Member Experience Manager and CX lead. Secondary titles include front-end developers and designers moving into leadership.
{{TARGET_MARKET_INDUSTRY_COMPANIES_JOB_TITLES_OVERVIEW}}- Credit unions, community banks and digital banking providers; titles: UX Manager, Director of Digital Experience, Product Manager, Product Owner, Member Experience Manager, CX lead.
{{07_Customer_Insights_Behaviors_Overview}}- These readers learn from peers more than from vendors, and they skim LinkedIn for concrete examples from institutions like theirs. They follow credit union trade press and UX sources such as Nielsen Norman Group. They are wary of vendor-sponsored content and rounded claims. Proposed: validate these behaviours through comment patterns on LI-01 to LI-06.
{{CUSTOMER_INSIGHTS_BEHAVIORS_OVERVIEW}}- Peer-led learning on LinkedIn; reads credit union trade press and UX research sources; skeptical of vendor claims; responds to specific, dated examples.
{{08_Customer_Goals_Desires_Motivations_Overview}}- Their goals are practical: land a platform migration without hurting members, get their insights work used, and grow into broader product leadership. They want credibility inside their own institution, which comes from research and honest numbers. They are motivated by serving members well, which fits Ben's credit-union background. Many also want a peer network outside their organisation.
{{CUSTOMER_GOALS_DESIRES_MOTIVATIONS_OVERVIEW}}- Land migrations without hurting members; get insights adopted; grow into product leadership; earn internal credibility with research and honest numbers.
{{09_Customer_Communication_Engagement_Overview}}- The audience engages mainly on LinkedIn, reading posts in the working week and commenting when a post matches their own experience. They follow links to longer pieces when the post promises a method. Direct messages and contact forms are used for peer conversations rather than sales. Ben's cadence of Tuesday and Thursday posts with Wednesday engagement matches that pattern.
{{CUSTOMER_COMMUNICATION_ENGAGEMENT_OVERVIEW}}- LinkedIn posts on weekdays, comments on familiar problems, click-through to longer bennieiv.xyz pieces, and direct messages for peer conversations.
{{10_Customer_Problems_Pain_Points_Overview}}- Their main problem is that systems are designed screen first and problems surface after launch. Insight programs stall in one team, and cross-department adoption is hard. Reported numbers are often rounded or lack a basis, which weakens decisions. Platform migrations bring tight timelines, vendor constraints and member risk all at once.
{{CUSTOMER_PROBLEMS_PAIN_POINTS_OVERVIEW}}- Screen-first design that hides system problems until launch; insight programs stuck in one team; numbers without a basis; high-risk platform migrations on fixed dates.
{{11_Customer_Personalities_Archetypes_Overview}}- The audience leans toward the pragmatic builder: people who prefer evidence to inspiration and systems to slogans. Many are quiet readers who engage only when a post is specific enough to be useful. A smaller group are community connectors in Kansas City and credit-union circles who reshare and introduce. Ben's restrained voice suits both.
{{CUSTOMER_PERSONALITIES_ARCHETYPES_OVERVIEW}}- Pragmatic builders who value evidence; quiet readers who engage on specifics; community connectors who reshare and introduce.
{{12_Customer_Transformation_Overview}}- Readers move from designing screens against a date to shaping the system first and researching early. They move from reporting single numbers to naming the basis of each one. They move from working alone inside one institution to belonging to a peer conversation. The change is in method and confidence, not in anything purchased.
{{CUSTOMER_TRANSFORMATION_OVERVIEW}}- From screen-first and launch-day surprises to system-first research; from unbased numbers to stated evidence; from isolated to connected with peers.
{{13_Storybrand_Script}}- In the StoryBrand frame, the reader is the hero: a digital-experience leader facing a system members must live inside. The problem is screen-first work that hides costs until launch. Ben is the guide, with fourteen years of building and a practice of stating the basis for every claim. The plan is to shape the system, research until the answers hold, and report honestly; the call to action is to reach out, and success is a system that is simple, useful and worth trusting.
{{STORYBRAND_SCRIPT}}- Hero: a credit-union digital-experience leader. Problem: screen-first work and launch-day surprises. Guide: Ben, a builder turned product architect. Plan: shape the system, research early, name every number's basis. CTA: "If you're building something worth inhabiting, or just curious, reach out." Success: a system members and staff trust.
{{01_Anecdotal_Hook}}- The anecdotal hook draws on Ben's own path. He started at CommunityAmerica Credit Union as a front-end developer and now leads its user experience work. That story makes the lesson concrete: he learned to trust systems over screenshots because he built them. It opens LI-07.
{{PERSONAL_TOUCH}}- "I lead UX at a credit union. I started there as a front-end developer."
{{02_Four_Us_Hooks}}- The Four Us hook aims to be useful, unique, ultra-specific and, without false urgency, timely. For Ben it pairs a specific CACU team result with a lesson peers can apply. Urgency is kept honest by tying it to real work on the calendar, such as the Q4 2026 migration. It uses plain language and no hype words.
{{CLEAR_LANGUAGE}}- "Six months, end to end: a Credit Score and Lending Recommendation, soft credit pull included. Here is what made the scope possible."
{{03_PAS_Hooks}}- The problem-agitate-solve hook starts with a problem peers recognise: insight programs that never leave one team. It agitates by naming the cost, a bottleneck no one can see. It solves by pointing to the Member Insights Playbook rolled out to 75+ people across 7 departments. It opens LI-03.
{{CLEAR_IDENTIFICATION_OF_THE_PROBLEM}}- "An insights program that lives in one team's head isn't a program. It's a bottleneck."
{{04_AIDA_Hooks}}- The AIDA hook moves from attention to action in a few lines. Attention comes from a counter-intuitive claim about migrations, interest from the four research studies, and desire from avoiding launch-day surprises. Action is the low-pressure invitation to compare notes. It opens LI-02.
{{ENGAGING_OPENING}}- "You don't discover what a digital banking migration will cost you on launch day. You discover it in study four."
{{05_5_Ws_Hook}}- The 5 Ws hook answers who, what, when, where and why in a compact opening. It suits the College Cost & Compare Calculator story because every element is on record. It keeps credit with CommunityAmerica Credit Union. Award wording is left out until verified.
{{CLEAR_ANSWERS_TO_EACH_OF_THE_5_WS}}- Who: 10,000+ families. What: the College Cost & Compare Calculator. Where: CommunityAmerica Credit Union, Kansas City. When: during Ben's front-end years (2017-2021). Why: to answer what college would actually cost.
{{06_Story_Hook}}- The story hook sets a scene with real characters. Ben, a product architect, builds himself a private console for tracking sports cards. The console refuses to show a value it cannot back up. The story leads into LI-08 and the provenance posts that follow.
{{CHARACTERS}}- Ben (the builder); his private Card Market console; fifteen graded rookie cards, including a 2017 Panini Prizm Patrick Mahomes PSA 10.
{{07_Bridge_Hook}}- The bridge hook starts from a commonly accepted idea and crosses to Ben's position. Most teams accept that a dashboard number is a fact. Ben bridges to the idea that a number is only as good as its stated basis. It opens LI-09.
{{COMMONLY_ACCEPTED_IDEAS}}- "A price is a price." Bridge: "An ask is not a sale. I built that rule into a tool so I couldn't quietly forget it."
{{08_Value_Proposition_Hooks}}- The value proposition hook states what readers gain from following Ben. The benefit is unique because it comes from a practitioner inside credit-union digital work. It promises method, not motivation. It is used in the LinkedIn featured section and bennieiv.xyz intro.
{{UNIQUE_BENEFITS}}- "How to shape the system members live inside, from someone doing it at a credit union right now."
{{09_Cliffhanger_Hook}}- The cliffhanger hook withholds the answer to a real open question. Ben's console has one week of data and no prices. The honest suspense is what the second priced week will show, and he promises to report it with its basis. It suits LI-10.
{{SUSPENSE}}- "One week on file, none priced yet. What happens at week two is the point of the whole tool."
{{10_Testimonial_Hooks}}- Testimonial hooks are not used yet, because no testimonials, reviews or quotes from colleagues are on record. Proposed: after the series, ask two CACU colleagues who worked on the Member Insights Playbook for a short attributed comment, with the employer's OK. Until then, hooks lean on sourced project facts instead. No names are used without written permission.
{{REAL_CUSTOMER_NAMES}}- None on record. Proposed: collect named, permissioned comments from CACU teammates after LI-12; do not publish any until approved.
{{11_How_to_Hooks}}- The how-to hook promises a method in a few clear steps. It uses the proposed Simple, Useful, Worth Trusting questions as the steps. It suits a bennieiv.xyz Notebook essay and the LI-01 follow-up. Each step is phrased as a question readers can use.
{{STEP_BY_STEP_INSTRUCTIONS}}- "How to shape a system before the wireframe: 1. Describe what someone must understand to live inside it. 2. Name the job it does for them. 3. Write down what each number and promise is based on."
{{12_Shock_Factor_Hook}}- The shock factor hook uses a surprising but true fact rather than a sensational one. Ben's own tool reports zero priced cards out of fifteen. That candour surprises readers used to confident dashboards. It fits LI-10 and LI-11.
{{A_SHOCKING_FACT}}- "My card console tracks 15 cards. It has priced exactly none of them, and it tells me so."
{{13_Statistical_Hook}}- The statistical hook leads with a sourced number and names its basis. The strongest is the 2023 Email Pilot result against a control group. It is credited to the CACU team. It opens LI-05.
{{RELEVANT_STATISTICS}}- "Against a control group, members in our 2023 Email Pilot were 2x more likely to qualify for Cashback Checking, and 1,400+ enrolled in eStatements."
{{14_Question_Hook}}- The question hook asks something peers must answer for themselves. It avoids rhetorical fluff by asking about their own system. It is used sparingly, since Ben usually opens on a position. It suits comment prompts and the product architecture essay.
{{CLEAR}}- "Before your next wireframe: can you describe, in plain words, the system someone will have to live inside?"
{{15_Comparison_Hook}}- The comparison hook sets two approaches side by side. Screen-first work is compared with system-first work, or a single data point with a history. The comparison is clear and uses his own examples. It suits LI-01 and LI-10.
{{CLEAR_COMPARISONS}}- "A screenshot shows what a product looks like. A system shows what it is like to live inside."; "One sale is a point. Eight weeks is a history."
{{16_FOMO_Hook}}- A fear-of-missing-out hook does not suit Ben's restrained voice and is used only in an honest form. The only urgency is real timing, such as a migration on the calendar. It never pressures readers to act. It can open a post aimed at teams with a conversion ahead.
{{URGENCY}}- "If your platform conversion is next year, the research that matters is this year."
{{17_The_Guarantee_Hook}}- Guarantee hooks are not used, because Ben sells nothing and promises no outcomes. The honest substitute is a commitment about his own practice. He guarantees only that every number he shares will say what it is based on. That line doubles as a trust signal.
{{CLEAR_GUARANTEE_TERMS}}- No outcome guarantees. Commitment only: "Every number I share will say what it is based on, and I will tell you when I don't know."
{{18_The_Scarcity_Hook}}- Scarcity hooks are not used in a sales sense. Where numbers appear, they describe real limits of his own work, such as the fifteen cards on his watchlist or the five per sport. These specific numbers show focus rather than pressure. They suit LI-08.
{{SPECIFIC_NUMBERS}}- "Fifteen cards. Five per sport. One week on file. That is the whole watchlist, on purpose."
{{19_The_Authority_Hook}}- The authority hook leans on Ben's own record and on named sources he actually uses. He cites his fourteen years of building and his current role leading UX at CommunityAmerica Credit Union. Where outside authority helps, he names the data sources his console relies on. Award names are held until their wording is verified.
{{NAMES_OF_AUTHORITIES}}- CommunityAmerica Credit Union (employer, credited for team work); Kansas State University (B.S. MIS); General Assembly (UX Design Program); ESPN, eBay APIs and PriceCharting as named data sources.
{{20_The_Social_Proof_Hook}}- The social proof hook relies on documented use of the systems his teams built, not on testimonials. The Member Insights Playbook is used by 75+ people across 7 departments, and the college calculator reached 10,000+ families. Both are CACU team results and are credited that way. No invented quotes or reviews are used.
{{REAL_USER_EXPERIENCES}}- "75+ people across 7 departments use the Member Insights Playbook we built at CommunityAmerica; 10,000+ families used the College Cost & Compare Calculator."
{{01_Exploring_Emerging_Trends_in_Industry}}- The anchor article explores one trend Ben sees across credit-union digital experience: platform migrations and personalization projects are forcing teams to design the system members live inside before they design screens. It draws on his own work at CommunityAmerica Credit Union, where the Q2 digital banking migration research has run four studies ahead of launch. The article treats the trend as a practical shift in how product and UX teams sequence work, not as a forecast. Every example is attributed to the CACU team; results come from his LinkedIn profile, and unreleased migration details are left out until CACU releases them.
{{PROBLEM_SOLUTION_HOOK}}- You don't discover what a digital banking migration will cost you on launch day; you discover it in study four. Proposed title: "Before a Wireframe, a System: What a Digital Banking Migration Teaches About Product Architecture."
{{01_H1_Heading_Title_as_a_Problem_Solution_Hook}}- The H1 pairs the problem (surprises that surface only at launch) with the solution (research and system design done before screens). Proposed H1: "Before a Wireframe, a System: What a Digital Banking Migration Teaches About Product Architecture." It is short, plain and free of hype, and it reuses Ben's own positioning line so the article and the LinkedIn series read as one voice. The same line opens LI-01, "Product architecture before pixels."
{{PROBLEM_SOLUTION_HOOK}}- You don't discover what a digital banking migration will cost you on launch day; you discover it in study four. Proposed title: "Before a Wireframe, a System: What a Digital Banking Migration Teaches About Product Architecture."
{{02_The_Impact_of_Technology_on_Social_Change}}- This section connects technology choices to the people who live with them: members managing money and front-line staff serving them. Ben's College Cost & Compare Calculator is the example, a tool that answered a family's question instead of selling a product and was used by 10,000+ families at CACU. The point is that a well-architected tool changes the conversation between an institution and the people it serves. Award and usage figures are stated as reported on his profile and verified before publishing.
{{SUBHEADING}}- Why the systems behind digital banking decide whether members trust what they see, and how research sequenced before screens keeps a migration simple, useful and worth trusting.
{{02_H1_Subheading_Preparing_for_Future_Success_and_Transformation}}- The subheading sets up the promise of the article in one sentence: preparing for a platform change means shaping the system first. Proposed subheading: "Why the systems behind digital banking decide whether members trust what they see, and how research sequenced before screens keeps a migration simple, useful and worth trusting." It mirrors Ben's stated aim of systems that are simple, useful and worth trusting. It avoids future claims about launch outcomes that have not happened yet.
{{SUBHEADING}}- Why the systems behind digital banking decide whether members trust what they see, and how research sequenced before screens keeps a migration simple, useful and worth trusting.
{{03_Strategies_for_Effective_Leadership_in_a_Digital_Age}}- Leadership here means cross-functional enablement: getting research, product, data and branch staff to share one picture of the member. Ben's example is the Member Insights Playbook in Salesforce, rolled out to 75+ people across 7 departments with a soft launch in November 2024 and full launch in January 2025. The lesson he draws is that an insights program living in one team's head is a bottleneck, not a program. The section closes on what a leader does first: define the system people will work inside, then staff it.
{{DEFINE_THE_PROBLEM}}- Digital banking teams often start with screens and features, then discover late that the underlying data, workflows and member expectations do not fit together. The cost shows up at launch, when changes are most expensive and member trust is most exposed.
{{03_H1_Body_Text_Introduction_Problem_Solution_and_Context}}- The introduction states the problem plainly: teams design screens before they understand the system members and staff live inside, and the gaps surface at launch. It then names the solution Ben practices, product architecture, which shapes that system first so it is simple, useful and worth trusting. Context comes from his role leading UX at CommunityAmerica Credit Union during the Q2 digital banking platform migration, with launch dates confirmed before publication. The tone is first person, short sentences, and no claims beyond what the research shows.
{{DEFINE_THE_PROBLEM}}- Digital banking teams often start with screens and features, then discover late that the underlying data, workflows and member expectations do not fit together. The cost shows up at launch, when changes are most expensive and member trust is most exposed.
{{04_The_Role_of_Innovation_in_Business_Growth}}- Innovation in this article is modest and specific: small, measured changes that move member behavior. The 2023 Email Pilot at CACU is the example, where a pilot group receiving personalized member insights was 2x more likely to qualify for Cashback Checking than the control group and drove 1,400+ eStatement enrollments. Ben frames growth as the result of testing against a control, not of launching features. The results come from his LinkedIn profile and are credited to the CACU team.
{{REFERENCE_TO_SPECIFIC_PAST_CHALLENGES}}- Member insights that sat inside one team and did not reach bankers; personalization ideas that had not been tested against a control group; tools built as features rather than answers to a member's actual question.
{{THE_IMPACT_OF_THESE_STRUGGLES_ON_THE_INDUSTRY}}- Credit unions risk shipping digital experiences that look modern but do not change member outcomes, and they learn about the gaps only after launch. That erodes the trust that is a credit union's main advantage.
{{04_H2_Heading_Section_01_Framing_Past_Struggles}}- Proposed H2: "Where Digital Experience Went Wrong Before: Features First, System Later." The section frames past struggles as a sequencing problem rather than a talent or budget problem. It uses Ben's own history, from front-end developer to UX leader, to explain why he trusts systems over screenshots. It stays general about the industry and specific only about work he led.
{{REFERENCE_TO_SPECIFIC_PAST_CHALLENGES}}- Member insights that sat inside one team and did not reach bankers; personalization ideas that had not been tested against a control group; tools built as features rather than answers to a member's actual question.
{{THE_IMPACT_OF_THESE_STRUGGLES_ON_THE_INDUSTRY}}- Credit unions risk shipping digital experiences that look modern but do not change member outcomes, and they learn about the gaps only after launch. That erodes the trust that is a credit union's main advantage.
{{05_Building_a_Sustainable_Future_Challenges_and_Opportunities}}- A sustainable digital experience is one a team can keep running after launch: documented, measured and owned across departments. Ben uses the Credit Score plus Lending Recommendation work, delivered end to end in six months including the soft credit pull, to show that speed comes from scope decisions made early. The opportunity is fewer rebuilds; the challenge is the discipline to decide what not to ship. The section avoids forecasts and keeps to what was delivered.
{{INCLUDE_SPECIFIC_HISTORICAL_EVENTS}}- Ben's path from front-end developer at CACU (2017) to Senior Product Architect (2021) to Manager, Product Experience and Innovation (2024) and Manager, User Experience (Dec 2025); the Member Insights Playbook launch (Nov 2024 soft, Jan 2025 full); the Q2 migration research ahead of Unify's launch (Aug 2026) and CACU's migration (Q4 2026, dates confirmed before past tense).
{{05_H2_Body_Text_Section_01_Historical_Problems_and_Market_Shifts}}- This body section traces how digital banking work shifted from building pages to building connected systems. Ben describes his own arc as the evidence: a front-end developer who built tools like the College Cost & Compare Calculator, then a product architect working on the Life Plans Personalization Engine and Salesforce workflows. The market shift he names is the move to shared platforms and data-driven personalization, which makes system design the first job. Dates tied to the platform migration are confirmed with CACU before they appear in past tense.
{{INCLUDE_SPECIFIC_HISTORICAL_EVENTS}}- Ben's path from front-end developer at CACU (2017) to Senior Product Architect (2021) to Manager, Product Experience and Innovation (2024) and Manager, User Experience (Dec 2025); the Member Insights Playbook launch (Nov 2024 soft, Jan 2025 full); the Q2 migration research ahead of Unify's launch (Aug 2026) and CACU's migration (Q4 2026, dates confirmed before past tense).
{{06_Navigating_the_Complexities_of_Global_Markets}}- The article stays local rather than global: a Kansas City credit union and the partners it works with. The complexity Ben navigates is organizational, with seven departments, a platform vendor and a partner credit union (Unify) each shaping the member experience. The section explains how research studies give those groups one shared set of findings to design against. It makes no claims about markets beyond his own work.
{{EXAMPLES_OF_EARLY_INNOVATION_ATTEMPTS}}- The Life Plans Personalization Engine built with the data team in 2021; the first Salesforce workflow for Financial Well-Being Coaches in 2022; UserTesting.com research introduced in 2021; the first Member Advisory Board in Q1 2023.
{{BARRIERS_ENCOUNTERED}}- Insights held by one team; workflows that did not match how staff actually served members; no control group to prove what worked. Each barrier was organizational before it was technical.
{{06_H3_Heading_Section_01_Early_Struggles_to_Innovate}}- Proposed H3: "Early Attempts: Personalization Before the System Was Ready." The section lists the early experiments Ben worked on and what each one taught about sequencing. It is candid about what did not work at first. It keeps credit with the CACU teams involved.
{{EXAMPLES_OF_EARLY_INNOVATION_ATTEMPTS}}- The Life Plans Personalization Engine built with the data team in 2021; the first Salesforce workflow for Financial Well-Being Coaches in 2022; UserTesting.com research introduced in 2021; the first Member Advisory Board in Q1 2023.
{{BARRIERS_ENCOUNTERED}}- Insights held by one team; workflows that did not match how staff actually served members; no control group to prove what worked. Each barrier was organizational before it was technical.
{{07_The_Importance_of_Diversity_and_Inclusion_in_the_Workplace}}- Here the theme becomes inclusion of perspectives: product decisions improve when branch staff, members and specialists are part of the research. Ben points to the first Member Advisory Board in Q1 2023 and to the Playbook's reach across 7 departments as ways CACU brought more voices into design. He also notes his own background, a crop farm in Corning, Kansas, as a reminder that users rarely look like the team building for them. No demographic statistics are cited.
{{SPECIFIC_EXAMPLES_OF_TRADITIONAL_SOLUTIONS}}- Adding features to a digital banking app on request; sending generic product emails to every member; keeping member insights in a report one team reads.
{{REASONS_THEY_WERE_INEFFECTIVE}}- They treated symptoms rather than the system: features without a shared model of the member, messages without a control group, insights without a path to the people serving members.
{{07_H3_Heading_Section_01_Why_Traditional_Solutions_Failed}}- Proposed H3: "Why Feature Requests and Generic Campaigns Fall Short." The section explains that traditional fixes addressed visible symptoms and left the underlying system unchanged. It contrasts them with the tested, system-level work of the Email Pilot and the Playbook. It stays descriptive and avoids naming other institutions.
{{SPECIFIC_EXAMPLES_OF_TRADITIONAL_SOLUTIONS}}- Adding features to a digital banking app on request; sending generic product emails to every member; keeping member insights in a report one team reads.
{{REASONS_THEY_WERE_INEFFECTIVE}}- They treated symptoms rather than the system: features without a shared model of the member, messages without a control group, insights without a path to the people serving members.
{{08_Harnessing_Data_for_Strategic_Decision_Making}}- Data use in Ben's practice comes with one rule: every number says what it is based on. He illustrates it with his private Card Market console, which labels each value with its basis and refuses to present an asking price as a sale. The same rule guided CACU's Email Pilot, which measured against a control rather than a before-and-after. The section makes the case that provenance, not volume, is what makes data useful for decisions.
{{INCLUDE_DATA_ON_MARKET_DEMAND}}- Use only sourced figures: 10,000+ families used the College Cost & Compare Calculator with a 3x increase in monthly planner meetings; the Email Pilot group was 2x more likely to qualify for Cashback Checking; 1,400+ eStatement enrollments. No external market-size figures are on record, so none are cited.
{{08_H3_Heading_Section_01_Market_Demand_Driving_New_Solutions}}- Proposed H3: "Demand Shows Up in Behavior, Not Surveys." The section uses the calculator and Email Pilot figures as evidence that members respond to tools that answer real questions. Each figure is labeled with its source and attributed to CACU. No industry demand statistics are introduced.
{{INCLUDE_DATA_ON_MARKET_DEMAND}}- Use only sourced figures: 10,000+ families used the College Cost & Compare Calculator with a 3x increase in monthly planner meetings; the Email Pilot group was 2x more likely to qualify for Cashback Checking; 1,400+ eStatement enrollments. No external market-size figures are on record, so none are cited.
{{09_The_Future_of_Work_Adapting_to_New_Realities}}- The future-of-work angle is about how UX and product teams will work alongside agents and automated data. Ben's example is his own Notion Worker, which builds card profiles daily and price history weekly, plus a researchCard tool for a Notion Custom Agent. He frames it as a small, private experiment in letting software do collection while the person keeps judgment. He is explicit that it is a side project and that no prices are on file yet.
{{FOCUS_ON_SPECIFIC_INNOVATIONS}}- The Member Insights Playbook in Salesforce; the Credit Score plus Lending Recommendation experience with a soft credit pull; the Card Market console's value-basis rule and weekly price history.
{{09_H2_Heading_Section_02_Showcasing_Current_Innovation_and_Impact}}- Proposed H2: "What Is Working Now: Insights People Actually Use." The section shows current innovations and their measured impact, drawing on CACU work and Ben's own console. Impact figures are limited to those on record. Unproven work is labeled as unproven.
{{FOCUS_ON_SPECIFIC_INNOVATIONS}}- The Member Insights Playbook in Salesforce; the Credit Score plus Lending Recommendation experience with a soft credit pull; the Card Market console's value-basis rule and weekly price history.
{{10_Engaging_Communities_Through_Corporate_Social_Responsibility}}- Community engagement in this article means financial education tools that serve families rather than sell to them. The College Cost & Compare Calculator and FAFSAchat are the examples, and the CollegeRoadmap suite was implemented at a dozen credit unions. Ben frames this as the credit-union model at its best: useful tools that earn trust. Awards connected to these tools are mentioned only after their wording is verified.
{{DETAILED_DESCRIPTIONS_OF_INNOVATIONS}}- The Member Insights Playbook surfaces personalized member insights (Goals, Credit Score, Money, Lending, Rewards) to bankers and branch staff; the Email Pilot sent personalized insights to a test group measured against a control; the College Cost & Compare Calculator helps families compare real college costs before meeting a planner.
{{MARKET_ANALYSIS_ON_THEIR_EFFECTIVENESS}}- Effectiveness is shown only by CACU's own measures: 75+ Playbook users across 7 departments, 2x Cashback Checking qualification versus control, 1,400+ eStatement enrollments, 10,000+ calculator families and 3x planner meetings. No third-party market analysis is on record.
{{10_H2_Body_Text_Section_02_Trends_Innovations_and_Value}}- This body section ties the innovations to the value they created for members and staff. The Playbook put insights in front of 75+ people who serve members; the Email Pilot doubled qualification against a control; the calculator reached 10,000+ families and tripled planner meetings. Ben's reading is that each worked because the system was designed first and measured honestly. Every figure comes from his LinkedIn profile and is credited to CACU and the teams involved.
{{DETAILED_DESCRIPTIONS_OF_INNOVATIONS}}- The Member Insights Playbook surfaces personalized member insights (Goals, Credit Score, Money, Lending, Rewards) to bankers and branch staff; the Email Pilot sent personalized insights to a test group measured against a control; the College Cost & Compare Calculator helps families compare real college costs before meeting a planner.
{{MARKET_ANALYSIS_ON_THEIR_EFFECTIVENESS}}- Effectiveness is shown only by CACU's own measures: 75+ Playbook users across 7 departments, 2x Cashback Checking qualification versus control, 1,400+ eStatement enrollments, 10,000+ calculator families and 3x planner meetings. No third-party market analysis is on record.
{{11_H3_Heading_Section_02_Emerging_Trends}}- Proposed H3: "Three Shifts Worth Watching." The section names trends Ben sees in his Miniflux reading on banking, fintech and credit-union trade press. It presents them as observations, not predictions. Each trend is linked to a source article when published.
{{INCLUDE_SPECIFIC_TRENDS}}- Shared digital banking platforms and credit-union migrations; personalization built on member data inside CRM tools such as Salesforce; agent-readable content and AI assistants reading institutional sites.
{{12_H3_Heading_Section_02_Technological_Disruption}}- Proposed H3: "Disruption Is Mostly Plumbing." The section argues that the disruptive technologies in credit-union UX are platforms, data pipelines and agents rather than flashy interfaces. It uses the Q2 migration and Ben's Notion Worker as grounded examples. It avoids naming vendors beyond those in the record.
{{EXAMPLES_OF_TECHNOLOGIES_CAUSING_DISRUPTION}}- Digital banking platform migrations (Q2); CRM-based insight delivery (Salesforce); scheduled data workers and custom agents (Notion Workers, researchCard); agent-readable site versions such as bennieiv.xyz's Built for Agents.
{{CASE_STUDIES_OR_SUCCESS_STORIES}}- CACU's 2023 Email Pilot (2x Cashback Checking qualification versus control; 1,400+ eStatement enrollments); the Member Insights Playbook (75+ people, 7 departments). Both come from his LinkedIn profile and are credited to CACU and the teams involved.
{{13_H3_Heading_Section_02_Urgency_of_Adoption}}- Proposed H3: "The Cost of Waiting Until Launch Day." The section makes a measured case for doing system research early rather than adopting any particular product. The urgency is about sequence, not about buying technology. It uses study four of the migration research as the illustration.
{{RISKS_OF_NOT_ADOPTING_NEW_SOLUTIONS}}- Discovering integration and workflow gaps at launch, when fixes cost most; members meeting a new platform that does not match how they bank; staff left without the insights they need to help.
{{BENEFITS_OF_EARLY_ADOPTION}}- Problems surface in research studies rather than in production; teams share one picture of the member; scope decisions made early make fast delivery possible, as the six-month Credit Score and Lending Recommendation work showed.
{{14_H2_Heading_Section_03_Opportunities_and_Challenges}}- Proposed H2: "The Opportunity and the Hard Part." The section pairs each opportunity with the discipline it demands. It keeps the tone candid and avoids promising outcomes. It prepares the reader for practical action steps.
{{SPECIFIC_OPPORTUNITIES_AVAILABLE}}- Using a platform migration as the moment to redesign the system, not just re-skin screens; putting member insights in front of every staff member who serves members; testing personalization against a control before scaling it.
{{CHALLENGES_THAT_MAY_ARISE}}- Cross-department alignment across many teams; employer and vendor constraints on what can be shared; data licensing and provenance limits, as in Ben's card console where vendor values are licensed for internal use only.
{{15_H2_Body_Text_Section_03_Opportunities_Obstacles_and_Solutions}}- This body section lays out opportunities, obstacles and practical responses in plain terms. The opportunity is to treat change moments like a platform migration as a chance to redesign the system members live inside. The obstacles are alignment, employer boundaries and data limits, and Ben answers each with a habit: research first, attribute honestly, and decide what not to publish. It closes by noting that the cheapest product decision he ever made was deciding not to publish something.
{{CLEAR_ARTICULATION_OF_OPPORTUNITIES}}- A platform change is the rare moment when an institution can redesign the whole member system at once; research done before launch turns that moment into lasting simplicity.
{{DISCUSSION_OF_OBSTACLES}}- Many departments, a platform vendor and partner institutions all shape the experience; results are shared from his LinkedIn profile and unreleased CACU work stays with the employer; data sources carry licensing terms.
{{PROPOSED_SOLUTIONS}}- Run staged research studies before launch; publish one shared playbook across departments; measure against a control group; label every number with its basis and keep licensed data private.
{{16_H3_Heading_Section_03_Competitive_Advantage_Through_Early_Adoption}}- Proposed H3: "Early Research Is the Advantage." The section argues that the advantage goes to teams that study the system early, not to those who adopt tools first. It cites CACU's experience with the Playbook and Email Pilot. It makes no claims about competitor institutions.
{{SUCCESS_STORIES_OF_EARLY_ADOPTERS}}- CACU's Member Insights Playbook, adopted by 75+ people across 7 departments; the CollegeRoadmap suite, implemented at a dozen credit unions. No other institutions' results are cited.
{{BENEFITS_OF_EARLY_ADOPTION_OVER_LATE_ADOPTION}}- Early adopters of research-first practice shape the system before it hardens; late adopters inherit decisions they then have to work around.
{{17_H3_Heading_Section_03_Overcoming_Cost_Barriers}}- Proposed H3: "Keeping It Small Enough to Afford." The section shows that system thinking does not require a large budget: a pilot with a control group, a shared playbook, a private tool on free data sources. Ben's Card Market runs on free ESPN data today and waits on paid PriceCharting and eBay approvals before pricing anything. No budget figures are claimed.
{{COMMON_COST_BARRIERS}}- Paid data subscriptions and API approvals; staff time across departments; vendor platform fees; the cost of rework discovered at launch.
{{STRATEGIES_FOR_FINANCING_OR_BUDGETING}}- Start with a pilot sized to prove one outcome against a control; use free or sanctioned data sources first; spend on paid data only when the question requires it; count avoided rework as part of the case.
{{18_H3_Heading_Section_03_Preparing_Teams_for_Innovation}}- Proposed H3: "Preparing the People Who Will Live Inside It." The section covers how teams get ready: shared research, training on new insight tools and early leadership development. Ben references CACU's inaugural Leadership Fundamentals cohort (2024) and his first two direct reports. It keeps the focus on habits rather than programs.
{{INCLUDE_SPECIFIC_TRAINING_PROGRAMS}}- CACU's inaugural Leadership Fundamentals cohort (2024); Playbook rollout to 75+ staff; Ben's own General Assembly User Experience Design Program (2018) and Web Development Graduate Certificate from Johnson County Community College.
{{19_H2_Heading_Section_04_Conclusion_and_Action_Steps}}- Proposed H2: "Start With the System." The conclusion restates the thesis in one line and gives three action steps. It avoids a sales close. It ends on Ben's standing invitation to peers.
{{HIGHLIGHT_KEY_TAKEAWAYS}}- Design the system before the screens; run research before launch, not after; measure against a control; make every number say what it is based on; decide what not to publish.
{{20_H2_Body_Text_Section_04_Summary_Call_to_Action_and_Final_Thoughts}}- The final section summarizes the argument: a digital experience is a system someone has to live inside, and the work is shaping it to be simple, useful and worth trusting. Ben lists the takeaways as actions a product or UX leader can start this quarter. He closes with his usual low-pressure invitation rather than a pitch: "If you're building something worth inhabiting, or just curious, reach out." The article links to bennieiv.xyz and his LinkedIn profile.
{{INCLUDE_A_SUMMARY_OF_INSIGHTS}}- Launch-day surprises are research failures; shared insights beat siloed ones; controlled tests beat anecdotes; provenance makes data trustworthy; restraint is a product decision.
{{01_Brief_Intake_Questions}}- The brief covers LI-06, "A calculator that changed the conversation," a LinkedIn post scheduled for Thursday, October 15, 2026, with the College Cost & Compare Calculator as its subject. The intake confirms why the post exists, where it runs and who signs it off before drafting starts. Ben Niehues IV is both requester and subject expert, and he approves all drafts in the Monday session before the slot. Open intake questions are listed as Proposed so the brief can be locked by Friday, October 9.
{{CONTENT_PURPOSE}}- Show, through one credited CommunityAmerica Credit Union project, that a tool built around a family's real question changes the conversation an institution has with the people it serves. The post supports the research-led digital banking pillar and the LI-01 to LI-12 series.
{{PUBLICATION_CHANNEL}}- LinkedIn personal profile (linkedin.com/in/bennieiv), Thursday, October 15, 2026, about 8:00 a.m. Central; a Studio case page on bennieiv.xyz is the proposed anchor for the link.
{{REQUESTER_AND_APPROVERS}}- Requester and sole approver: Ben Niehues IV, reviewing on the Monday before publication (October 12). No other approvers are on record; the drafting pipeline in his console prepares the draft.
{{DEADLINE}}- Brief locked Friday, October 9; draft ready Friday, October 9 or earlier; Ben's approval Monday, October 12; scheduled for Thursday, October 15, 2026.
{{SUBJECT_EXPERT}}- Ben Niehues IV, who worked on the College Cost & Compare Calculator with the CommunityAmerica Credit Union team and lists it on his public LinkedIn profile.
{{02_Audience_Reader_Profile}}- The reader is a product, UX or digital-experience leader at a credit union or community financial institution who is deciding what to build next and how to justify it. They know member tools and planning conversations well but have rarely seen a tool's results stated with plain numbers and credited to a team. They arrive with a practical question: does a simple tool change member behavior, or does it only add a page to the website? The post meets that question with a specific, sourced account.
{{READER_ROLE}}- Product, UX and digital-experience managers and directors at credit unions and community financial institutions; cross-functional peers in financial education, marketing and member service; Kansas City product and tech community as a secondary group.
{{READER_KNOWLEDGE_LEVEL}}- Expert in the credit-union context, intermediate on product architecture as a named practice, and unfamiliar with this specific calculator unless they are CACU members or staff.
{{TRIGGERING_PROBLEM}}- They own a planning, lending or education tool that gets traffic but does not start conversations, or they are being asked to show what a digital tool did for members beyond page views.
{{JOURNEY_STAGE}}- Awareness and consideration of Ben's way of working, as a peer voice; not a buying stage, since nothing is sold.
{{LIKELY_OBJECTION}}- "That is one credit union's result, and it will not transfer to us." The post answers by naming the basis of each number, crediting the team, and describing the approach rather than promising a repeat.
{{03_Objective_And_Success_Measure}}- The objective is to make peers see the calculator as a worked example of product architecture: start with the question families already ask, then build the tool around it. The desired action is a comment, a reshare or a message from a peer who builds something similar. Success is judged on conversations started and comment quality, with impressions as context only. Baselines are not on record, so LI-01 and LI-02 set them and this brief uses Targets.
{{PRIMARY_OBJECTIVE}}- Establish one sourced credit-union case as evidence for the owned topic, product architecture for credit-union digital experience.
{{DESIRED_ACTION}}- Readers comment with their own planning-tool experience, reshare the post, or message Ben through LinkedIn or bennieiv.xyz/contact.
{{PRIMARY_METRIC}}- Comments and messages from product, UX or credit-union peers that reference the post; impressions are tracked as a secondary figure from LinkedIn analytics.
{{BASELINE_AND_TARGET}}- Baseline: not on record; set from LI-01 and LI-02 results. Target: at least 3 substantive peer comments and 1 conversation started within 7 days of publication.
{{MEASUREMENT_WINDOW}}- Seven days after publication (October 15 to 22, 2026), read in the Friday signals review on October 16 and again in the series read-out after LI-12 on November 5.
{{04_Core_Message_And_Angle}}- The core message is that the College Cost & Compare Calculator did not sell anything; it answered a question families were already asking, and that is why monthly planner meetings tripled. The angle is system before screen: the question families live inside came first, the interface second. The post states its numbers as they appear on Ben's public profile, credits CommunityAmerica Credit Union and the team, and claims no more than the profile does. The coverage gap is an honest practitioner account inside a credit union, where most writing on college planning tools is vendor marketing.
{{CORE_MESSAGE}}- A tool built around the question a family is already asking changes the conversation: more than 10,000 families used the College Cost & Compare Calculator at CommunityAmerica Credit Union, and monthly planner meetings tripled.
{{DIFFERENTIATING_ANGLE}}- Product architecture applied to a member education tool: describe the system the family lives inside before drawing any screen, told by a practitioner who worked on it with the team.
{{SUPPORTING_POINTS}}- The calculator answers "what will this school actually cost us?"; 10,000+ families used it; monthly planner meetings tripled (3x); the work was a team effort credited to CommunityAmerica Credit Union.
{{EXISTING_COVERAGE_GAP}}- College-cost calculators are usually covered as vendor features or financial-aid advice. Practitioner accounts of why one worked, written by someone on the team at a credit union, are scarce; none is on file from the feeds Ben monitors.
{{05_Search_Intent_And_Keyword_Plan}}- LinkedIn posts are found through the feed and profile rather than search, so the keyword plan is light and serves the Studio case page that the post links to. The primary phrase is credit union college cost calculator, with a product architecture angle. The search intent is informational and professional, from peers looking for how a credit union built a planning tool. No search-volume data is on file, so keyword priority is Proposed and verified once analytics exist on bennieiv.xyz.
{{PRIMARY_KEYWORD}}- Proposed: credit union college cost calculator.
{{SECONDARY_KEYWORDS}}- Proposed: college cost compare; financial planner meetings; credit union product design; member education tool; product architecture credit union.
{{QUESTIONS_TO_ANSWER}}- What problem did the calculator solve for families? What changed in planner meetings? How many families used it? What does product architecture mean for a tool like this?
{{SEARCH_INTENT}}- Informational and professional: peers learning how a credit-union team built and justified a planning tool. Not transactional.
{{KEYWORD_PLACEMENT}}- Studio case page: primary phrase in the title and first paragraph, secondary phrases in subheadings. LinkedIn post: natural wording only, no keyword stuffing, one phrase in the first two lines.
{{06_Content_Outline}}- The outline has one hook, one turn, one result and one lesson, matching the LinkedIn one-idea-per-post rule of under 1,300 characters. It opens on the family's question, not on an award or a feature list. The middle states the two sourced results and credits the team. It closes with the architecture lesson and Ben's standard invitation to peers.
{{WORKING_TITLE}}- A calculator that changed the conversation
{{HEADLINE_OPTIONS}}- A calculator that changed the conversation; The tool didn't sell anything; What will this school actually cost us?
{{SECTION_HEADINGS}}- 1. The question families were asking; 2. What we built at CommunityAmerica; 3. What changed: 10,000+ families, 3x planner meetings; 4. The system came first; 5. Invitation to peers.
{{SECTION_PURPOSES}}- 1. Open on the family's question to earn attention; 2. Name the project and credit the team; 3. State the two results with their basis; 4. Connect to product architecture; 5. Close with the open invitation, no hard call to action.
{{WORD_COUNT_TARGETS}}- LinkedIn post: 150 to 220 words, under 1,300 characters; Studio case page: 500 to 700 words; five sections at 30 to 60 words each in the post.
{{07_Tone_And_Style_Direction}}- The tone is Ben's own: first person, plain, candid, with short declarative sentences and no hype. Team results use "we" and name CommunityAmerica Credit Union; opinions use "I." There are no exclamation marks, emoji or award language. The reading level is about grade 8 to 9 so a busy peer can absorb it in under a minute.
{{TONE_DESCRIPTORS}}- Architectural; candid; restrained; generous.
{{READING_LEVEL}}- About grade 8 to 9; sentences of 6 to 16 words, one longer sentence allowed per paragraph.
{{POINT_OF_VIEW}}- First person singular for his own view; first person plural only for CommunityAmerica team work, with the credit union named.
{{PREFERRED_TERMS}}- System; member (not customer or user); planner meetings; basis; families; we built at CommunityAmerica.
{{FORMATTING_RULES}}- One to three sentences per paragraph with a blank line between; no bold runs, all-caps, emoji or exclamation marks; no more than one link; fragments used once for a beat.
{{08_Sources_And_Evidence_Plan}}- Every claim traces to a source Ben can name. The two results are taken from his public LinkedIn profile, where the project is credited to CommunityAmerica Credit Union and the team, and they are quoted exactly. Anything beyond the profile, such as method details or interview quotes, is requested from Ben and marked Proposed until he provides it. No outside statistics are used, and no claim about the wider market is made.
{{REQUIRED_SOURCES}}- Ben's public LinkedIn profile entry for the College Cost & Compare Calculator at CommunityAmerica Credit Union (10,000+ families; 3x planner meetings); the project's public description if a CACU page exists.
{{EXPERT_QUOTES}}- Ben Niehues IV: one short line on what families asked, to be recorded in the Monday session. Proposed, not yet on file.
{{INTERNAL_DATA}}- None beyond the two figures on his profile; the post states them as listed and does not add new internal metrics.
{{VERIFICATION_NEEDED}}- Confirm the exact wording of "3x planner meetings" (monthly) and "10,000+ families" against the profile before scheduling; confirm any award wording before it is used, otherwise leave awards out.
{{ASSET_REQUESTS}}- One calm screenshot or neutral image of the calculator if publicly shown; otherwise a text-only post. Ben supplies photo or image rights; no card or stock imagery.
{{09_Call_To_Action_Design}}- The call to action is an invitation, not a pitch, because nothing is sold. The primary line is Ben's standard close, which keeps the series voice consistent. The secondary action links to the Studio case page for readers who want the full account. Both sit at the end of the post so the story is not interrupted, and both promise only what the page delivers.
{{PRIMARY_CTA_TEXT}}- If you're building something worth inhabiting, or just curious, reach out.
{{SECONDARY_CTA_TEXT}}- Read the full case on bennieiv.xyz.
{{CTA_PLACEMENT}}- Last two lines of the LinkedIn post; link in the first comment if the post reach drops with an in-body link, to be tested across LI-05 to LI-07.
{{CTA_DESTINATION}}- bennieiv.xyz/studio case page for the College Cost & Compare Calculator (Proposed); bennieiv.xyz/contact for conversations.
{{PROMISE_CONTINUITY}}- The post promises the story of one tool and its two results; the case page delivers exactly that, with no sign-up wall and no sales language.
{{10_Brief_Quality_Checklist}}- Before drafting, the brief is checked for a named reader, one objective, a measurable target, sources for every claim and a CTA that matches the page. Two items are open: the verified wording of the two results and the case page URL. Both are assigned, so the brief can move forward once they are closed. Ben signs the brief off and later the draft.
{{BRIEF_CHECKS}}- Named reader; one objective; target set; every number sourced; voice rules attached; CTA matches destination; publication date and approver set.
{{FAILED_ITEMS}}- Case page URL not yet confirmed; wording of the two results not yet checked against the profile line by line.
{{REQUIRED_FIXES}}- Confirm the Studio page slug by October 9; compare the post's figures with the profile text and record the check in the approval queue.
{{SIGN_OFF_OWNER}}- Ben Niehues IV.
{{11_Distribution_And_Repurposing_Notes}}- The post publishes on LinkedIn on Thursday, October 15 at about 8:00 a.m. Central and is linked to the Studio case page. After 7 days, the strongest line is reused as an excerpt, and the signals review on October 16 decides whether it earns a longer Notebook companion. Performance is reviewed in the series read-out after LI-12 on November 5.
{{PUBLISH_STEPS}}- 1. Ben approves on Monday, October 12; 2. schedule for Thursday at 8:00 a.m. Central; 3. publish the Studio case page first; 4. post on LinkedIn with the link; 5. answer comments the same day.
{{INTERNAL_LINKS}}- Studio case page for the College Cost & Compare Calculator; Notebook essay "Before a Wireframe, a System"; bennieiv.xyz/contact.
{{PROMOTION_CHANNELS}}- LinkedIn personal profile only; Instagram and X stay outside the six-week program.
{{EXCERPT_CANDIDATES}}- "The tool didn't sell anything. It answered a question families were already asking."; "More than 10,000 families used it, and monthly planner meetings tripled."
{{PERFORMANCE_REVIEW_DATE}}- Friday, October 16 (first read) and Thursday, November 5, 2026 (series read-out).
{{01_Content_Discovery_Questions}}- Ben Niehues IV is a personal brand, so discovery starts from a practice rather than a product: product architecture for digital experience in credit unions. The audience is product, UX and digital-experience peers, and the asset base is twelve LinkedIn posts (LI-01 to LI-12), a site with Notebook, Studio and Field Notes, and a private card console. The goal is authority and peer conversations, not sales. Capacity is about two hours a week around a full-time role at CommunityAmerica Credit Union.
{{BUSINESS_OFFER}}- Nothing is sold. The offer to readers is systems-first product thinking: "Before a wireframe or a feature, there's a system someone has to live inside."
{{AUDIENCE_QUESTIONS}}- How do you research a platform migration before launch? How do you get staff in several departments to use member insights? How do you report a number honestly? What does a product architect do?
{{EXISTING_CONTENT}}- Twelve drafted LinkedIn posts (LI-01 to LI-12); bennieiv.xyz Notebook, Studio, Field Notes and Margins; a Notebook essay planned as the companion to LI-01; Instagram @bennieiv (2,431 followers on 2026-09-25); Card Market console copy.
{{CONTENT_GOALS}}- Target: 12 of 12 posts published Sep 29 to Nov 5, 2026, and at least one peer conversation started per two posts. Follower and reach baselines are set at week 0.
{{PUBLISHING_CAPACITY}}- Proposed: about 2 hours a week, with Monday approval and a Friday signals review; two LinkedIn posts a week, one longer piece every two to four weeks.
{{02_Audience_Question_Mining}}- Questions come from three places: the Miniflux signals Ben already collects, the comments on his own LinkedIn posts once LI-01 is live, and the recurring questions from his career. They are kept in the audience's own words so titles match how peers speak. The recurring objection is that one credit union's results do not transfer. Because the series has not started, comments are a Proposed source, not an existing one.
{{CUSTOMER_QUESTIONS}}- "How do we get staff to actually use member insights?"; "What should we test before a platform conversion?"; "Is this number real?"; "What does a product architect do?"
{{QUESTION_SOURCES}}- Miniflux categories (Banking and fintech 12 articles, Credit union trade press 10, Startland News 5, Local business news 0 at setup); nngroup.com and uxdesign.cc feeds; LinkedIn comments on LI-01 to LI-12 once published.
{{AUDIENCE_LANGUAGE}}- Member, not customer; platform conversion or migration; insights; planner meetings; "what is this based on."
{{RECURRING_OBJECTIONS}}- "That was your credit union, not mine"; "Research slows the launch"; "A side project is not evidence."
{{BUYING_STAGE_QUESTIONS}}- No buying stage exists. Stages are awareness ("What is product architecture?"), consideration ("Does his approach fit our migration?") and conversation ("Can we talk?").
{{03_Search_Demand_Review}}- Search demand for Ben's subjects is not measured. No keyword volume or analytics are on file, and the feeds show steady coverage of credit-union platform change, not query counts. The review therefore lists candidate subjects with inferred intent and marks demand as Proposed. The working assumption is that professional intent on LinkedIn matters more than search volume for this program. Keyword data for bennieiv.xyz is Proposed for after analytics are set up.
{{CANDIDATE_SUBJECTS}}- Product architecture; credit union digital banking migration research; member insights playbook; college cost calculator; email pilot with a control group; data provenance.
{{SEARCH_INTENT}}- Mostly informational and professional (how to research a migration, what product architecture means); none transactional.
{{DEMAND_LEVEL}}- Not measured. Inferred from 27 collected Miniflux articles in four categories; Proposed: pull keyword volumes with Keywords Everywhere before choosing essay topics.
{{COMPETING_PAGES}}- Nielsen Norman Group and UX Collective for general UX; America's Credit Unions and credit union trade press for industry; vendor blogs on college planning tools. Card-data services (Card Ladder, Market Movers, 130 Point, Alt) for the side project only.
{{SEASONAL_PATTERNS}}- Not measured. Proposed: college-planning subjects are timely in autumn and winter, so LI-06 in mid-October fits; migration subjects follow the CACU calendar (migration planned for Q4 2026).
{{04_Competitor_Content_Gap_Scan}}- The scan compares Ben's territory with established voices in UX and credit-union media. General UX is crowded, while a practitioner's account from inside a live credit-union digital banking migration is thinly covered. Formats that competitors favor are frameworks and listicles, which leaves room for dated, sourced case accounts. No commercial competitor is tracked because Ben sells nothing, so the scan covers alternative voices only.
{{COMPETITOR_TOPICS}}- UX research methods and heuristics (NN/g, UX Collective); credit union industry news and advocacy (America's Credit Unions); fintech product trends; vendor content on digital banking platforms.
{{COMPETITOR_FORMATS}}- Long-form articles, frameworks and checklists, industry news summaries, webinars and vendor white papers.
{{WEAK_COVERAGE_AREAS}}- First-person accounts of credit-union migration research; results credited with their basis; product architecture named as a discipline in financial services.
{{UNCOVERED_TOPICS}}- What study four of a migration teaches that launch day does not; turning a Salesforce-based insights tool into a cross-department habit; a control-group email pilot explained plainly; provenance rules for any number.
{{EXPERTISE_ADVANTAGES}}- Fourteen years from front-end developer to UX manager; three public results credited to CommunityAmerica Credit Union and the team (Member Insights Playbook, 2023 Email Pilot, College Cost & Compare Calculator); a live migration to write about; a card console as a provenance example.
{{05_Topic_Pillar_Framework}}- Four pillars organize every topic: product architecture, research-led digital banking, evidence and provenance, and craft and restraint. Each connects to an offer only in the sense of a reader conversation, since nothing is sold. The pillar map matches the four owned topics used in the post series, so each of the twelve posts has a home. Audience needs are stated per pillar to keep ideas from drifting into general UX advice.
{{CONTENT_PILLARS}}- Product architecture; Research-led digital banking; Evidence and provenance; Craft and restraint.
{{PILLAR_PURPOSES}}- Product architecture: define the discipline. Research-led digital banking: show practice with credited CACU work. Evidence and provenance: prove the standard for numbers. Craft and restraint: show taste in the decisions behind the work.
{{LINKED_OFFERS}}- No paid offer. Each pillar links to an anchor asset on bennieiv.xyz: Notebook essay, Studio case pages, Card Market Studio page (private research, no card values) and a Field Note.
{{SUBTOPIC_AREAS}}- Product architecture: systems before screens. Digital banking: migration research, member insights, email pilots, planning tools. Provenance: basis, history versus single point, asking price versus sale. Craft: one accent, square furniture, deciding not to publish.
{{PILLAR_AUDIENCE_NEEDS}}- Product and UX leaders need a practical way to sequence work; credit-union peers need honest examples; data-minded readers need a standard for trusting numbers; designers need permission to leave things out.
{{06_Topic_Idea_Generation}}- The idea pool is built from the twelve scheduled posts and from weekly Miniflux signals, so each idea has a source. The first ideas extend LI-01 to LI-12, for example the research behind the digital banking migration and the two results that came from team work at CommunityAmerica Credit Union. Customer stories are replaced by team case stories, since Ben has no clients. Card Market supplies provenance ideas without any card values.
{{WORKING_TITLES}}- Product architecture before pixels; Four studies before a migration; A playbook that lives in one head is a bottleneck; Two times more likely to qualify, and what it was based on; A calculator that changed the conversation; Fifteen cards, none priced yet; Why the card console stays private; The furniture is square.
{{QUESTIONS_ANSWERED}}- What is product architecture? When do you learn what a migration costs? How do you roll out insights across departments? What does a number say it is based on? Why publish an unfinished tool's status?
{{IDEA_SOURCES}}- Miniflux signals (Friday review); the twelve drafted posts; Ben's public LinkedIn profile results; Card Market console status; comments on published posts.
{{TOPIC_ANGLES}}- System before screen; evidence with a named basis; a credited team result in plain numbers; an unfinished tool described candidly; restraint as a design decision.
{{CUSTOMER_STORY_TOPICS}}- Team stories, credited to CommunityAmerica Credit Union: Member Insights Playbook used by 75+ people across 7 departments; 2023 Email Pilot, 2x Cashback Checking qualification versus control; College Cost & Compare Calculator, 10,000+ families and 3x planner meetings. Card Market is a private project, not a customer story.
{{07_Topic_Scoring_Model}}- Each candidate is scored on fit with the four pillars, audience demand, evidence Ben can cite, and effort, on a 1 to 5 scale. Fit and evidence carry the most weight because the program lives or dies on credibility. Demand scores are Proposed until keyword and comment data exist, and effort scores use his stated time per format. Topics below the threshold go to the parking list and are reviewed monthly.
{{SCORING_CRITERIA}}- Pillar fit; evidence on record; audience demand; effort; timeliness against a signal.
{{CRITERIA_WEIGHTS}}- Proposed: pillar fit 30 percent; evidence 30 percent; demand 20 percent; effort 10 percent; timeliness 10 percent.
{{DEMAND_SCORES}}- Proposed, 1 to 5: research-led digital banking 4; product architecture 3; evidence and provenance 3; craft and restraint 2. To be replaced with comment and analytics data after LI-06.
{{EFFORT_SCORES}}- Proposed, 1 (low effort) to 5: LinkedIn post 1; Field Note 2; Notebook essay 4; Studio case page 5.
{{SELECTION_THRESHOLD}}- Proposed: a weighted score of 3.5 or higher, with evidence of at least 4 for any topic that cites CACU work.
{{08_Topic_Brief_Template}}- The topic brief template captures the five things a writer needs before drafting a post: audience, core question, angle, evidence and the next step for the reader. It is filled for each selected topic and feeds the content brief. Ben approves the filled template in the Monday session. The example answers below are from LI-06.
{{TOPIC_AUDIENCE}}- Product, UX and digital-experience leaders at credit unions and community financial institutions.
{{CORE_QUESTION}}- What happens when a tool is built around the question a family is already asking?
{{TOPIC_ANGLE}}- System before screen: the question came first, the calculator second.
{{REQUIRED_EVIDENCE}}- 10,000+ families used the College Cost & Compare Calculator and monthly planner meetings tripled, both from Ben's public LinkedIn profile and credited to CommunityAmerica Credit Union and the team.
{{READER_NEXT_STEP}}- Comment with a planning tool you have built, or read the case page on bennieiv.xyz.
{{09_Angle_and_Hook_Development}}- Priority topics are chosen from the scored list and given a primary angle, two alternatives and an opening hook in Ben's voice. Hooks open on a position or a fact, never a question or hype. Proof points are limited to results already public on his profile and to the side-project status he can verify. The differentiating viewpoint is the same across topics: the system comes first, and every number names its basis.
{{PRIORITY_TOPICS}}- Four studies before a migration (LI-02); the Member Insights Playbook (LI-03); the 2023 Email Pilot (LI-04 or LI-05); the calculator (LI-06); fifteen cards, none priced (LI-10).
{{ALTERNATIVE_ANGLES}}- Migration: research as insurance versus research as design. Playbook: a bottleneck versus a habit. Email Pilot: what a control group tells you. Card Market: provenance versus price.
{{OPENING_HOOKS}}- "You don't find out what a migration costs on launch day. You find out in study four."; "An insights program that lives in one team's head isn't a program. It's a bottleneck."; "The tool didn't sell anything."; "Fifteen cards. None priced yet."
{{PROOF_POINTS}}- Member Insights Playbook used by 75+ people across 7 departments; Email Pilot with 2x Cashback Checking qualification versus a control group; 10,000+ families and 3x planner meetings; Card Market: 15 graded rookie cards, value basis none, no prices.
{{DIFFERENTIATING_VIEWPOINT}}- Product architecture is shaping the system people live inside before drawing screens, and a result is only as good as the basis it names.
{{10_Format_and_Channel_Mapping}}- Formats follow effort and evidence. Short LinkedIn text posts carry each topic, Notebook essays extend the strongest posts, and Studio case pages hold the credited CACU results. Card Market topics stay on LinkedIn and one Studio page, never as a product page. LinkedIn is priority one, bennieiv.xyz is the home for longer pieces, and Instagram and X stay outside the six-week plan.
{{TOPIC_FORMATS}}- LinkedIn text posts (LI-01 to LI-12); Notebook essay for product architecture; Studio case pages for the Playbook and the calculator; Studio page for Card Market; Field Note for craft.
{{PUBLISHING_CHANNELS}}- LinkedIn personal profile; bennieiv.xyz Notebook, Studio and Field Notes.
{{REPURPOSING_PLAN}}- Post first, then a Notebook essay or Studio page a week later, then a Field Note excerpt; pull one line per post for reuse; no video or audio planned.
{{FORMAT_RATIONALE}}- Posts fit peers reading on weekdays and fit his two hours a week; essays and case pages give depth and a stable link; text avoids extra production work.
{{CHANNEL_PRIORITY}}- 1. LinkedIn; 2. bennieiv.xyz; 3. Instagram @bennieiv (held); 4. X (held).
{{11_Topic_Pipeline_Schedule}}- The pipeline runs on the series calendar: two posts every week, Tuesday and Thursday, from LI-01 on Tuesday, September 29 to LI-12 on Thursday, November 5, 2026. Ben owns every topic. Drafts are ready the week before, approved on Monday and scheduled straight after. The Friday signals review adds new ideas to the queue for the next cycle.
{{TOPIC_SEQUENCE}}- LI-01 product architecture; LI-02 to LI-06 research-led digital banking (migration studies, Playbook, Email Pilot, calculator); LI-07 career; LI-08 to LI-11 evidence and provenance (Card Market); LI-12 craft and restraint.
{{TOPIC_OWNERS}}- Ben Niehues IV for all topics; the console drafting pipeline prepares first drafts.
{{DRAFT_DEADLINES}}- Proposed: each draft ready the Friday before its week; Monday approval; buffer of 2 approved posts.
{{REVIEW_STEPS}}- Draft from source; check each number against its source line; voice check against the guide; Ben approves on Monday; schedule.
{{PUBLICATION_DATES}}- LI-01 Sep 29; LI-02 Oct 1; LI-03 Oct 6; LI-04 Oct 8; LI-05 Oct 13; LI-06 Oct 15; LI-07 Oct 20; LI-08 Oct 22; LI-09 Oct 27; LI-10 Oct 29; LI-11 Nov 3; LI-12 Nov 5, 2026.
{{12_Topic_Performance_Review}}- Topic performance is reviewed with the source and date on every number. No results exist yet because the series begins on September 29, so every field below is Pending or Target. Comparison of scores with actual results starts after LI-06 and is used to re-weight the scoring model. The next round of topics is chosen at the read-out after LI-12 on November 5.
{{TOPIC_TRAFFIC}}- Pending; impressions per post from LinkedIn analytics and sessions to bennieiv.xyz once analytics are set up. Baseline not on record.
{{TOPIC_ENGAGEMENT}}- Pending; comments and reshares per post. Target: at least 3 substantive peer comments per case post.
{{TOPIC_LEADS}}- No leads, since nothing is sold. Conversations started through LinkedIn messages or bennieiv.xyz/contact are the nearest measure; Target: one per two posts.
{{SCORE_VERSUS_RESULT}}- Pending; compare each topic's predicted score with comments and conversations after LI-06 and after LI-12, and re-weight demand if they diverge.
{{NEXT_ROUND_TOPICS}}- Proposed: follow-ups on the highest-engagement pillar; the Unify and CACU migration outcomes once they are reported; Notebook essays from the two strongest posts.
{{01_Current_Output_Baseline}}- Before this program, no regular publishing cadence is on record for Ben's LinkedIn profile. His site bennieiv.xyz carries dated Notebook essays, Studio case pages, Field Notes and Margins, but posting frequency and engagement figures are not captured. The program starts from zero scheduled posts and twelve drafted posts (LI-01 to LI-12). Baselines for engagement and followers are to be captured at week 0.
{{WEEKLY_OUTPUT_BY_CHANNEL}}- LinkedIn: no regular cadence on record; bennieiv.xyz: occasional dated essays, frequency not measured; Instagram @bennieiv: frequency not measured.
{{CONSISTENCY_SCORE}}- Not measurable yet; baseline set at 0 of 0 scheduled slots before Sep 29, 2026.
{{ENGAGEMENT_PER_PIECE}}- Not on record; to be captured from LinkedIn analytics for LI-01 onward.
{{SILENT_PERIODS}}- Not on record; history of LinkedIn posting to be reviewed at week 0.
{{VOLUME_EFFECT}}- Unknown until the program has run; the first six weeks establish the baseline.
{{02_Audience_Consumption_Patterns}}- Ben's readers are working professionals who read LinkedIn during the work week. The plan assumes weekday mornings are the best window, which is a proposed assumption to test, not a measured fact. Readers prefer short text posts with one idea and a link to a longer essay. Fatigue is watched through falling engagement on consecutive posts.
{{ACTIVE_DAYS}}- Proposed: Tuesday and Thursday, mid-week workdays.
{{ACTIVE_HOURS}}- Proposed: 7:30 to 9:00 a.m. Central, before the working day fills up; to be confirmed with LinkedIn analytics.
{{PREFERRED_FORMATS}}- Short LinkedIn text posts (one idea, under 1,300 characters) linking to Notebook essays and Studio case pages.
{{FREQUENCY_TOLERANCE}}- Proposed: two posts a week is sustainable for a professional audience without crowding feeds.
{{FATIGUE_SIGNALS}}- Falling reactions and comments across three consecutive posts; unfollows after posts; comments that repeat the same objection.
{{03_Cadence_Objectives}}- The cadence goal is consistency rather than volume: two LinkedIn posts every week for six weeks, all twelve on schedule. LinkedIn is the primary channel and bennieiv.xyz is the home for longer pieces. Consistency means no missed Tuesday or Thursday slot without a buffer post filling it. The cadence must fit around Ben's full-time role at CACU.
{{CADENCE_GOAL}}- Target: 12 of 12 LinkedIn posts (LI-01 to LI-12) published on schedule between Sep 29 and Nov 5, 2026.
{{PRIMARY_CHANNELS}}- LinkedIn personal profile (linkedin.com/in/bennieiv); bennieiv.xyz Notebook and Studio.
{{CONSISTENCY_DEFINITION}}- Every Tuesday and Thursday slot filled, with approved drafts ready by Monday.
{{04_Production_Capacity_Assessment}}- Ben writes around a full-time job, so capacity is limited and must be protected. Drafts are prepared from his research documents and he reviews and approves them on Monday. A short post takes much less time than an essay, so essays are planned at no more than one every two weeks. The main constraint is his time around the CACU role; results from his LinkedIn profile are ready to use.
{{PRODUCTION_HOURS_AVAILABLE}}- Proposed: about 2 hours a week, mostly the Monday review block.
{{TIME_PER_FORMAT}}- Proposed: LinkedIn post review 20 to 30 minutes; Field Note 30 minutes; Notebook essay 3 to 4 hours; Studio case page 4 to 6 hours.
{{SUSTAINABLE_OUTPUT}}- Proposed: two LinkedIn posts a week plus one longer piece every two to four weeks.
{{CAPACITY_CONSTRAINTS}}- Full-time UX role at CACU; the employer's OK for any new internal results; family time; no editor or designer on record.
{{05_Channel_Frequency_Plan}}- LinkedIn carries the rhythm at two posts a week, with a minimum of one if a week is disrupted. The Notebook gets longer companions to the strongest posts. Instagram and X are not part of the six-week plan. Stretch frequency is only considered after the first six weeks are measured.
{{CHANNEL_FREQUENCIES}}- LinkedIn: 2 posts a week; bennieiv.xyz Notebook: 1 essay every 2 to 4 weeks; Wednesday engagement: 2 comments on market signals.
{{MINIMUM_FREQUENCY}}- Proposed: 1 LinkedIn post a week.
{{TARGET_FREQUENCY}}- Target: 2 LinkedIn posts a week (Tuesday and Thursday).
{{STRETCH_FREQUENCY}}- Proposed: 3 LinkedIn posts a week, only if the frequency test supports it after week 6.
{{06_Day_Time_Slotting}}- Posts go out on Tuesday and Thursday, with drafting and approval on Monday and signal work on Wednesday and Friday. Times are proposed for weekday mornings Central and will be adjusted once LinkedIn analytics exist. The slots keep publishing away from Monday's inbox and Friday's wind-down. The schedule matches the plan: LI-01 on Sep 29 through LI-12 on Nov 5, 2026.
{{CHANNEL_SLOTS}}- LinkedIn post slots: Tuesday and Thursday; engagement slot: Wednesday; review slot: Monday; signals review: Friday.
{{PUBLISH_DAYS}}- Tuesday and Thursday.
{{PUBLISH_TIMES}}- Proposed: 8:00 a.m. Central.
{{SLOT_RATIONALE}}- Mid-week mornings reach working professionals before meetings; Monday approval gives a one-day buffer before the first post.
{{07_Content_Mix_Ratios}}- The mix leans on Ben's owned topics, with credit-union product work carrying most of the series. Of the twelve posts, seven draw on CACU and career work, four on the Card Market console and provenance, and one on craft. Nothing is promotional because nothing is sold. Every post maps to one of the four owned topics.
{{CONTENT_TYPES}}- Practice posts (product architecture); case posts (CACU results); provenance posts (Card Market); craft posts (design decisions).
{{MIX_SHARES}}- Product architecture and career 2 of 12 (LI-01, LI-07); research-led digital banking 5 of 12 (LI-02 to LI-06); evidence and provenance 4 of 12 (LI-08 to LI-11); craft and restraint 1 of 12 (LI-12).
{{PROMOTIONAL_SHARE}}- 0 percent; the program sells nothing and never pitches the card console.
{{PILLAR_ALIGNMENT}}- Each post is tagged to one of the four owned topics: product architecture, research-led digital banking, evidence and provenance, craft and restraint.
{{08_Batch_Production_Schedule}}- Work is batched into one Monday session where the week's two drafts are checked against source research and approved. Planning of upcoming topics happens in the Friday signals review. There is no recording session because the program is text only. Drafts are ready at least one day before their slot.
{{PLANNING_SESSION}}- Friday signals review: read the week in Miniflux and pick one signal worth a future post.
{{WRITING_BLOCK}}- Monday batch draft: check and approve the week's two LinkedIn drafts.
{{RECORDING_SESSION}}- None; the program is text only and no video or audio is planned.
{{SCHEDULING_SESSION}}- Monday, directly after approval: schedule Tuesday and Thursday posts.
{{LEAD_TIME}}- Proposed: drafts ready one week ahead of their slot; approval at least one day before.
{{09_Buffer_Backlog_Rules}}- A small buffer of approved, evergreen posts protects the schedule when a CACU week gets busy or a new internal result awaits the employer's OK. Buffer posts come from topics that do not depend on new internal results, such as craft and provenance. The buffer is refilled at the next Monday session. The program pauses rather than posting unapproved material.
{{BUFFER_SIZE}}- Proposed: 2 approved posts held in reserve.
{{BUFFER_USE_RULES}}- Use a buffer post only when a scheduled draft is not approved or awaits the employer's OK on a new internal result by Monday evening.
{{REPLENISHMENT_RULE}}- Replace any used buffer post at the next Monday session from the evergreen topics (LI-10, LI-12 style).
{{PAUSE_RULES}}- Pause publishing if CACU asks for a mention to be removed, if a post would reveal card values, or during a family or work emergency; resume with the next scheduled slot.
{{10_Frequency_Test_Plan}}- After the six-week series, a frequency test compares two posts a week with three. LinkedIn is the only test channel. The baseline is the six-week series itself. The decision rule protects quality and Ben's time as much as reach.
{{TEST_CHANNEL}}- LinkedIn personal profile.
{{BASELINE_PERIOD}}- Weeks 1 to 6 (Sep 29 to Nov 5, 2026) at two posts a week.
{{TEST_FREQUENCY}}- Proposed: three posts a week (Tuesday, Wednesday, Thursday).
{{TEST_DURATION}}- Proposed: four weeks.
{{TEST_MEASURES}}- Impressions per post; comments per post; conversations started; follower change; Ben's reported hours.
{{DECISION_RULE}}- Keep three a week only if comments per post hold within 20 percent of baseline and weekly hours stay under 3; otherwise return to two.
{{11_Cadence_Performance_Measures}}- Cadence is measured by slots filled and streak length first, then by reach and audience growth. Baselines for reach and followers are captured at week 0 because none are on record. Fatigue indicators are watched every Friday. All numbers are reported with their source and date.
{{SLOTS_FILLED_RATE}}- Target: 12 of 12 slots filled (100 percent) in weeks 1 to 6.
{{CONSISTENCY_STREAK}}- Target: 6 consecutive weeks with both slots filled.
{{REACH_PER_PIECE}}- Impressions per LinkedIn post from LinkedIn analytics; baseline to be set by LI-01 and LI-02.
{{AUDIENCE_GROWTH}}- LinkedIn followers, baseline to capture at week 0 (not on record); Instagram baseline 2,431 (2026-09-25).
{{FATIGUE_INDICATORS}}- Three consecutive posts with falling comments; rising unfollows; reduced Monday approval rate.
{{12_Cadence_Adjustment_Report}}- At the end of week 6, a short report compares the plan with what happened: slots filled, streak, reach and conversations. It records the result of any frequency test and recommends the next cadence. It notes any change in Ben's available hours. No channel is paused unless the data or his capacity calls for it.
{{MEASURE_FINDINGS}}- To be completed at week 6 from LinkedIn analytics; no results exist yet.
{{TEST_RESULTS}}- Pending; the frequency test runs only after the baseline series.
{{FREQUENCY_RECOMMENDATIONS}}- Proposed default: continue two LinkedIn posts a week plus one Notebook essay a month unless the test supports three.
{{CAPACITY_CHANGES}}- Review after the CACU platform migration milestones, when Ben's work load may change.
{{CHANNELS_TO_PAUSE}}- None proposed; Instagram and X stay outside the program until LinkedIn cadence is stable.
{{01_Monitoring_Purpose}}- RSS monitoring feeds Ben's thought-leadership program with timely signals he can respond to in his own voice. It supports the Wednesday engagement slot and the Friday signals review. The only reader is Ben, supported by the drafting pipeline in his console. Speed matters less than relevance because the program comments on developments rather than breaking news.
{{MONITORING_JOBS}}- Find two signals a week to comment on; surface one signal a week worth a new post; track credit-union and digital banking developments relevant to the Q2 migration topic; watch sports-card data and hobby news for the provenance posts.
{{OUTPUT_READERS}}- Ben Niehues IV, and the console's drafting pipeline that proposes LinkedIn drafts for his approval.
{{SPEED_REQUIREMENTS}}- Daily collection is enough; items are reviewed weekly on Friday, with no real-time needs.
{{02_Topic_and_Entity_Watchlist}}- The watchlist mirrors Ben's four owned topics and his day job. It covers digital banking, credit-union technology, UX research practice and sports-card data. Named entities are limited to organizations and people already in his record. Exclusions keep out investment content and price speculation, which the program never publishes.
{{WATCHED_TOPICS}}- Digital banking platform migrations; credit-union digital experience; member personalization; UX research methods; product architecture; data provenance and licensing; sports-card market data.
{{WATCHED_COMPANIES}}- CommunityAmerica Credit Union; Unify Credit Union; Q2; Salesforce; PriceCharting; eBay; Card Ladder; Market Movers; 130 Point; Alt.
{{WATCHED_PEOPLE}}- Ben Niehues IV (mentions of his own work); no other individuals are tracked.
{{KEYWORD_TERMS}}- credit union, digital banking, platform migration, member experience, UX research, personalization, product architecture, grading, PSA 10, sold comps.
{{EXCLUSION_TERMS}}- investment advice, price predictions, card flipping, sponsored, giveaway.
{{03_Feed_Source_Curation}}- Sources come from the feeds already on record plus the four Miniflux categories that are live. They balance banking and credit-union trade news with UX practice and a small amount of card-hobby news. Local Kansas City sources support community relevance. Sites without feeds are checked manually or skipped.
{{CANDIDATE_FEEDS}}- https://www.nngroup.com/feed/rss/; https://uxdesign.cc/feed; https://www.cardlines.com/feed/; https://www.kcur.org/index.rss; https://www.americascreditunions.org/news-media; https://www.kcsourcelink.com/; Startland News (shared Miniflux category).
{{FEED_RELEVANCE}}- NN/g and UX Collective for UX practice; America's Credit Unions for industry context; Cardlines for card-hobby data; KCUR, KC SourceLink and Startland News for Kansas City community and tech.
{{POSTING_FREQUENCY}}- Observed so far in Miniflux: Banking and fintech 12 articles, Credit union trade press 10, Startland News 5, Local business news 0; per-feed frequency not yet measured.
{{FEED_VALIDITY}}- Feeds are live in Miniflux; Local business news has returned 0 articles and needs checking.
{{SITES_WITHOUT_FEEDS}}- americascreditunions.org/news-media and kcsourcelink.com may not expose standard RSS; check manually or replace.
{{04_Collection_Setup}}- Collection runs in Miniflux under categories prefixed "BEN NIEHUES". Items are parsed for title, link, date and summary, and deduplicated by URL. Full text is fetched only where the feed provides a summary alone. Stored items flow into the console's signals table.
{{POLLING_SCHEDULE}}- Proposed: every 6 hours via Miniflux defaults; reviewed weekly on Friday.
{{PARSING_RULES}}- Keep title, link, published date, source and summary; strip tracking parameters; ignore items older than 30 days.
{{DEDUPLICATION_KEYS}}- Canonical URL, then normalized title plus source.
{{FULL_TEXT_RETRIEVAL}}- Use Miniflux's fetch-original-content option only for summary-only feeds; store excerpts, not full copies.
{{STORED_ITEM_FIELDS}}- id; source; category; title; url; published_at; summary; tags; score; status (new, kept, used, dropped).
{{05_Filtering_and_Scoring_Rules}}- Filtering keeps items that connect to an owned topic and drops anything promotional or speculative. Sources are weighted by how closely they match Ben's program. A simple score ranks items for the Friday review. Duplicate stories keep the most authoritative source.
{{KEEP_RULES}}- Keep items about credit-union or digital banking experience, UX research practice, data provenance, or Kansas City product and tech.
{{DROP_RULES}}- Drop sponsored content, price predictions, investment advice, and items with no link to an owned topic.
{{SOURCE_WEIGHTS}}- Proposed: credit-union trade press 1.0; NN/g and UX Collective 0.9; banking and fintech 0.8; Startland News 0.6; Cardlines 0.5; local news 0.4.
{{SCORING_FORMULA}}- Proposed: score = source weight x topic match (0 to 3) x freshness (1.0 under 7 days, 0.5 under 30).
{{DUPLICATE_STORY_RULE}}- When several sources cover one story, keep the highest-weighted source and link the rest.
{{06_Classification_Scheme}}- Items are classified by owned topic first and tagged by entity and format second. Classification is keyword-based with Ben's correction during the Friday review. The scheme matches the post series so a kept item can move straight into the idea queue. Examples below show the intended mapping.
{{PRIMARY_CATEGORIES}}- Product architecture; Research-led digital banking; Evidence and provenance; Craft and restraint; Kansas City community.
{{SECONDARY_TAGS}}- credit-union; platform-migration; personalization; ux-research; data-licensing; sports-cards; design-systems; local.
{{ASSIGNMENT_METHOD}}- Keyword match on title and summary assigns a category; Ben confirms or corrects in the Friday review.
{{EXAMPLE_ITEMS}}- A credit-union platform conversion story goes to Research-led digital banking; an NN/g article on research planning goes to Product architecture; a card-grading data story goes to Evidence and provenance.
{{07_Routing_and_Delivery}}- There are no real-time alerts because the program is not news-driven. Items reach Ben as a weekly digest before the Friday review. Kept items go to the content idea queue in his console. Everything is archived in Miniflux and the console's signals table.
{{REAL_TIME_ALERTS}}- None; mentions of CommunityAmerica Credit Union may be flagged for same-day review.
{{DIGEST_DELIVERIES}}- Weekly digest, Friday morning, top 10 items by score.
{{CONTENT_IDEA_QUEUE}}- Kept items tagged "post idea" go to the console's signals queue for the next Monday drafting session.
{{ARCHIVE_DESTINATION}}- Miniflux archive and the console signals table.
{{RECIPIENTS}}- Ben Niehues IV only.
{{08_Feed_Health_Review}}- Feed health is reviewed monthly. Each feed is checked for fetch errors, the age of its latest item and the share of items kept. Feeds that never yield a kept item are replaced. The Local business news category, currently at 0 articles, is the first to review.
{{FETCH_ERRORS}}- Check Miniflux error counts monthly; fix or remove any feed failing for 7 days.
{{LAST_ITEM_AGE}}- Flag any feed with no new item in 30 days; Local business news currently has none.
{{KEPT_ITEM_SHARE}}- Proposed threshold: a feed should contribute at least 5 percent kept items over a month.
{{READER_ENGAGEMENT}}- Track how many digest items Ben opens, keeps or uses.
{{FEED_DECISIONS}}- Proposed: keep credit-union and UX feeds; review Local business news; keep Cardlines only while provenance posts are running.
{{09_Weekly_Intelligence_Digest}}- The weekly digest gives Ben the top developments in his topics with one line on why each matters. It suggests content angles tied to the current post series. Because there are no commercial competitors, the competitor section tracks alternative card-data tools only. Every item links to its source.
{{TOP_DEVELOPMENTS}}- Top 3 to 5 items of the week by score, each with source, date and one-sentence summary.
{{BUSINESS_IMPLICATIONS}}- One line per item on what it means for credit-union digital experience or for Ben's owned topics, framed as his view.
{{COMPETITOR_MOVES}}- Changes at card-data alternatives (Card Ladder, Market Movers, 130 Point, Alt, eBay price tools) relevant to the provenance posts; no commercial rivals are tracked.
{{CONTENT_ANGLES}}- One or two proposed post angles linking a development to an owned topic, for example a migration story as a hook for "study four".
{{SOURCE_LINKS}}- Direct link to each original article; no paywalled text reproduced.
{{10_Feed_Value_Measures}}- Feed value is judged by whether monitoring produces posts and conversations. Measures run from items collected to items used in published content. Baselines exist only for collection so far. Targets are proposed for the six-week series.
{{ITEMS_COLLECTED}}- Baseline at setup: 27 articles across four Miniflux categories (12 banking and fintech, 10 credit-union trade press, 5 Startland News, 0 local business news).
{{ITEMS_DELIVERED}}- Target: 10 items per weekly digest.
{{DIGEST_ENGAGEMENT}}- Target: Ben reviews every Friday digest during the six-week series.
{{ITEMS_ACTED_ON}}- Target: 2 signals commented on each Wednesday (12 over six weeks).
{{CONTENT_FROM_FEEDS}}- Target: at least 1 post idea a week sourced from a feed, with 2 turned into published posts by week 6.
{{01_Database_Purpose_And_Record}}- The Card Market runs on two Notion databases that the card-market Notion Worker creates and owns: Card Profiles and Card Price History. Card Profiles answers what each listed card is worth at its grade today and what that number rests on; Card Price History keeps one row per card per week so trends read from history rather than a single sale. The record unit is one graded card, identified by year, set, number, player, variant and grade, so the same card entered twice lands on one row and a different grade becomes a new card. Records are written only by the worker's two syncs; Ben maintains the list the syncs read, never the values.
{{DATABASE_PURPOSE}}- Track the market value of a private list of graded sports cards week over week, with the evidence behind each number. The databases serve one owner, Ben, as private research, not a service.
{{RECORD_UNIT}}- Card Profiles: one listed card at one grade (for example 2017 Panini Prizm Patrick Mahomes #269 PSA 10). Card Price History: one card in one ISO week (for example that card in 2026-W39).
{{RECORD_CREATORS}}- The profilesSync (daily, replace) and pricesSync (weekly, incremental) syncs of the Notion Worker; Ben only edits the watchlist (src/watchlist.ts or an optional Notion watchlist database).
{{KEY_QUESTIONS}}- What is this card worth at its grade and on what basis; how has it moved over one and four weeks; how deep is the market (asks, sold in 90 days, liquidity); what premium does a PSA 10 carry over raw and grade 9; which sources are still missing.
{{02_Source_Data_Assessment}}- Source data comes from four places: the watchlist of 15 cards, the ESPN public site API, the eBay Browse and Marketplace Insights APIs, and the PriceCharting Prices API. Today only ESPN returns data, so player, team, position, status, age, draft and season stats are populated while every price field is empty and all 15 cards carry the value basis none. The watchlist columns map cleanly to select and number properties, and sport, grader, value basis and liquidity are natural selects. The main quality issue is not bad data but missing data: one week on file (2026-W39), nothing priced, and liquidity unknown on every card.
{{SOURCE_COLUMNS}}- Watchlist: Player; Sport; Year; Set; Number; Variant; Grader; Grade; Rookie; Active; Query; PricechartingId. Collected: team, position, stats, headshot, asks, sold comps, grade ladder, value basis, sources state.
{{SELECT_CANDIDATES}}- Sport (baseball, basketball, football); Value Basis (price guide, eBay sold, eBay asking, none); Liquidity (deep, moderate, thin, unknown); Grader (PSA, BGS, SGC, CGC, TAG, RAW) on the watchlist.
{{RELATION_CANDIDATES}}- Card Price History to Card Profiles, two-way, shown on the profile as Price History; an optional Notion watchlist database as the input list, read by the worker rather than related.
{{UNUSED_COLUMNS}}- Variant and Query stay on the watchlist only (they shape the card id and eBay search, not the profile); draft and age from ESPN are folded into the Stats text rather than given their own properties.
{{DATA_QUALITY_ISSUES}}- All 15 cards unpriced (value basis none) because eBay Browse and PriceCharting are not configured and Insights is not approved; only one week of history; ESPN team values as returned may lag trades; eBay listing titles need the title filter to drop lots, reprints, breaks and off-grade copies.
{{03_Property_Schema}}- Card Profiles has a title (Card) plus Card ID, Sport, Player, Year, Set, Number, Grade, Rookie, Team, Position, Market Value, Value Basis, 1W Change, 4W Change, Ask Median, Ask Low, Asks, Sold Median, Sold (90d), Raw, Grade 9, PSA 10, PSA 10 Multiple, Liquidity, Stats, Read, Sources, Card Image, Headshot, eBay Sold Search, Price Guide, ESPN and Updated. Card Price History has Snapshot (title), Snapshot ID, Card (relation), Sport, Week, Week Of and the same price fields per week. Money is stored as dollar numbers, changes as percent numbers, and every price row carries its Value Basis. There is no status property because the worker, not a person, moves records.
{{PROPERTY_NAMES}}- Card; Card ID; Sport; Player; Year; Set; Number; Grade; Rookie; Team; Position; Market Value; Value Basis; 1W Change; 4W Change; Ask Median; Ask Low; Asks; Sold Median; Sold (90d); Raw; Grade 9; PSA 10; PSA 10 Multiple; Liquidity; Stats; Read; Sources; Card Image; Headshot; eBay Sold Search; Price Guide; ESPN; Updated.
{{PROPERTY_TYPES}}- Title (Card, Snapshot); rich text (Card ID, Player, Set, Number, Grade, Team, Position, Stats, Read, Sources, Week); select (Sport, Value Basis, Liquidity); number in dollars (Market Value, Ask Median, Ask Low, Sold Median, Raw, Grade 9, PSA 10); number in percent (1W, 4W Change); number (Year, Asks, Sold (90d), PSA 10 Multiple); checkbox (Rookie); file (Card Image); URL (Headshot, eBay Sold Search, Price Guide, ESPN); date (Updated, Week Of); relation (Card).
{{SELECT_OPTIONS}}- Sport: baseball (red), basketball (orange), football (brown). Value Basis: price guide (green), eBay sold (blue), eBay asking (yellow), none (gray). Liquidity: deep (green), moderate (yellow), thin (red), unknown (gray).
{{STATUS_GROUPS}}- None by design: the worker writes every record, so readiness is expressed by Value Basis (none means unpriced) and Liquidity (unknown means too little evidence) rather than a manual status.
{{REQUIRED_PROPERTIES}}- Card, Card ID, Sport, Player, Year, Set, Number, Grade, Value Basis, Sources and Updated on every profile; Snapshot, Snapshot ID, Card, Week and Value Basis on every history row.
{{04_Relation_Map}}- The schema has one relation: each Card Price History row points to its card in Card Profiles, and the relation is two-way so every profile shows its weekly rows under Price History. A profile has many snapshots and a snapshot has exactly one card. The optional Notion watchlist is an input the worker reads, not a relation, which keeps the list editable without touching the managed databases. No merge is needed; the two databases hold different grains, one card versus one card-week.
{{RELATIONS}}- Card Price History.Card to Card Profiles, paired with Card Profiles.Price History.
{{TARGET_DATABASES}}- Card Profiles (target of Card) and Card Price History (target of Price History); the watchlist database is read-only input when CARD_WATCHLIST_DATABASE_ID is set.
{{RELATION_DIRECTION}}- Two-way; written from the history side by pricesSync, with the reverse property generated on the profile.
{{CARDINALITY_LIMITS}}- One card to many weekly snapshots (about 52 a year per card); each snapshot links to exactly one card; the worker keeps the last half-year of weekly points in sync state for trend maths.
{{MERGE_CANDIDATES}}- None; merging would mix a replace-mode daily table with an incremental weekly table and break history, since replace mode would delete past weeks.
{{05_Rollups_And_Formulas}}- The worker computes the derived numbers in code (analyze.ts) and writes them as plain properties, because a sync cannot read the database it writes and Notion formulas cannot see the sync's half-year state. 1W Change, 4W Change, PSA 10 Multiple, Liquidity and the Read are therefore stored values, not Notion formulas. The only rollup worth adding in Notion is a count of priced weeks per card from Price History, which tells Ben when trends are allowed to start. Proposed: a formula flag that shows Unpriced when Value Basis is none, so views can filter it.
{{ROLLUP_PROPERTIES}}- Proposed: Priced Weeks (count of Price History rows where Value Basis is not none); Last Week On File (latest Week Of from Price History).
{{FORMULA_PROPERTIES}}- Proposed: Unpriced (checkbox formula); Trend Ready (checkbox formula); Evidence Label (text formula combining Value Basis and Sold (90d)).
{{FORMULA_LOGIC}}- Unpriced = Value Basis is none. Trend Ready = Priced Weeks is at least 2, matching the console rule that trends start after two priced weeks. Evidence Label = Value Basis plus the count behind it, for example eBay sold, 12 in 90 days.
{{DERIVED_FLAGS}}- Unpriced; Trend Ready; Thin Market (Liquidity is thin or unknown); Source Missing (Sources text contains not configured).
{{PROGRESS_CALCULATIONS}}- Cards priced out of 15 (baseline 0 of 15 on 2026-09-22) and weeks of history on file (baseline 1, 2026-W39). Target: 15 of 15 priced with at least 8 weeks of history at 90 days.
{{06_View_Set}}- Card Profiles gets four views: The Market (table grouped by Sport, sorted by Market Value), Unpriced (cards whose Value Basis is none, showing Sources so the missing connector is obvious), Gallery (Card Image with Player, Grade and Value Basis) and Movers (Trend Ready cards sorted by 1W Change). Card Price History gets a Weekly Log table grouped by Week and a By Card view filtered to one card. These mirror the console's own market page and per-card workspace so Ben reads the same thing in Notion and on the site. Every view shows Value Basis next to any price, because no number appears without its basis.
{{VIEW_NAMES}}- The Market; Unpriced; Gallery; Movers; Weekly Log; By Card.
{{VIEW_LAYOUTS}}- The Market: table; Unpriced: table; Gallery: gallery with Card Image cover; Movers: table; Weekly Log: table; By Card: table (or line chart once 8 priced weeks exist).
{{VIEW_FILTERS}}- Unpriced: Value Basis is none. Movers: Trend Ready is checked. By Card: Card contains the selected profile. The Market: none (all 15 cards).
{{VIEW_GROUPINGS}}- The Market and Gallery grouped by Sport; Weekly Log grouped by Week; Movers ungrouped, sorted by 1W Change descending.
{{VISIBLE_PROPERTIES}}- The Market: Card, Grade, Market Value, Value Basis, 1W Change, Liquidity, Updated. Unpriced: Card, Sources, Updated. Weekly Log: Snapshot, Week Of, Market Value, Value Basis, Asks, Sold (90d).
{{07_Database_Templates}}- Because the worker creates every row, database templates are few and used only for manual notes Ben adds alongside a card. Proposed: one Card Note template that sits inside a profile page with headings for Why this card, What would change my view and Sources checked. The default for new pages is no template, so worker-written rows stay clean. No repeating templates are needed; the weekly cadence lives in the pricesSync schedule, not in Notion recurrence.
{{TEMPLATE_NAMES}}- Proposed: Card Note.
{{DEFAULT_PROPERTY_VALUES}}- None set on worker rows; for a manual Card Note, Value Basis defaults to none until a sync writes a price.
{{TEMPLATE_BODY_BLOCKS}}- Card Note: heading Why this card; heading What would change my view; heading Sources checked, with a callout reminding that an ask is not a sale and values stay private.
{{DEFAULT_TEMPLATE}}- None; worker-created rows must not inherit template blocks.
{{REPEATING_TEMPLATES}}- None; the weekly snapshot is produced by pricesSync every 7 days.
{{08_Data_Entry_Rules}}- People enter data in one place only: the watchlist. Each watchlist row needs Player, Sport, Year, Set, Number, Grader and Grade (null for RAW), and unticking Active pauses a card without deleting its history. Select options on the managed databases are fixed in the worker schema and changed only in code. Titles follow the worker's pattern so the same card always resolves to the same id, and the managed databases are treated as locked for manual edits.
{{REQUIRED_ENTRY_FIELDS}}- Watchlist: Player; Sport; Year; Set; Number; Grader; Grade (except RAW); Rookie and Active checkboxes set deliberately.
{{OPTION_GOVERNANCE}}- Sport, Value Basis and Liquidity options are defined in src/index.ts and change only through a code change and redeploy; nobody adds options by hand in Notion.
{{TITLE_NAMING_PATTERN}}- Profiles: <Year> <Set> <Player> #<Number> · <Grader> <Grade>, for example 2011 Topps Update Mike Trout #US175 · PSA 10. History: the same title followed by an em dash and the ISO week, for example — 2026-W39.
{{ARCHIVE_RULE}}- Untick Active on the watchlist to drop a card from Card Profiles on the next daily replace; its Price History rows are kept because pricesSync is incremental and never sweeps past weeks.
{{STRUCTURE_LOCKING}}- Lock both managed databases against schema edits; schema changes happen in code, and a sync state reset is reserved for deliberate restarts because it empties the trend history the worker holds.
{{09_Schema_Test_Scenarios}}- The schema is tested against the questions it exists to answer, using the real 15-card list. The core test is that the Unpriced view shows all 15 cards today with Sources naming eBay Browse and PriceCharting as not configured, and that it empties as connectors are added. Edge cases include a RAW card (2020 Panini Prizm Joe Burrow), a PSA 9 card (2003 Topps Chrome LeBron James), the same card entered twice and a grade change. Any test that shows a price without a Value Basis, or an ask labelled as a sale, fails the schema.
{{ANSWER_TESTS}}- Can Ben see every card's value and basis in The Market; can he find which source is missing for a card; can he read one card's weekly history in By Card; does Movers stay empty until two priced weeks exist.
{{EDGE_CASE_TESTS}}- Duplicate watchlist entry lands on one row; changing Grade creates a new card; RAW card excludes graded listings; paused card keeps history; worker run with no secrets still fills ESPN fields.
{{SAMPLE_RECORDS}}- 2011 Topps Update Mike Trout #US175 PSA 10; 2017 Panini Prizm Patrick Mahomes #269 PSA 10; 2020 Panini Prizm Joe Burrow #307 RAW; 2003 Topps Chrome LeBron James #111 PSA 9.
{{ANSWERING_VIEWS}}- The Market answers value and basis; Unpriced answers what is missing; By Card answers trend; Movers answers weekly change once Trend Ready.
{{FAILED_TESTS}}- Current expected failures are data, not schema: Movers and 4W Change stay empty and Liquidity reads unknown until price sources are connected and two priced weeks exist.
{{10_Database_Import_And_Launch}}- There is no import from an old tracker: the databases are created by ntn workers deploy, which builds both managed databases, and then filled by triggering profilesSync and pricesSync. The recommended order is a preview run of profilesSync, a live profilesSync, then pricesSync, then ntn workers sync status to confirm. The relation rebuilds itself because pricesSync writes the Card relation on each weekly row. Deploying and running workers needs a Notion Business or Enterprise plan, which is the first launch prerequisite.
{{IMPORT_METHOD}}- Worker deploy (ntn workers deploy) followed by sync triggers; the local collector (npm run collect) writes site/data/market.json for development only and is not the record.
{{IMPORT_ORDER}}- Deploy worker; set whichever price secrets exist (EBAY_CLIENT_ID and EBAY_CLIENT_SECRET, PRICECHARTING_TOKEN, EBAY_INSIGHTS=1 once approved); profilesSync --preview; profilesSync; pricesSync; sync status.
{{RELATION_REBUILD}}- Automatic: each pricesSync upsert keys the row as card id at week and sets the Card relation to that profile.
{{ROLLUP_VERIFICATION}}- After the first priced week, confirm Priced Weeks reads 1 on priced cards and 0 on unpriced ones, and that Trend Ready stays unchecked until a second priced week lands.
{{OLD_TRACKER_RETIREMENT}}- Not applicable; there was no earlier tracker. The static site/data/market.json fallback remains for local development and should be described as a fallback, never as the source of record.
{{11_Database_Usage_Review}}- Usage is reviewed monthly by Ben alone, since he is the only user. The review checks whether the daily and weekly syncs ran, how many cards moved from none to a real value basis, which properties stay blank and why, and whether any view is no longer opened. Proposed: remove a property only after two monthly reviews show it blank for reasons that are not a missing connector. The baseline for the first review is 0 of 15 priced and one week on file.
{{RECORD_CREATION_RATE}}- Expected: 15 profile rows refreshed daily and 15 history rows added per week while the list is 15 cards; about 60 to 65 history rows a month.
{{BLANK_REQUIRED_FIELDS}}- Baseline 2026-09-22: all price fields blank on 15 of 15 cards because no price source is connected; ESPN fields populated on all 15.
{{UNUSED_PROPERTIES}}- Candidates to watch: Ask Low and Price Guide link, which stay blank until eBay Browse and PriceCharting are connected; review only after connectors are live.
{{STALE_STATUS_RECORDS}}- Flag any profile whose Updated date is more than two days old (daily sync missed) and any card with no history row for the latest ISO week (weekly sync missed).
{{SCHEMA_REVIEW_CADENCE}}- Monthly usage review; schema changes only in code at a quarterly review or when a new price source is added.
{{01_Connector_Purpose}}- The card-market Notion Worker is the connector between Ben's Notion workspace and four outside data sources: the ESPN public site API, the eBay Browse API, the eBay Marketplace Insights API and the PriceCharting Prices API. It lets a Notion Custom Agent research any baseball, basketball or football card on demand through one tool, researchCard, and it feeds the Card Profiles and Card Price History databases on a schedule. Its only user is Ben, and its purpose is private research: what a card is worth at its grade and what that number is based on. It never buys, sells, lists or publishes anything.
{{TARGET_SYSTEM}}- Ben's Notion workspace (Notion Workers on a Business or Enterprise plan), drawing on ESPN, eBay Browse, eBay Marketplace Insights and PriceCharting.
{{ENABLED_JOBS}}- Research one card on demand; refresh card profiles daily; record one weekly price snapshot per card; report which sources returned data for each card.
{{CONNECTOR_USERS}}- Ben Niehues IV only, through a Notion Custom Agent and the two managed databases; the console behind bennieiv.xyz/login is single-password.
{{OUT_OF_SCOPE_JOBS}}- Scraping eBay pages (robots.txt disallows /sch/); placing bids, buying or listing cards; publishing card values to anyone else (PriceCharting licence is internal use); investment advice.
{{02_API_Surface_Review}}- Four APIs sit behind the connector, each with a different access model. ESPN's public site API needs no key and supplies bio, headshot and season-by-season stats; eBay Browse needs a free developer production keyset for active listings; eBay Marketplace Insights needs eBay's approval for the Insights scope before it returns sold listings from the last 90 days; PriceCharting needs a paid token and returns value at every grade. Today only ESPN is live, so the connector returns player data and names the other three as not configured. The worker paces its calls and treats any missing source as skipped rather than as an error.
{{RELEVANT_ENDPOINTS}}- ESPN public site API (athlete bio and stats); eBay Browse item_summary search (active listings); eBay Marketplace Insights item_sales search (sold, 90 days); PriceCharting product lookup (grade ladder: raw, 7, 8, 9, 9.5, PSA/BGS/SGC/CGC/TAG 10).
{{API_AUTH_MODEL}}- ESPN: none. eBay Browse and Insights: OAuth client-credentials application token from EBAY_CLIENT_ID and EBAY_CLIENT_SECRET, with Insights gated by EBAY_INSIGHTS=1 after approval. PriceCharting: PRICECHARTING_TOKEN on a paid subscription.
{{RATE_LIMITS}}- Proposed working limits: stay well under eBay's published daily call quotas for a developer keyset and under PriceCharting plan limits; at 15 cards the weekly load is a few dozen calls, and the worker paces requests between cards.
{{PAGINATION_MODEL}}- Listing searches take the first page of results after the title filter; syncs page through the watchlist in batches with hasMore and nextState, resetting the index when the list is done.
{{API_CONSTRAINTS}}- No scraping of eBay search or sold pages; PriceCharting values are for internal use only; Insights is unavailable until eBay grants the scope; ESPN is an unofficial public endpoint and may change without notice.
{{03_Capability_Mapping}}- The connector maps its jobs to the smallest set of primitives that does the work. On-demand research is one tool, researchCard; scheduled work is two syncs, profilesSync and pricesSync, which write managed databases instead of exposing tools. Reading the list is a resource-like input, the watchlist, rather than a tool the agent calls. One tool is enough because every research question starts from one card identity and returns one profile.
{{JOB_TO_PRIMITIVE_MAP}}- Research one card: tool researchCard. Refresh profiles: sync profilesSync (1d, replace). Record weekly prices: sync pricesSync (7d, incremental). Read the list: watchlist input (src/watchlist.ts or the Notion watchlist database).
{{TOOL_SET}}- researchCard (read-only).
{{RESOURCE_SET}}- Card Profiles database; Card Price History database; the watchlist.
{{PROMPT_SET}}- Proposed: one saved agent prompt, Research this card, which asks for sport, player, year, set, number, grader and grade, then summarises value, basis and the read.
{{TOOL_COUNT_RATIONALE}}- A single tool keeps the agent from guessing between overlapping calls; profiles and prices are schedule-driven and belong in syncs, not in tools an agent could trigger repeatedly.
{{04_Tool_Definitions}}- researchCard, titled Research a sports card, looks up one baseball, basketball or football card and returns the player's latest stats, current eBay asks and photos, price-guide values across grades and a plain-language read of the market. It works for any card, not only cards on the watchlist. Its inputs are sport, player, year, set, number, grader and grade, validated against enums where possible. Its output always includes valueBasis and sources, so the agent can say what a number rests on and which sources were missing.
{{TOOL_NAMES}}- researchCard.
{{TOOL_DESCRIPTIONS}}- Look up one baseball, basketball or football card: the player's latest stats, current eBay asks and photos, price-guide values across grades, and a plain-language read of the market. Works for any card, not only ones on the watchlist.
{{INPUT_SCHEMAS}}- sport: enum baseball, basketball, football; player: string (as printed, e.g. Ronald Acuña Jr.); year: integer; set: string (e.g. Topps Update); number: string without # (e.g. US250); grader: enum PSA, BGS, SGC, CGC, TAG, RAW; grade: string or null for RAW.
{{OUTPUT_STRUCTURES}}- card; marketValue; valueBasis; asks; sold; gradeLadder; player (name, team, position, stats); read (list of signals); image; cheapestListings (up to 5: title, price, url); ebaySoldSearch; sources; or error when the input cannot be normalised.
{{BEHAVIOUR_ANNOTATIONS}}- Read-only; idempotent; open-world (calls external APIs); non-destructive; results may be partial when a source is not configured.
{{05_Resource_Definitions}}- The connector's resources are the two managed Notion databases and the watchlist it reads. Card Profiles is one row per listed card and Card Price History one row per card per ISO week, each addressed by a stable key derived from the card id. The worker does not offer live subscriptions; freshness comes from the daily and weekly schedules. Content is Notion properties plus JSON for the local development fallback.
{{RESOURCE_URIS}}- notion database: Card Profiles; notion database: Card Price History; watchlist: src/watchlist.ts or the database named by CARD_WATCHLIST_DATABASE_ID.
{{RESOURCE_TEMPLATES}}- Card key <year>-<set>-<number>-<player>-<grader>-<grade> (e.g. 2011-topps-update-us175-mike-trout-psa-10); snapshot key <card id>@<ISO week> (e.g. @2026-W39).
{{CONTENT_TYPES}}- Notion page properties (title, rich text, select, number, checkbox, file, URL, date, relation); application/json for site/data/market.json and history.json in local development.
{{SUBSCRIPTION_SUPPORT}}- None; freshness is scheduled (profiles daily, prices weekly) and on-demand through researchCard.
{{06_Auth_and_Transport_Design}}- The connector runs as a Notion Worker, so transport and user authorisation to Notion are handled by the Notion Workers platform and the owner's workspace. Outbound calls use server-side secrets set with ntn workers env set; no secret is ever exposed to the agent or written into a row. eBay access uses an application token from client credentials, with the Insights scope only after eBay approval. A source whose secret is missing is skipped and named in the Sources column rather than failing the run.
{{TRANSPORT_CHOICE}}- Notion Workers runtime (hosted by Notion) for syncs and the tool; outbound HTTPS to ESPN, eBay and PriceCharting.
{{AUTHORISATION_FLOW}}- Workspace owner deploys the worker; eBay client-credentials grant for an application token; static token for PriceCharting; optional NOTION_API_TOKEN to read a Notion watchlist.
{{OAUTH_SCOPES}}- eBay: the public buy scope for Browse and, once approved, the Marketplace Insights scope; Notion: read access to the watchlist database only.
{{TOKEN_STORAGE}}- Worker environment secrets (EBAY_CLIENT_ID, EBAY_CLIENT_SECRET, PRICECHARTING_TOKEN, NOTION_API_TOKEN) set with ntn workers env set; local development reads a gitignored .env. Secret names are documented, values never.
{{TOKEN_VALIDATION}}- On each run the worker checks which secrets are present and records each source's state (ok, not configured, error) in the row's Sources field; expired eBay tokens are re-requested per run.
{{07_Error_and_Limit_Handling}}- Errors are classified so the agent can say plainly what happened instead of guessing. A missing secret is not configured and is reported, not retried; a bad card input returns an error message naming the field; an upstream timeout or rate limit is retried once with back-off and then recorded as a source error. Whatever fails, the row still carries its value basis, so a missing price shows as none rather than as zero. Model-facing messages are short and name the next step, for example set PRICECHARTING_TOKEN (paid subscription).
{{ERROR_CLASSES}}- not configured (missing secret); not approved (Insights scope); invalid input (card cannot be normalised); upstream error (5xx or timeout); rate limited (429); no match (no listings pass the title filter).
{{MODEL_FACING_MESSAGES}}- No price source is returning a value for this card yet, see Config for which one is missing; 1 week on file, none priced yet, trends start after two priced weeks; set EBAY_CLIENT_ID and EBAY_CLIENT_SECRET.
{{RETRY_RULES}}- Proposed: retry upstream 5xx and 429 once after a back-off; never retry not configured, not approved or invalid input; a failed card does not stop the batch.
{{TIMEOUT_RULES}}- Proposed: 10 seconds per outbound request and one card at a time with pacing, so a slow source degrades one card's row rather than the whole sync.
{{08_Security_Review}}- The connector is read-only against every outside system, which removes the biggest risk class: it cannot buy, bid, list or delete anything on eBay. The main risks are secret leakage and prompt injection from listing titles returned by eBay into the agent's context. Secrets live only in worker environment variables and are never echoed into rows or tool output. Listing titles are treated as data, passed through the title filter and shown as quoted text, never as instructions.
{{SCOPE_REVIEW}}- Only read scopes are requested: eBay Browse and Insights search, PriceCharting prices, ESPN public data, and read access to one Notion watchlist; no write scopes to any marketplace.
{{INJECTION_RISKS}}- eBay listing titles and seller text flowing into the Custom Agent; mitigated by returning them as structured fields, capping cheapestListings at five and never executing text from results.
{{DESTRUCTIVE_ACTION_CONTROLS}}- None needed against outside systems (no write calls exist); inside Notion, replace mode is limited to Card Profiles, and Card Price History is incremental so past weeks are never swept.
{{CROSS_USER_ISOLATION}}- Single-owner workspace and a single-password console; no multi-user data, and PriceCharting values are not shared outside Ben's private use.
{{SECURITY_FIXES}}- Proposed: confirm no secret appears in the Sources text; keep .env gitignored; add a check that published pages on bennieiv.xyz never render Market Value fields.
{{09_Connector_Test_Plan}}- Testing covers the schema, the platform, the install and real agent tasks. Schema tests validate researchCard inputs against the enums and reject a card without a number; conformance tests run each sync with --preview and check that keys are stable. The install test is a clean deploy with no secrets, which must still fill ESPN fields for all 15 cards. Agent tests ask the Custom Agent to research known cards and pass only if every value it states names its basis.
{{SCHEMA_TESTS}}- Valid input for 2018 Topps Update Ronald Acuña Jr. #US250 PSA 10 accepted; RAW with grade null accepted; unknown grader rejected; missing number rejected with a clear error.
{{CONFORMANCE_TESTS}}- ntn workers sync trigger profilesSync --preview shows 15 rows; a second preview produces the same keys; pricesSync adds rows for the new ISO week only.
{{CLIENT_INSTALL_TESTS}}- npm run check passes; ntn workers deploy creates both databases; ntn workers sync status reports both syncs healthy on a Business or Enterprise plan.
{{AGENT_TASK_TESTS}}- Ask the agent to research the 2017 Panini Prizm Patrick Mahomes #269 PSA 10 and report its value basis; ask for a card not on the list; ask for a trend on a card with one week on file and expect it to decline.
{{PASS_CONDITIONS}}- Every stated value has a basis; no ask is described as a sale; missing sources are named; no trend is claimed before two priced weeks.
{{10_Release_and_Versioning}}- The connector is released by redeploying the worker from the tenant repo, with the README as its installation guide. Permissions are explained source by source: what each gives and which secret it needs. The capability list is short, one tool and two syncs, and usage examples use real cards from the list. Proposed: record each schema or source change in a dated changelog line in the README, and treat any change to property names as breaking because views and the console depend on them.
{{INSTALLATION_GUIDE}}- npm install; npm run check; ntn workers deploy; set any price secrets you have; optionally set NOTION_API_TOKEN and CARD_WATCHLIST_DATABASE_ID; trigger profilesSync with --preview, then profilesSync and pricesSync; check sync status.
{{PERMISSIONS_EXPLAINED}}- ESPN needs nothing; eBay Browse needs a free developer production keyset; eBay Insights needs eBay's approval; PriceCharting needs a paid token and its data stays internal; Notion needs a Business or Enterprise plan to run workers.
{{CAPABILITY_LIST}}- researchCard tool; profilesSync (daily, replace) into Card Profiles; pricesSync (weekly, incremental) into Card Price History; value basis on every row; listing filter that drops lots, reprints, breaks and off-grade copies.
{{USAGE_EXAMPLES}}- Research 2003 Topps Chrome LeBron James #111 PSA 9; research 2020 Panini Prizm Joe Burrow #307 RAW; list which of the 15 cards are still unpriced and why.
{{CHANGE_POLICY}}- Proposed: additive changes (new source, new property) ship any time; renaming or removing a property or select option is breaking and needs the views and console updated in the same change.
{{11_Connector_Adoption_Measures}}- Adoption for a one-person connector is measured by reliability and coverage, not installs. The meaningful numbers are how many of the 15 cards return a real value basis, how often syncs succeed, how often Ben calls researchCard and how often any source errors. Baseline on 2026-09-22 is one install, one user, 0 of 15 cards priced and one week of history. Target: 15 of 15 priced with at least 8 weeks of history at 90 days, and zero missed weekly syncs.
{{INSTALL_COUNT}}- 1 (Ben's workspace; deployment recorded in workers.json, environment prod).
{{ACTIVE_USERS}}- 1 (Ben); not intended for others while PriceCharting data is under an internal-use licence.
{{CALLS_PER_TOOL}}- researchCard: not yet measured; Proposed: log calls per week from the worker logs starting at the first priced week.
{{TOOL_ERROR_RATE}}- Baseline: price sources report not configured on 15 of 15 cards (a setup state, not an error); Target: under 5 percent upstream errors per weekly run once connected.
{{UNUSED_TOOLS}}- None; the only tool is researchCard. Review after 90 days whether it is used beyond the watchlist.
{{01_Hard_Coded_Value_Audit}}- The token work starts from the measured palette of bennieiv.xyz, read from computed styles and the site's own --va-* custom properties on 2026-09-22, and from the tenant's copies of it (tokens.json, the console theme .tt-ben-niehues-iv and the registry COLOR entry). The site already declares its colours as tokens, so the audit targets the places that repeat the hex by hand: the registry accent #c0431a, the console theme's accent text #e1521c, and the card-market console, which still wears Intelligent Operations tokens on purpose. Type sizes and spacing were not measured, so those raw values are the audit's open gap. The goal is one token file every surface reads, with no hex, size or spacing typed outside it.
{{RAW_COLOUR_VALUES}}- #c0431a repeated in registry.ts COLOR, tenant-themes.css and brand-kit.json; #e1521c in the console theme as accent text on dark; the card-market console's IO orange (#ff9013) where it should read the tenant accent once rebranded.
{{RAW_SIZE_VALUES}}- Not measured on 2026-09-22; Proposed: capture font sizes and line heights from bennieiv.xyz at 1568px and 390px before defining the type scale.
{{RAW_SPACING_VALUES}}- Not measured; Proposed: record margins and gaps from the Notebook, Studio and home layouts and map them to a 4px-based scale.
{{NEAR_DUPLICATE_VALUES}}- #100E09 in icon.svg versus ink #1a1917; the Radix tomato step 9 #e54d2e in the console brand kit versus the site accent #c0431a; ink-100 #e4e3de versus paper-sunken #edebe4 used as hairline and band.
{{SINGLE_USE_VALUES}}- Status colours live #3fa80a and draft #e0a400 appear only on status marks; accent-line #e0a183 only on accent borders; keep them as tokens but do not extend their use.
{{02_Token_Tier_Model}}- The model has three tiers. Primitives hold the raw measured values, such as va-orange-600 for #c0431a and va-stone-900 for #1a1917. Semantic tokens name roles, such as color-surface-page, color-text-body and color-action-primary, and only ever reference primitives. Component tokens are aliases for the few places that need them, such as button, link, card and navigation, and only ever reference semantic tokens.
{{PRIMITIVE_TIER}}- Raw values from tokens.json: paper, stone and ink steps, the orange accent family, status green and amber, the IBM Plex families, radius 0.
{{SEMANTIC_TIER}}- Role names that surfaces and components use: surface, text, border, action, focus and feedback roles, each pointing at one primitive.
{{COMPONENT_TIER}}- Aliases only where a component needs a role beyond the semantic set: button, input, card, navigation, kicker rule and status mark.
{{REFERENCE_RULES}}- Components reference semantic tokens only; semantic tokens reference primitives only; primitives hold literal values; no tier skips a level and no literal appears in component CSS.
{{EXAMPLE_TOKENS}}- --va-orange-600: #c0431a; --va-color-action-primary: var(--va-orange-600); --va-link-color: var(--va-color-action-primary).
{{03_Token_Naming_Convention}}- Names keep the site's own prefix, --va-, so tokens stay recognisable as Ben's rather than Intelligent Operations'. The grammar is prefix, category, role, variant and state, in that order, all lowercase and hyphenated. Role words describe what a value does, never what it looks like, at the semantic tier. Platform exports translate the same names mechanically, so one name means one thing everywhere.
{{NAME_GRAMMAR}}- --va-<category>-<role>-<variant>-<state>, e.g. --va-color-text-secondary or --va-color-action-primary-hover.
{{SEGMENT_ORDER}}- Prefix (va); category (color, font, space, radius, shadow, motion); role; variant; state.
{{ROLE_VOCABULARY}}- surface (page, raised, sunken); text (primary, body, secondary, muted, on-accent); border (rule, hairline, accent); action (primary); focus; feedback (live, draft).
{{STATE_VOCABULARY}}- default (omitted); hover; pressed; focus; disabled; selected.
{{PLATFORM_NAME_MAPPING}}- CSS custom property --va-color-text-body; JSON path color.text.body; TypeScript constant vaColorTextBody.
{{FORBIDDEN_PATTERNS}}- Colour names at the semantic tier (orange, grey); IO names (--io-*, --tk-*) in Ben's files; numeric-only names without category; one-off tokens for a single page.
{{04_Primitive_Token_Set}}- The primitive set is the measured palette plus the three IBM Plex families and a radius of zero. Colours: paper #f5f4f0, paper-raised #fbfaf7, paper-sunken #edebe4, ink #1a1917, ink-700 #3b3a35, ink-500 #6e6a61, ink-300 #a8a399, ink-200 #d3cfc5, ink-100 #e4e3de, accent #c0431a, accent-ink #99340f, accent-vivid #e1521c, accent-tint #f7e7df, accent-line #e0a183, live #3fa80a and draft #e0a400. Type sizes, spacing, elevation and motion were not measured and are proposed until a second measurement pass confirms them. The site is flat and square, so elevation and radius primitives stay minimal.
{{COLOUR_PRIMITIVES}}- paper #f5f4f0; paper-raised #fbfaf7; paper-sunken #edebe4; ink #1a1917; ink-700 #3b3a35; ink-500 #6e6a61; ink-300 #a8a399; ink-200 #d3cfc5; ink-100 #e4e3de; accent #c0431a; accent-ink #99340f; accent-vivid #e1521c; accent-tint #f7e7df; accent-line #e0a183; live #3fa80a; draft #e0a400.
{{TYPE_PRIMITIVES}}- font-mono IBM Plex Mono (labels, kickers, navigation, the name; uppercase, letter-spaced); font-serif IBM Plex Serif (headlines); font-sans IBM Plex Sans (body). Proposed size scale: 12, 14, 16, 18, 22, 28, 36, 48 px, pending measurement.
{{SPACING_PRIMITIVES}}- Proposed: 4px base with steps 4, 8, 12, 16, 24, 32, 48, 64, 96, confirmed against the live site before adoption.
{{RADIUS_PRIMITIVES}}- radius-0: 0px, the only radius; all 15 links and buttons measured square. The app icon's rounded square is an icon asset, not a UI radius.
{{ELEVATION_PRIMITIVES}}- None measured; the site separates surfaces with paper tones and hairline rules rather than shadows. Proposed: shadow-none only.
{{MOTION_PRIMITIVES}}- Not measured; Proposed: duration-fast 120ms and duration-base 200ms with a standard ease, used only for hover and focus, and disabled under reduced motion.
{{05_Semantic_Token_Map}}- Surfaces map to the three paper tones, text to the ink steps, borders to ink-200 and ink-100 with accent-line for accent borders, and the single action colour to the burnt orange accent with accent-ink for hover and pressed. Focus uses the accent, as the site already does for its focus ring. Feedback roles are the two status colours, live and draft. Error and warning roles are left unmapped on purpose, because the site has no error states today.
{{SURFACE_ROLES}}- surface-page: paper #f5f4f0; surface-raised: paper-raised #fbfaf7; surface-sunken: paper-sunken #edebe4; surface-selection: accent-tint #f7e7df.
{{TEXT_ROLES}}- text-primary (headlines): ink #1a1917; text-body: ink-700 #3b3a35; text-secondary: ink-500 #6e6a61; text-muted (labels): ink-300 #a8a399; text-link: accent #c0431a.
{{BORDER_ROLES}}- border-rule: ink-200 #d3cfc5; border-hairline: ink-100 #e4e3de; border-accent: accent-line #e0a183; kicker rule: accent #c0431a.
{{ACTION_ROLES}}- action-primary: accent #c0431a; action-primary-hover and pressed: accent-ink #99340f; action-on-dark: accent-vivid #e1521c; focus ring: accent #c0431a.
{{FEEDBACK_ROLES}}- feedback-live: #3fa80a; feedback-draft: #e0a400.
{{UNMAPPED_ROLES}}- error, warning, info and success-on-dark have no source values; Proposed: add them only when a real state needs them, checked for contrast on paper.
{{06_Theme_And_Mode_Strategy}}- Ben's own brand runs one light theme on warm paper, and the dark mode is limited to what exists today: the accent-vivid step for accent on dark. The tenant console is a second theme that re-points the semantic tier at the Radix tomato scale nearest the accent, so the same component tokens work in both. The card-market console is a third, deliberately IO-styled theme, and rebranding it is a data change to the semantic map rather than a code change. Every theme passes contrast checks before it ships.
{{THEME_LIST}}- bennieiv (the personal site, measured palette); tenant console (.tt-ben-niehues-iv, Radix tomato scale); card-market console (IO design language until rebranded).
{{MODE_LIST}}- light (default on paper); dark (Proposed, using accent-vivid #e1521c on dark surfaces, as the console already does).
{{OVERRIDDEN_TIER}}- Semantic tier only; primitives stay fixed per theme and component aliases never change per theme.
{{THEME_SELECTION_MECHANISM}}- A theme class on the root element (.tt-ben-niehues-iv in the console) plus prefers-color-scheme with a data-theme override for mode.
{{PER_THEME_CONTRAST_CHECKS}}- Check text-body #3b3a35, text-secondary #6e6a61 and link #c0431a on paper #f5f4f0 against WCAG AA; check ink-300 #a8a399 labels (likely below 4.5:1, so large or non-essential text only); check accent-vivid on dark surfaces.
{{07_Component_Token_Aliases}}- Component aliases are created only where a component needs a value its semantic role does not already express. Buttons and links share the action role and radius 0; inputs use the raised surface with a rule border and the accent focus ring; cards sit on the raised surface with a hairline border and no shadow; navigation is set in Plex Mono uppercase in secondary ink. The kicker rule, a short accent line before a kicker, is the one signature alias.
{{ALIAS_CRITERIA}}- Create an alias only when a component uses a role in a way two or more components share, or when the component needs a state the semantic tier lacks; otherwise use the semantic token directly.
{{ALIAS_NAMING_PATTERN}}- --va-<component>-<part>-<property>-<state>, e.g. --va-button-primary-bg-hover.
{{BUTTON_ALIASES}}- button-primary-bg: action-primary; button-primary-bg-hover: accent-ink; button-primary-text: surface-raised; button-radius: radius-0; button-label-font: font-mono.
{{INPUT_ALIASES}}- input-bg: surface-raised; input-border: border-rule; input-border-focus: focus; input-text: text-body; input-radius: radius-0.
{{CARD_ALIASES}}- card-bg: surface-raised; card-border: border-hairline; card-shadow: none; card-radius: radius-0; card-kicker-rule: accent.
{{NAVIGATION_ALIASES}}- nav-text: text-secondary; nav-text-active: text-primary; nav-font: font-mono uppercase letter-spaced; nav-indicator: accent.
{{08_Token_Source_And_Build_Pipeline}}- The single source is tokens.json in the tenant brand folder, which already records each colour's hex, CSS variable name, role and measurement evidence. Proposed: extend it to the three tiers in a token JSON format and build CSS custom properties, a TypeScript map and the brand-kit.json the console reads from it. Versions follow semantic versioning, with a major bump for any renamed or removed token. A build check fails if any stylesheet in Ben's surfaces contains a literal hex or pixel value outside the token file.
{{TOKEN_SOURCE_FORMAT}}- tenants/ben-niehues-iv/brand/tokens.json, extended to primitive, semantic and component groups with the existing role and evidence notes kept.
{{TRANSFORM_TOOLING}}- Proposed: a small node build script (or Style Dictionary) that emits CSS variables, a TS module and the console brand-kit.json from the one source.
{{PLATFORM_OUTPUTS}}- CSS custom properties (--va-*) for bennieiv.xyz and the card-market site; brand-kit.json for the tenant console; a TS map for React surfaces.
{{VERSIONING_SCHEME}}- Semantic versioning: patch for value corrections, minor for new tokens, major for renames or removals; the measured date stays in the file.
{{HARDCODE_CHECK}}- A prebuild check that greps Ben's stylesheets for hex colours, px sizes and radius values not coming from var(--va-*) and fails the build, mirroring the estate's no-hard-coded-styles rule.
{{09_Token_Usage_Rules}}- Components use semantic or component tokens, never primitives and never literals. A new token is added only when a real, recurring need exists that no current role covers, and the reason is written next to it. Exceptions are rare, time-limited and logged. The anti-patterns to catch are a second accent colour, rounded corners, shadows and IO orange appearing in Ben's own surfaces.
{{TIER_USAGE_RULES}}- Pages and components: semantic and component tokens only. Themes: override semantic tokens only. Primitives: referenced only by semantic tokens.
{{NEW_TOKEN_CRITERIA}}- Used in at least two places; not expressible by an existing role; passes contrast on its intended surface; approved by Ben as brand owner.
{{EXCEPTION_PROCESS}}- Proposed: a one-line exception comment naming the reason and an expiry date, reviewed at the monthly token check and removed or promoted to a token.
{{LINT_CHECKS}}- No literal hex; no px radius other than 0; no --io-* or --tk-* tokens in Ben's files; no primitive referenced from a component.
{{ANTI_PATTERNS}}- A second accent colour; rounded furniture; drop shadows; IO orange #ff9013 or #ff6b00 on Ben's brand surfaces; colour-named semantic tokens.
{{10_Token_Migration_Plan}}- Migration runs in three waves. Wave one moves the tenant console and registry to read the accent and theme from the one token source instead of repeated hex values. Wave two measures and tokenises type sizes and spacing on bennieiv.xyz. Wave three rebrands the card-market console from the IO design language to Ben's tokens, if he chooses to, which is a data change to the semantic map.
{{MIGRATION_WAVES}}- Wave 1: console theme, registry COLOR and brand-kit.json read tokens.json. Wave 2: measure and tokenise type and spacing on bennieiv.xyz. Wave 3 (optional): card-market console moves from IO tokens to --va-* tokens.
{{AUTOMATABLE_REPLACEMENTS}}- Exact hex matches of the 16 measured colours replaced with their var(--va-*) names; border-radius declarations replaced with the radius-0 token.
{{MANUAL_REVIEW_AREAS}}- Near-duplicates (#100E09 vs #1a1917; Radix tomato vs #c0431a); muted label contrast; any accent used as body text.
{{ENFORCEMENT_DATE}}- Proposed: hardcode check switched to failing after wave 1 is merged, targeted within 30 days of approval.
{{MIGRATION_OWNERS}}- Ben as brand owner approves values; the Intelligent Operations console team applies waves 1 and 3; Ben owns wave 2 on his own site.
{{11_Token_Coverage_Measures}}- Coverage is measured as the share of colour, size, spacing and radius declarations that read a token. Colour coverage on bennieiv.xyz is expected to be high already, since the site declares --va-* properties, while type and spacing coverage is unknown until measured. Proposed: report tokenised share, remaining literals, unused tokens and contrast failures monthly. Target: 100 percent colour and radius coverage on all three surfaces after wave 1 and zero AA contrast failures on body text.
{{TOKENISED_DECLARATION_SHARE}}- Baseline not measured; Target: 100 percent of colour and radius declarations tokenised after wave 1, type and spacing after wave 2.
{{REMAINING_HARDCODED_VALUES}}- Known today: #c0431a in registry.ts and tenant-themes.css; IO tokens in the card-market console by design.
{{UNUSED_TOKENS}}- Watch accent-line and the two status colours; remove only if unused for two quarterly reviews.
{{CONTRAST_FAILURES}}- To check: ink-300 #a8a399 on paper for small labels; Target: zero AA failures for body and link text.
{{MEASUREMENT_CADENCE}}- Monthly automated count in the build; quarterly manual contrast and near-duplicate review.
{{01_Question_Universe_Discovery}}- The question universe for Ben's program is what product, UX and digital-experience peers ask about the work he writes about, plus the entity questions people ask about him. It clusters around product architecture as a practice, research-led digital banking and platform migrations at credit unions, evidence and provenance in data products, and who Ben Niehues IV is. Questions are drawn from his own essays and Studio pages, the LinkedIn post plan LI-01 to LI-12, and the Miniflux feeds on banking, fintech and credit union trade press. The card work contributes provenance questions only, never questions about what a card is worth.
{{AWARENESS_QUESTIONS}}- What is product architecture; how is product architecture different from UX design; what does a UX team do during a digital banking platform migration; who is Ben Niehues IV.
{{EVALUATION_QUESTIONS}}- How do you research a digital banking migration before launch; how do you roll out a member insights playbook across departments; how do you know if a personalised email pilot worked against a control group.
{{DECISION_QUESTIONS}}- Who in Kansas City writes about product architecture in financial services; how do I contact Ben Niehues IV; where can I read his case studies.
{{POST_PURCHASE_QUESTIONS}}- Adapted for a personal brand: after reading, what does every number says what it is based on mean in practice; why is an asking price not a sale; why should one week of data not be called a trend.
{{QUESTION_SOURCES}}- Ben's essays and Studio pages on bennieiv.xyz; the playbook positions for LI-01 to LI-12; Miniflux categories Banking and fintech, Credit union trade press and Startland News; comments on his LinkedIn posts once published.
{{02_Answer_Opportunity_Assessment}}- The best opportunities are questions where Ben has first-hand, specific material that generic UX content lacks. Product architecture defined as the system someone has to live inside, research before a digital banking migration, and value basis as a rule for data products are all topics he can answer from his own work. Entity questions about Ben himself are the easiest to win because bennieiv.xyz is the canonical source. Broad questions like what is UX design are held by large publishers such as Nielsen Norman Group and are low priority.
{{TARGET_QUESTIONS}}- What is product architecture; who is Ben Niehues IV; how should a credit union research a digital banking migration; what does value basis mean in a data product; why is an asking price not a sale.
{{BUSINESS_VALUE}}- Answers that name Ben as the source build recognition with product and UX peers and lead to conversations via bennieiv.xyz/contact or LinkedIn; no revenue is attached.
{{CURRENT_ANSWER_HOLDER}}- Not audited yet; Proposed: record who AI answers and search features cite for each target question at week 0. Generic UX questions are likely held by large publishers such as Nielsen Norman Group and uxdesign.cc.
{{ANSWER_FORMAT_SHOWN}}- Proposed audit: note whether each target question returns a paragraph definition, a list or a named-person answer, and match that format.
{{WIN_LIKELIHOOD}}- High for entity questions about Ben; medium for product architecture and value-basis questions answered in his own voice; low for broad UX definitions.
{{03_Answer_Architecture}}- Each question cluster gets one canonical page on bennieiv.xyz, with LinkedIn posts pointing back to it. Product architecture is answered on a Notebook essay built from LI-01; research-led digital banking on a Studio case page, built on his LinkedIn-profile results and credited to CommunityAmerica; evidence and provenance on a Notebook essay built from LI-09 and LI-10; and the entity answer on the about page. The site's Built for Agents version carries the same answers in agent-readable form. Short FAQ blocks sit at the foot of each canonical page rather than on a separate FAQ page.
{{QUESTION_CLUSTERS}}- Product architecture; research-led digital banking; evidence and provenance; craft and restraint; about Ben.
{{CANONICAL_PAGES}}- bennieiv.xyz Notebook essay on product architecture; Studio case page on digital banking migration research; Notebook essay on value basis and provenance; Studio page for Card Market as private research; about page.
{{FAQ_PLACEMENTS}}- Three to five question-and-answer pairs at the foot of each canonical essay and Studio page; an entity FAQ on the about page.
{{INTERNAL_LINK_PLAN}}- Every LinkedIn post links to its canonical page; each essay links to the related Studio case; every page links to the about page and /contact with the line If you're building something worth inhabiting, or just curious, reach out.
{{04_Answer_Writing_Rules}}- Every answer section starts with the question as its heading and answers it in the first two sentences, in Ben's first-person, plain voice. Answers are short, then supported by one concrete example from his work, attributed to CommunityAmerica where it is team work. Numbers appear only with their basis, and estimates or unconfirmed dates are labelled as such. No hype, no exclamation marks and no claims beyond what the sources support.
{{HEADING_RULE}}- Use the question as the heading, in the words a peer would type, e.g. What is product architecture?
{{ANSWER_FIRST_RULE}}- Answer in the first one or two sentences before any story; for example, Product architecture is shaping the system someone has to live inside before designing screens or features.
{{ANSWER_LENGTH_RULE}}- 40 to 60 words for the direct answer; supporting detail up to about 150 words.
{{FORMAT_RULES}}- Paragraph for definitions; numbered steps for how-to questions; a short list for criteria; no tables in answer blocks.
{{SUPPORTING_DETAIL_RULE}}- Add one example from Ben's own work with its source and, for CACU work, the employer attribution; never add card values or unconfirmed awards.
{{05_Direct_Answer_Drafts}}- Draft answers are written for the five target questions in Ben's voice. What is product architecture: before a wireframe or a feature, there is a system someone has to live inside, and product architecture is shaping that system to be simple, useful and worth trusting. What is value basis: every number says what it is based on, whether a guide value at grade, the median of sold comps or the median ask, and an ask is never presented as a sale. Who is Ben Niehues IV: a product architect and UX leader in Kansas City who leads user experience at CommunityAmerica Credit Union and started there as a front-end developer.
{{QUESTION_HEADINGS}}- What is product architecture?; Who is Ben Niehues IV?; How should a credit union research a digital banking migration?; What does value basis mean?; Why is an asking price not a sale?
{{ANSWER_BLOCKS}}- Product architecture is shaping the system someone has to live inside before designing screens or features, so it is simple, useful and worth trusting. Value basis is the evidence a number rests on: a guide value at the grade, the median of sold comps or the median ask, stated every time.
{{SUPPORTING_DETAIL}}- For migration research: CACU's Q2 digital banking migration was preceded by four research studies (confirm dates; the timeline is unreleased CACU work and needs the employer's OK). For provenance: Ben's private card console shows one week on file, none priced yet, and waits for two priced weeks before showing a trend.
{{SOURCE_FACTS}}- LinkedIn profile summary and experience (2026); card-market worker README; site/data/market.json dated 2026-09-22; brand tokens measured 2026-09-22.
{{06_Structured_Data_Plan}}- Structured data makes Ben one consistent entity across his site and profiles. The about page carries Person markup with his name, job title, employer, location and sameAs links to LinkedIn, Instagram and X; essays carry Article markup with Ben as author; Studio pages carry Article markup with the case sections; FAQ blocks carry FAQPage markup. Card Market pages, if any, carry no price or offer markup, because nothing is sold and values stay private. Markup is validated before each page ships.
{{SCHEMA_TYPES_BY_TEMPLATE}}- About: Person and ProfilePage. Notebook essay: Article (or BlogPosting). Studio case page: Article. FAQ blocks: FAQPage. Site: WebSite.
{{POPULATED_PROPERTIES}}- Person: name Ben Niehues IV, jobTitle Manager, User Experience, worksFor CommunityAmerica Credit Union, address Kansas City, Missouri, alumniOf Kansas State University, sameAs linkedin.com/in/bennieiv, instagram.com/bennieiv. Article: headline, author, datePublished, dateModified.
{{ENTITY_CONSISTENCY}}- Use Ben Niehues IV everywhere (not Ben Niehues alone), the same job title as LinkedIn, and bennieiv.xyz as the canonical URL; the site sets the name in Plex Mono rather than as a logo.
{{VALIDATION_STATUS}}- Not yet validated; Proposed: run each template through a structured data validator before publishing and record pass or fail.
{{07_Voice_and_Conversational_Fit}}- Spoken and conversational questions are phrased the way a peer would ask an assistant, and Ben's answers already suit that: short, first-person and plain. Each canonical page gets a one-sentence spoken answer that can stand alone. Local details are limited to Kansas City, Missouri, since there is no public business address. There is no business listing to maintain, because this is a personal brand rather than a storefront.
{{CONVERSATIONAL_VARIANTS}}- Who is the product architect at CommunityAmerica Credit Union; what does product architecture mean; how do you tell if a price is a sale or an ask; who writes about UX in Kansas City fintech.
{{SPOKEN_ANSWERS}}- Ben Niehues IV is a product architect and UX leader in Kansas City who leads user experience at CommunityAmerica Credit Union. Product architecture is shaping the system someone has to live inside before designing any screen.
{{LOCAL_DETAILS}}- Kansas City, Missouri only; no street address, phone or hours, because none are public for a personal brand.
{{BUSINESS_PROFILE_CHECKS}}- No business listing applies; instead check that LinkedIn, Instagram and X profiles use the same name, title and link to bennieiv.xyz.
{{08_Answer_Readiness_Audit}}- Readiness is audited per canonical page before and after the first six weeks of posting. The audit checks that each page leads with its answer, matches the format answer engines show, carries valid markup, and is crawlable, including the Built for Agents version. The tenant site ben-niehues-iv.intelligentoperations.ai is not built and returns 404, so no answers should point there. Required fixes are listed with an owner and are not scored until the week-0 audit is done.
{{STRUCTURE_SCORE}}- Not yet scored; Proposed: score each page 0 to 3 on question heading, answer-first paragraph and supporting example.
{{FORMAT_MATCH}}- To be recorded at the week-0 audit against what answer engines show for each target question.
{{MARKUP_VALIDITY}}- Not yet validated; Person, Article and FAQPage markup to be added and tested.
{{INDEXABILITY_CHECK}}- Confirm bennieiv.xyz pages and the agent-readable version are indexable; confirm the private console and /login are excluded; confirm no link points to the unbuilt tenant subdomain.
{{REQUIRED_FIXES}}- Add Person markup to the about page; add FAQ blocks to the three canonical essays; add sameAs links; add a headshot (none on file); build CACU case pages from his LinkedIn-profile results, credited to CACU, and get the employer's OK for anything new.
{{09_Answer_Visibility_Measures}}- Visibility is measured with a small, repeatable check rather than traffic tools, because site analytics are not on record. Each month, the five target questions are asked in the main answer engines and search, and the result records whether Ben or bennieiv.xyz is named or cited. Impressions and clicks are added once Search Console is connected. Conversations started through /contact or LinkedIn messages are the outcome that matters.
{{ANSWER_OWNERSHIP_RATE}}- Baseline not measured; Target: Ben cited for both entity questions within 60 days and for at least one of the three topic questions within 90 days.
{{ANSWER_IMPRESSIONS}}- Not available; Proposed: connect Google Search Console for bennieiv.xyz and record a week-0 baseline.
{{ANSWER_CLICKS}}- Not available until Search Console is connected; baseline TBD.
{{BRANDED_SEARCH_LIFT}}- Proposed: track impressions for Ben Niehues IV and bennieiv from the week-0 baseline over the six-week posting run.
{{ANSWER_PAGE_LEADS}}- Conversations started via bennieiv.xyz/contact or LinkedIn messages that name a canonical page; baseline 0 tracked, counted manually each Friday.
{{10_Answer_Refresh_Cycle}}- Answers are refreshed monthly alongside the Friday signals review. The owner checks whether Ben is still cited, diagnoses any loss, updates facts that have changed and adds new questions from comments and feeds. Dated facts, such as the Unify launch in August 2026 and the CACU migration in Q4 2026, are reviewed first because they move from future to past tense. Card Market answers are updated as sources connect, without ever adding values.
{{OWNERSHIP_CHECK}}- Monthly: ask each target question in two answer engines and search, and record whether Ben or bennieiv.xyz is cited.
{{LOSS_DIAGNOSIS}}- If a citation is lost, check whether the answer still leads the page, whether the fact is out of date, and whether a newer, more specific source now answers it.
{{ANSWER_UPDATES}}- Update dates and tense on migration content; update Card Market status (sources connected, weeks on file) without values; refresh examples when his LinkedIn profile or CACU's releases change.
{{NEW_QUESTION_INTAKE}}- Add questions from LinkedIn comments, /contact messages and the Friday signals review, capped at two new questions a month.
{{REFRESH_FREQUENCY}}- Monthly check; quarterly rewrite of any page that has not been cited after two checks.
{{01_Reporting_Scope_and_Goals}}- This report covers the first six weeks of Ben's LinkedIn thought-leadership program, from LI-01 on 29 September 2026 to LI-12 on 5 November 2026. It is written before results exist, so it sets the scope, baselines and targets the report will be read against. The goal is to establish Ben as a recognisable voice on product architecture, research-led digital banking and evidence in data products among product and UX peers, and to start conversations through bennieiv.xyz and LinkedIn. There is no paid media and no revenue goal.
{{REPORTING_PERIOD}}- 29 September 2026 to 9 November 2026 (six weeks), with a week-0 baseline captured on 29 September.
{{CHANNELS_IN_SCOPE}}- LinkedIn personal profile (primary); bennieiv.xyz Notebook and Studio pages (destination); Instagram @bennieiv (secondary, baseline only).
{{MARKETING_GOALS}}- Publish all 12 planned posts on schedule; grow a measurable audience of product and UX peers; start conversations with peers; keep every public number grounded in his LinkedIn profile or his own project files.
{{PERIOD_TARGETS}}- Proposed: 12 of 12 posts published on their Tuesday and Thursday slots; 12 of 12 drafts approved on Mondays; follower growth and profile views measured against a week-0 baseline; at least one peer conversation started per two weeks.
{{REPORT_AUDIENCE}}- Ben, as author and sole stakeholder, and the Intelligent Operations team running the drafting and signals pipeline.
{{02_Metric_Hierarchy}}- The outcome metric is conversations started with product, UX and digital-experience peers through LinkedIn messages or bennieiv.xyz/contact. Beneath it sit funnel metrics: impressions, engagement, profile views, follower growth and clicks to bennieiv.xyz. Channel metrics track the program's own discipline: posts published on schedule and drafts approved on time. Expected conversion rates are not set, because there is no baseline yet; the first six weeks exist to establish them.
{{OUTCOME_METRICS}}- Peer conversations started (LinkedIn messages and /contact submissions naming a post or page); inbound speaking or collaboration requests, counted but not targeted.
{{FUNNEL_METRICS}}- Post impressions; reactions and comments per post; profile views; LinkedIn followers; clicks to bennieiv.xyz; bennieiv.xyz sessions once analytics are connected.
{{CHANNEL_METRICS}}- Posts published on schedule (of 12); drafts approved by Monday (of 12); Wednesday signal comments made (target two a week); Instagram followers (baseline 2,431 on 2026-09-25).
{{STAGE_DEFINITIONS}}- Reach: impressions. Engage: reactions, comments, reposts. Visit: profile view or click to bennieiv.xyz. Converse: a message or /contact submission that starts a conversation.
{{EXPECTED_CONVERSION_RATES}}- Not set; no baseline exists. Proposed: derive rates from weeks 1 to 6 and set targets for the next period.
{{03_Attribution_and_Data_Notes}}- Attribution is simple and manual, because there is one author, no paid media and no CRM. A conversation is credited to the post or page the person mentions, or to the most recent post before it if none is named. LinkedIn's own post analytics are the source for reach and engagement, and follower counts are recorded by hand each Friday. The biggest gaps are the missing LinkedIn follower baseline and the absence of site analytics on bennieiv.xyz.
{{ATTRIBUTION_MODEL}}- Self-reported first, then last-touch: credit the post or page the person names, else the most recent post published before the conversation.
{{LOOKBACK_WINDOWS}}- 14 days from a post's publish date for engagement and conversations credited to it.
{{PLATFORM_CRM_RECONCILIATION}}- No CRM; a simple log of conversations (date, channel, post credited) kept by Ben and checked against LinkedIn messages each Friday.
{{TRACKING_GAPS}}- LinkedIn follower count not on record at start (capture at week 0); no analytics on bennieiv.xyz; no UTM convention yet; Instagram and X are not in the posting plan.
{{04_Funnel_Performance_Summary}}- No funnel results exist yet; this section records baselines and the targets they will be measured against. Reach, engagement and follower figures start from a week-0 capture on 29 September 2026, and conversations start from zero tracked. Target variance and period-over-period change become reportable after week 2 and again at week 6. The stage expected to be weakest is Visit, because bennieiv.xyz has no analytics and clicks cannot yet be confirmed.
{{STAGE_VOLUMES}}- Baseline: impressions, engagement and profile views to be captured at week 0; conversations 0 tracked; Instagram followers 2,431 (2026-09-25).
{{STAGE_CONVERSION}}- Not yet measurable; Proposed: report engagement per impression and conversations per 1,000 impressions from week 2.
{{TARGET_VARIANCE}}- To be reported at week 6 against the targets of 12 of 12 posts on schedule and at least three conversations started over the period.
{{PRIOR_PERIOD_CHANGE}}- None; this is the first reporting period.
{{WEAKEST_STAGE}}- Expected: Visit, because clicks to bennieiv.xyz cannot be confirmed without site analytics.
{{05_Channel_Performance_Breakdown}}- The program is organic only, so there is no media spend, cost per acquisition or return on spend to report. LinkedIn is the only channel with scheduled output in this period; bennieiv.xyz is the destination and Instagram is tracked only as a baseline. Conversions are counted as conversations started, with no pipeline value attached. The cost of the program is Ben's time and the Intelligent Operations drafting pipeline, which this report does not price.
{{CHANNEL_SPEND}}- No paid media in scope; spend $0 planned on every channel.
{{CHANNEL_CONVERSIONS}}- LinkedIn: conversations started, baseline 0 tracked; bennieiv.xyz: /contact submissions, baseline 0 tracked.
{{ATTRIBUTED_PIPELINE}}- Not applicable; the program has no sales pipeline or revenue goal.
{{COST_PER_ACQUISITION}}- Not applicable; no paid spend.
{{RETURN_ON_SPEND}}- Not applicable; no paid spend.
{{06_Campaign_Results_Review}}- The campaign is the 12-post series in two runs: LI-01 to LI-08 in weeks 1 to 4 and LI-09 to LI-12 in weeks 5 and 6. Its objective is to test which of the four owned topics, product architecture, research-led digital banking, evidence and provenance, and craft and restraint, earns the most engaged peer response. Results will be reported per post at week 6; no results are claimed here. Lessons so far are process ones, such as crediting CommunityAmerica and the team in every post that cites team results.
{{CAMPAIGN_OBJECTIVES}}- Publish 12 grounded posts on schedule; identify the strongest of the four topics by comments and conversations; establish baselines for the next period.
{{CAMPAIGN_RESULTS}}- Not yet available; results for LI-01 to LI-12 will be reported at week 6 against the week-0 baseline.
{{TOP_PERFORMING_CREATIVE}}- Not yet known; Proposed: rank posts by comments from product and UX peers rather than by reactions, and compare hook types (position statement vs result vs admission of limits).
{{AUDIENCE_PERFORMANCE}}- Proposed: tag each commenter as product or UX peer, credit union or financial services, Kansas City tech community or other, and report the mix per topic.
{{LESSONS_LEARNED}}- Process lessons to date: LI-02 to LI-06 cite CACU work from his LinkedIn profile and credit the team; awards and press claims need verification; card values must stay out of every post.
{{07_Content_and_Engagement_Signals}}- Leading indicators for this program are comments from peers, profile views and saves, because they precede conversations. Trends can only be read after at least two weeks of posting, matching the program's own rule that one data point is not a trend. Top content will be named at week 6 by comments and conversations credited. Assisted conversions are conversations where a person mentions more than one post.
{{LEADING_INDICATORS}}- Comments from product and UX peers per post; profile views per week; follower change per week; clicks to bennieiv.xyz.
{{INDICATOR_TRENDS}}- Not yet readable; first trend read after two weeks of posts, on 10 October 2026.
{{TOP_CONTENT_PIECES}}- To be named at week 6; candidates to watch are LI-01 (product architecture before pixels) and LI-09 (every number says what it is based on), which carry the program's core positions.
{{ASSISTED_CONVERSIONS}}- Conversations where the person mentions two or more posts or pages; counted from the Friday log.
{{08_Performance_Diagnosis}}- Diagnosis at this stage is about risks to the plan rather than causes of results. The controllable factors are on-time approval, grounded claims and consistent Tuesday and Thursday publishing; the main external factors are LinkedIn's distribution and the timing of CommunityAmerica's platform migration. Tracking gaps, especially no site analytics and no follower baseline, could make real progress invisible. The report will separate tracking effects from performance effects when results arrive.
{{PRIMARY_CAUSES}}- Not yet diagnosable; the report will attribute results to topic, hook type and timing once six weeks of data exist.
{{CONTROLLABLE_FACTORS}}- Monday approval discipline; publishing on schedule; answering comments within a day; Wednesday comments on two signals; linking each post to a canonical page.
{{EXTERNAL_FACTORS}}- LinkedIn feed distribution; CACU's release timing for new work; news cycle in banking and credit union trade press; the Unify and CACU migration calendar.
{{TRACKING_EFFECTS}}- Missing follower baseline and site analytics could understate growth; manual conversation logging could miss messages not tied to a post.
{{09_Next_Period_Allocation}}- Allocation for the next period is effort, not budget, since there is no paid media. Proposed: shift posting weight toward whichever of the four topics earns the most peer comments and conversations, and turn the best two posts into Notebook essays or Studio pages on bennieiv.xyz. Planned tests compare hook types and posting days. The expected effect is more visits to canonical pages and a measurable conversation rate for the following period.
{{BUDGET_SHIFTS}}- None; no paid budget is planned for the next period.
{{EFFORT_SHIFTS}}- Proposed: move one of the two weekly posts to the strongest topic; convert the top two posts into long-form pages; keep Wednesday signal comments.
{{PLANNED_TESTS}}- Proposed: hook type (position statement vs concrete result vs stated limit) across four posts each; Tuesday vs Thursday performance; a post with a link in the first comment vs in the body.
{{EXPECTED_FUNNEL_EFFECT}}- Target: more clicks to bennieiv.xyz from long-form conversions and at least one conversation every two weeks; to be confirmed once analytics exist.
{{10_Marketing_Report_Summary}}- The first period of Ben's program is set up to measure, not to claim. Its goal is 12 grounded posts on schedule, a week-0 baseline for LinkedIn and bennieiv.xyz, and the first peer conversations through /contact or LinkedIn. LinkedIn is the decisive channel, with bennieiv.xyz as the destination and no paid media. The next period shifts effort to the strongest topic and turns the best posts into canonical pages, once the tracking gaps are closed.
{{GOAL_RESULTS_SUMMARY}}- Results pending; targets are 12 of 12 posts on schedule, a captured baseline and at least three conversations over six weeks.
{{DECISIVE_CHANNEL}}- LinkedIn personal profile (linkedin.com/in/bennieiv), with bennieiv.xyz as the destination.
{{DIAGNOSIS_SUMMARY}}- Main risks are tracking gaps (no follower baseline, no site analytics) and keeping new CACU material within the employer's OK, not content supply.
{{ALLOCATION_CHANGE}}- Proposed: more effort on the strongest topic and on long-form pages; no paid spend.
Screens were captured from Ben Niehues IV’s own site and tenant console on 2026-09-30, with personal data blurred. Variable values are the structured outputs of its prompt libraries, marked Provisional in its console until the client confirms them.