Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.