Economist Arthur Laffer became famous—well, as famous as an economist can become—when he introduced his Laffer Curve to explain how tax policy affects government revenue.
In this simple bell curve, at one end the tax rate is 0%, and the government therefore takes in no tax revenue at all. As the hypothetical tax rate goes up—to 5%, to 10%, to 15%, etc.—the government collects increasing amounts of tax money. This all makes intuitive sense.
But something interesting takes place farther along on the tax-rate spectrum—and no one is sure exactly where it happens. At some point, when the rate goes up one more percentage point, revenue actually falls. The trend continues in this manner, rising rates and declining revenue, until the tax rate finally reaches 100%—and the revenue the government collects drops back down to nothing. If every dollar you earned was going to be seized by the IRS, would you keep working?
In other words, there is a rate somewhere between 0% and 100% that represents the sweet-spot for collecting taxes. Raise the rate another percentage point beyond that magic number, and even though doing so up to this point had resulted in more tax revenue flowing in, now revenue will start dropping. This is because at some point the increased tax rate starts to act as a disincentive to be productive—people will work less, businesses will invest less, and individuals and corporations will find more ways to hide income from Uncle Sam.
Part of the genius of the Laffer Curve is that it can be applied to many areas of life. Completely ignore a child’s efforts or achievements, for example, and the child might learn such behavior isn’t valued. Offer some praise, and she will likely continue behaving similarly. But offer too much praise, and it might become counterproductive. We have even written about this sweet-spot in a blog about building the right cross-functional product team: include too few people, or too many, and you risk problems in your product’s development.
How and When to Share Your Product Roadmap
The Laffer Curve principle can also provide some clarity when deciding whether or not to publicly share your product roadmap, and how much detail to include if you do.
Like the amount of money falling even as the government taxes a greater percentage of the economy, there is a counterintuitive truth at work in sharing your roadmap as well: There is risk on both sides of this strategy. Publishing too much detail in your roadmap carries obvious risks, but not publishing anything can, for some companies, carry risks of its own.
On one end of the spectrum would be oversharing. Imagine you published a roadmap delineating every strategic detail about your product’s next release: epics, features, deadlines, plans for third-party integrations, major marketing pillars to support the new release, etc.
This type of roadmap would present significant risks of:
- Setting up your users and prospects for disappointment if you don’t hit the deadlines promised in your roadmap, or if you have to delay a feature until a future release.
- Alerting your competitors about the details of your product, giving them an opportunity to copy your planned strategy or to improve upon it.
- Inviting complaints or demands from users even before you release the product and they have a chance to experience it firsthand—after which their opinions might improve.
But what about the other end of the spectrum? What about not sharing anything? No roadmap for your users to view, and not even a hint about what’s next strategically for your product?
Wouldn’t this also put your product and team at risk of…
- Losing some users’ interest in the product?
- Worrying some users that your team is no longer investing in the product, and that it might not continue to be updated or even supported?
- Missing opportunities to sign up new customers or to extend your relationships with existing customers—all of whom might be interested if they knew your strategic plans?
Use the Laffer Curve to Identify the Sweet-Spot in Every Decision About Sharing Your Roadmap
There is actually a Laffer Curve for every decision you can make about publicly sharing your roadmap. For every decision, you will be aiming for the sweet-spot that offers you the greatest strategic benefit and the lowest risk.
1. Should you publish your roadmap if it lists specific features?
Here the Laffer Curve might argue that if you don’t include even a hint about functionality you risk losing customer interest, because users won’t have any idea of what to expect or any reason to be enthused about your next release.
But if you list all of your actual features, you’ll be both alerting the competition (and maybe giving them ideas they didn’t have) and risking a big letdown if any of those promised features don’t make it into your release for any reason.
So you’ll need to look for that sweet-spot, giving away just enough information to maximize anticipation while minimizing these downside risks.
“Should you publish your roadmap if it contains specific features? You’ll need to find a sweet-spot, giving away just enough information to maximize anticipation while minimizing risk.”
This is also a great reason not to create your roadmaps as static documents using spreadsheet or presentation tools—but instead to use a web-based roadmap tool. Using such a tool, with just a few clicks you will be able to create multiple versions of your roadmap—say, one just for your internal teams and another, less-detailed version to share publicly.
2. Should your roadmap include timelines?
Again, consider the Laffer Curve and locate your organization’s sweet-spot answer.
If you publish a roadmap without even a broad suggestion of when the product should be available, that could cost you some potential customers, particularly if yours is a product they need or if you have a lot of competitors.
By contrast, if you publish too much detail about your planned timelines—“Expected Release: May 17”—you are setting your team and your organization up for an angry response if you miss that date.
We believe the Laffer Curve sweet-spot here would be a broad timeframe—“Q3,” “the second half of 2017,” etc.
3. How prominently should you feature your public roadmap’s disclaimer?
How you approach this question might have a bigger impact on your product and your organization than you realize at first.
Whenever you share your roadmap publicly, you are essentially making a promise to anyone who reads it. Even though you are not explicitly guaranteeing any of the strategic updates or functionality listed on that roadmap, that is how readers will likely interpret your published roadmap—as a promise and a guarantee.
So you will need a disclaimer of some sort. On one hand you can hide the disclaimer as a tiny link or blurb near the copyright information. At the other end of the spectrum you can follow the lead of some product managers and actually make the disclaimer a large-text, prominent portion of the roadmap, a section no viewer could miss.
There is risk at both ends, of course. You don’t want your customers and prospects to perceive you as trying to bury the disclaimer.
But you also don’t want to thrust it so far into the foreground that it seems you don’t truly stand by any of the plans you’re displaying for your product. That might undermine much of the value of sharing your roadmap in the first place.
Here, our advice would be to find a middle ground: Don’t hide your disclaimer, but don’t give it an undue amount of prominence.
You can use the Laffer Curve approach for every question you’ll have to ask yourself about sharing your roadmap—starting with whether or not it makes strategic sense for your company and your product to share the roadmap at all.
Our feeling is that if a roadmap is too specific, it can be dangerous. If it’s too generic, though, it can be worthless, because it won’t excite or inspire anyone. So you’ll have to find the sweet-spot that’s right for your products and your company.
If you’d like an example of an organization that has thought through these strategic questions and publicly publishes its roadmap to great effect, check out our interview with the head of the hugely successful government portal, GOV.UK.