Building Nimbus Publicly

Thirty days ago, we made the Nimbus roadmap public. Anyone could see what we were building, what was next, what was planned for later, and what had just shipped.

We expected three things: a small bump in customer trust, some helpful feedback, and maybe a few new feature requests we hadn't considered.

We got something different.

What actually happened

In 30 days:

• 47 feature suggestions from customers (we'd had maybe 8 in the previous 30 days)

• 12 of those suggestions made it onto the roadmap

• 3 of them shipped within the same 30-day window

• 4 instances of customers spontaneously promoting Nimbus on social media specifically because of the public roadmap

• 1 unexpected feature pivot

The pivot is the part I want to talk about.

The pivot

We had a feature on the "Later" column: AI agent marketplace. We thought it was a Q1 2027 thing — a long-term vision, not urgent, not specifically requested.

Two days after making the roadmap public, we got 8 messages from customers asking when it was shipping. By week two, that number was 23. By week four, AI agent marketplace was the single most-requested feature on the roadmap.

Until then, we'd been heads-down building "real-time collaboration" as our next big push. After seeing the public response, we paused real-time collaboration mid-sprint and started prototyping the agent marketplace.

Real-time collaboration is still on the roadmap. It moved from Q3 2026 to Q4 2026. Agent marketplace moved from 2027 to Q4 2026.

Without the public roadmap, we would have shipped the wrong thing first.

The cost of being wrong

The thing nobody talks about with public roadmaps is: you have to be okay being wrong, publicly.

Two of our "Now" items slipped past their original dates. We had to mark them moved. Customers saw the dates change. One particularly engaged customer sent us a screenshot of the timeline shift, asking if everything was okay.

The choice was: hide the slips and keep our credibility, or own them publicly and ask for trust.

We chose the second option. The result was more empathy from customers than we expected. Several said the date slip actually increased their trust because we were honest about it.

Hiding the slips would have meant they'd find out anyway — through delayed deliveries or vague excuses. Owning them publicly meant we got to control the story.

What I'd tell other founders considering this

1. Don't go from "no roadmap" to "public roadmap" overnight. Get the team aligned on what's on it first. Internal disagreement is fine. Public disagreement is confusing.

2. Decide what "public" means. We share titles, descriptions, and rough timing. We don't share priorities, internal dependencies, or political reasoning. Both choices are defensible.

3. Update it weekly, not "when there's news." Customers check more often than you think. Stale roadmaps lose trust faster than honest delays.

4. Be willing to be wrong about timing. If you're not going to update the dates, don't publish them. Vague is better than wrong-and-hidden.

5. Listen, but don't let the loudest customers steer the roadmap. We do not auto-promote items based on request count. The roadmap is informed by customers, not run by them.

The compounding effect

The unexpected benefit of the public roadmap: prospects started referencing it during sales calls.

"I saw your roadmap. I really like that you're shipping X." We heard this on 3 of the 5 enterprise calls last week. Two of those prospects closed.

That doesn't happen with internal roadmaps. The public roadmap turned a planning document into a sales asset.

— Ethan Carter