📖 Book
✓ Link checked
Free
Intermediate
Why we picked it
Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.
From
Basecamp / 37signals
by Ryan Singer
free online book
- Work in short cycles with a cool-down between them.
- Fix time, vary scope, use 'appetites,' not estimates.
- Make bets, not plans; no runaway backlog.
Open
basecamp.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
A short, plain chapter that makes the case for keeping money and dates fixed while trimming features. It is the cleanest argument for why a milestone should be a smaller, real thing you can see, not a promise to finish everything at once. Read it before you write your payment schedule so you frame milestones around shippable slices.
From
37signals
by 37signals
- Launching on time, on budget, and on full scope almost never happens.
- Hold time and budget steady, then pull back scope to fit.
- A smaller thing that works beats a bigger thing that half works.
Open
basecamp.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
A runaway roadmap is usually a list of every decent idea, and this piece is the antidote. Build half a product that is great rather than a full product that is mediocre, then cut the feature list in half again. For an early founder tempted to plan quarters of features, it reframes cutting as the point, not the compromise.
From
Basecamp (37signals)
by Jason Fried, David Heinemeier Hansson
~3 min read
- Ship half a product, not a half done product
- Cut your feature list, then cut it again
- Real usage, not a plan, tells you what to build next
Open
basecamp.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This is the direct answer to the pressure problem in the question: if a public roadmap scares you because of dates you cannot hit, stop putting dates on it. Bastow invented the Now, Next, Later format precisely because fixed timelines create false promises, and she walks through how to communicate direction and confidence without committing to a calendar. It is the format most public roadmaps quietly adopt for exactly this reason.
From
prodpad.com
by Janna Bastow
- Drop dates and group work into Now, Next, and Later so the further out something is, the less certain you are seen to be about it.
- The format signals priority and direction without a deadline, which is what protects you from over-promising to early users.
- The roadmap's real value is the conversations it starts, not the artifact itself, so treat it as a way to talk with users, not a contract.
Open
prodpad.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A clear tour of roadmap styles that shows exactly why a feature by date roadmap sets you up to over promise. Torres contrasts feature roadmaps with theme and Now-Next-Later roadmaps and explains what each hides or reveals about uncertainty. Read it to choose a format on purpose instead of defaulting to a timeline because it looks organized.
From
Product Talk
by Teresa Torres
~15 min read
- Feature and date roadmaps pretend to a certainty you do not have
- Theme based roadmaps commit to problems, not specific features
- Pick the roadmap style that matches how much you actually know
Open
producttalk.org →
✍️ Essay
✓ Link checked
Free
Advanced
Why we picked it
Cagan makes the sharpest version of the argument: replace a list of features with a small set of outcomes you are trying to move, then let the team find the features. It is the strongest case for a roadmap as direction rather than a shipping contract. Read it when your roadmap has quietly become a promise list to stakeholders.
From
Silicon Valley Product Group
by Marty Cagan
~10 min read
- State the outcome you want, not the feature you assume will get it
- Most roadmap features never deliver their intended result
- Commit to a few high integrity dates, keep the rest flexible
Open
svpg.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
Ries gives you a working method for reading weak signals instead of guessing: build a small test, measure how real people respond, and learn fast enough to change course before a year is gone. Its most useful idea for this question is validated learning and the pivot-or-persevere call, a concrete way to decide whether an idea is worth continuing. Read it as a discipline for catching a dead-end early, not as a growth-hacking manual.
From
theleanstartup.com
by Eric Ries
~330 pages
- Validated learning means progress is measured by what you have actually confirmed with customers, not by how much you have built.
- The build-measure-learn loop is meant to shorten the time between an assumption and honest feedback on it.
- Pivot or persevere is a scheduled, evidence-based decision, so you are not drifting on an idea by default.
Open
theleanstartup.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A roadmap that lists solutions ages fast, while a roadmap of problems stays useful. Intercom shows how to write a tight problem statement (the outcome the customer wants, why, and what hurts today) so each cycle starts from a problem rather than a pre-chosen feature. It is the habit that keeps your roadmap a direction instead of a spec.
From
Intercom Blog
by Intercom
~8 min read
- Frame roadmap items as problems, not predefined solutions
- A good problem statement names the outcome and the pain
- Starting from the problem leaves room to change the how
Open
intercom.com →
Why we picked it
The single essay behind our line that a roadmap is a direction, not a contract. It argues that a long plan is just a guess you wrote down, and that writing it down gives it a false weight it has not earned. Read it when you feel pressure to commit to a twelve month plan you cannot actually see.
From
Signal v. Noise (Rework excerpt)
by Jason Fried
~4 min read
- A plan is a guess, so stop treating a long one as truth
- Working without a rigid long plan is fine, and often faster
- Decide in the short term with information you actually have
Open
medium.com →
