2026-04-04 - DataHub One-Post Prototype Second Pass

2026-04-04 - DataHub One-Post Prototype Second Pass

Summary

This is a second-pass prototype for the same DataHub update used in the first one-post experiment.

The purpose of this run was to test whether a stronger brief structure would produce better output.

Instead of starting mainly from the product update, this pass explicitly started from:

  • current strategic priority
  • reader pain
  • core message
  • client outcome
  • value-first writing rules

Result:

  • the output was stronger than the first pass
  • the posts felt less like feature updates and more like useful content
  • the strongest version better reflected what the marketing lead wanted

Why This Second Pass Was Run

Feedback from the marketing lead suggested that the original drafts were usable, but still too close to product-first framing.

The revised direction was:

  • lead with a sharper hook
  • write for a real reader pain
  • use MINTO structure
  • make the client outcome visible
  • remove triviality and vague product language

Exact Second-Pass Brief Used

# Enhanced Prototype Brief: DataHub LinkedIn Post

## Goal

Create one strong, ready-to-publish LinkedIn post for DataHub / Datopian based on a real internal update.

The post should be:
- informative
- concrete
- engaging
- practical, not hypey
- close to ready to publish with minimal edits
- deliver value to the reader rather than merely announce a feature

## Product

DataHub

## Current Strategic Priority

Make DataHub the go-to place for data.

More specifically, reinforce that DataHub is not just a place where datasets are stored. It is a place where high-quality data can be found, explored, understood, and used.

## Audience

- data engineers
- data managers
- government open data teams
- research institutions
- enterprise data teams

## Reader Pain

- the data exists, but it is hard to find
- the dataset is published, but still hard to understand or use
- downstream users still need manual work to explore, visualize, or reuse the data
- "publishing" often means uploading files, not creating something genuinely usable

## Core Message

Better data publishing means reducing the work required after publishing.

## Client Outcome

People should be able to explore, understand, share, and reuse published data with less manual interpretation and less dependence on someone else turning raw files into something usable.

## Raw Source Update

Source channel: Discord `#whats-cooking`
Date: 2026-03-20
Author: anuveyatsu

Raw messages:

1. We now support Observable Plot for visualizations:
https://datahub.io/ai/epoch-data-on-ai-models

2. We also have individual view pages now which makes it easy to embed views:
https://datahub.io/ai/epoch-data-on-ai-models/v/0

3. Added a new visualization here:
https://datahub.io/core/eu-emissions-trading-system

Context note:
A follow-up message saying “Ignore it please, there is no data for 2024” is not part of the public post angle and should be ignored.

## Desired Angle

Focus on practical value:
- better data publishing
- easier sharing and embedding of views
- more useful dataset exploration
- publishing data as something usable and explorable, not just a file dump

Reframe the product update around the outcome the reader experiences:

- less manual work after data is published
- easier exploration and reuse
- easier sharing and embedding of views
- less dependency on someone else to turn raw files into something usable

## Tone

Use the DataHub / Datopian tone:
- clear
- practical
- specific
- data-geeky in a good way
- no hype
- no inflated claims
- make the value legible quickly
- deadpan or matter-of-fact

## Structure

Use MINTO Pyramid:
1. lead with the conclusion or insight
2. explain why it matters
3. ground it in the concrete update and examples
4. put links at the end

Use short paragraphs and avoid feature-release-note phrasing.

## Channel

LinkedIn only for this prototype.

## Output Request

Write 3 LinkedIn post options:
1. safest
2. strongest
3. most engaging

Constraints:
- concise, but with enough context to be useful
- no hashtags unless truly necessary
- no thread or multi-post structure
- no strategy explanation
- no extra questions unless blocked
- each option should feel ready to publish
- each option must deliver value, not just describe what shipped

## Context URLs And Sources To Use For Enrichment

Use these first before making assumptions:

1. Product / stream context in repo:
- `volume-and-velocity/context/product-streams.md`
- `volume-and-velocity/context/voice-and-tone.md`
- `volume-and-velocity/context/channel-guidance.md`
- `volume-and-velocity/context/strategic-priority-and-reader-pain.md`

2. Live URLs from the update:
- https://datahub.io/ai/epoch-data-on-ai-models
- https://datahub.io/ai/epoch-data-on-ai-models/v/0
- https://datahub.io/core/eu-emissions-trading-system

3. Related product context if needed:
- `offers/datahub.md`
- `north-star.md`
- `dashboard.md`

## Important Constraints

- Do not invent technical details not supported by the source or linked pages.
- Prefer one strong practical angle over trying to mention everything.
- Treat this as a real shipped improvement, not as a vague product announcement.
- Avoid generic hooks, rhetorical questions, hype, and engagement bait.
- Make the reader pain visible.
- Make every claimed benefit concrete and credible.

Outputs Generated

Safest

Publishing a dataset is not the same as making it usable.

A lot of data work still breaks at that point: the file is online, but anyone who wants to understand it, share it, or reuse it has to do extra work first.

That is what we are trying to reduce on DataHub.

We’ve added Observable Plot visualizations and individual view pages, so published datasets are easier to explore, share, and embed without another translation step.

Examples:
https://datahub.io/ai/epoch-data-on-ai-models
https://datahub.io/ai/epoch-data-on-ai-models/v/0
https://datahub.io/core/eu-emissions-trading-system

Better data publishing is really about reducing the work that starts after publishing.

Strongest

Selected as the best option from the second pass.

A lot of published data is technically available and practically unusable.

The file is there. The reader still has to inspect it, turn it into something visual, and explain it to someone else before it becomes useful.

We’ve been working on that gap in DataHub.

Datasets now have Observable Plot visualizations and individual view pages, which makes them easier to explore, share, and embed as actual data views, not just raw files.

See it here:
https://datahub.io/ai/epoch-data-on-ai-models
https://datahub.io/ai/epoch-data-on-ai-models/v/0
https://datahub.io/core/eu-emissions-trading-system

If published data still creates downstream work, it is not really published well yet.

Most Engaging

The hidden cost of publishing data is everything people have to do after the link is live.

They open the dataset, then someone still has to make it readable, visual, or shareable before it can be used in a real workflow.

That is the problem we’ve been trying to reduce on DataHub.

With Observable Plot visualizations and individual view pages, datasets are easier to explore directly and easier to share in a form other people can actually work with.

A few examples:
https://datahub.io/ai/epoch-data-on-ai-models
https://datahub.io/ai/epoch-data-on-ai-models/v/0
https://datahub.io/core/eu-emissions-trading-system

Usable data should not require a second layer of manual interpretation.

Why This Pass Is Better

The improvement did not come mainly from rewriting the wording.

The improvement came from changing what the AI was asked to optimize for:

  • reader pain instead of product description
  • client outcome instead of feature list
  • strategic narrative instead of isolated update
  • value delivered instead of "what shipped"

Takeaway

This suggests that one of the highest-leverage improvements for Volume and Velocity is not a brand new drafting system.

It is a better brief and better context.

Edit this page
Built with LogoFlowershow