↗ Options, Not Roadmaps

Ryan Singer talked about how they (don't) deal with roadmaps on the Signal v. Noise blog.

In short: roadmaps are a bad idea because they can create uncertainty, false expectations, and guilt. My favorite argument against long term roadmaps is the uncertainty.

We don’t have a crystal ball. Say we have features A, B, and C we want to build. We don’t know if A is going to work out as planned, and what that would mean for B. We don’t know if we’ll have a eureka in the bathtub one day, and new idea X will suddenly feel much more important than B or C. Or we might start building out B, only to realize that it’s not what we want or it’s harder than we thought and want to bail on it.

That means no explicit promises and no implicit promises either. A list on the wall or in some official strategy document is an implicit promise: “this is what we’re doing next.“ There is no official list of what we’re doing next anywhere in the company.

I strongly believe in not writing down big ideas for a product, because if it really is a good idea it will resurface, preferably multiple times.

That said, client projects are different beasts than homegrown software. Clients expect roadmaps, and there's less wiggling room for features. You can't really skip expectations, clients expect them. Mapping client projects is a different puzzle to solve.