For Product

Rough for Product teams

How Product teams use Rough to protect the roadmap, learn from real demand, and absorb the long tail without burning down focus.

The problem you keep hitting

There's the roadmap. And then there's everything else. The customer who asked for a new export format. The pre-sales request you couldn't promise on. The internal team that needed a different view of the same data. None of it is unreasonable. None of it is bad. It just isn't what you're supposed to be working on.

The cost of getting that wrong is real. Saying yes too often means the roadmap stalls. Saying no too often means deals slip and customers quietly drift. Most product teams end up oscillating between the two.

What changes with Rough

Rough lets you absorb the long tail without putting it on the roadmap. Sales reps, customer success engineers and customers themselves can build the things they need on top of your product, inside Surfaces you control. You stay focused on the work that has to come from your team.

Practically, this gives you three things:

• A pressure release. The "can it do X?" requests stop being a queue you have to drain. Most of them get solved at the edge, where they originated.
• Real demand signal. What gets built in Rough — and what gets used — tells you which extensions are common enough to deserve first-class support. You're not guessing what to promote into the core product; you can see what people are already converging on.
• A safer way to prototype. If you're not sure whether an idea is worth full engineering investment, build it as a Rough Feature first. If it survives contact with users, promote it. If it doesn't, no harm done.

How to think about it

A useful frame: Rough is for things that don't yet deserve a roadmap conversation. The things that do still belong with your product team. The trick is being honest about which is which.

The other useful frame: Rough is a customer feedback tool that happens to produce working software. Every Feature is a vote about what your product is missing.

Day-to-day

• Use the Rough management dashboard to see what's being built and by whom.
• Promote Features that get repeated use into proper roadmap items, when the demand is clear.
• Retire or rethink Features that nobody uses — same as you would any other product surface.
• Talk to your Sales and CS teams about what they're building. The ones doing the most building usually have the clearest picture of where the product is weakest.

Where to go next

• What a Rough Feature actually is.
• How RAF works — for when an engineer asks.
• For engineering — what your engineers will need to do.