A product roadmap for year one should be three paragraphs, not forty tickets. A year-one roadmap has three phases: months one through three are learning, months four through six are focusing, months seven through twelve are scaling. Do not plan features beyond six months. Learn for a quarter, focus for a quarter, scale for two, and replan every quarter without drama.
Your AI strategy should start with your data
Every B2B company is being asked about their AI strategy. The answer should start with your data, not with the technology. What data do you have that is unique? What predictions or automations would create value for your customers? What can you build that a generic AI tool cannot?
The mistake is adding AI features because competitors are. A chatbot that answers generic questions is not a strategy. A recommendation engine trained on your proprietary usage data is. Start with the data you have, identify the decision or task it can improve, and build the smallest version of that improvement. Ship it, measure it, and iterate. AI is a capability, not a product.
Scope your MVP to one workflow, not one market
The biggest MVP mistake is trying to serve an entire market instead of a single workflow. A workflow is a specific sequence of tasks that a specific person does to accomplish a specific goal. Serve one workflow for one persona exceptionally well and you have a product. Serve five workflows adequately and you have a demo.
The test for your MVP scope: can you describe the before and after in one sentence? Before: the customer manually exports data from three tools into a spreadsheet. After: the customer clicks one button and the report is ready. If your before-and-after takes a paragraph, your scope is too broad. Narrow it until the sentence is crisp.
Technical debt is a business decision, not an engineering one
Technical debt gets framed as an engineering problem. It is not. It is a business decision about trade-offs between speed and quality. Sometimes shipping fast with debt is the right call. Sometimes it is not. The decision should be made consciously, with the business context, not by default.
The framework: track technical debt like financial debt. Know how much you have, what the interest payments are (slower development, more bugs, harder hiring), and when you plan to pay it down. Allocate twenty percent of engineering time to debt reduction. Not zero, because it compounds. Not fifty, because you still need to ship. Twenty percent is the sustainable rate.
Build versus buy depends on your differentiation
The build-versus-buy decision should be based on one question: is this capability a differentiator for your business? If it is, build it. If it is not, buy it. Your CRM, your payroll system, your analytics platform are not differentiators. Your core product is.
The mistake is building everything because you can. Engineering time is your scarcest resource. Every hour spent building something you could buy is an hour not spent on your differentiator. The counter-argument is that off-the-shelf tools do not fit your workflow. Sometimes that is true. Usually it is an excuse. Adapt your workflow to the tool unless the workflow is genuinely unique.
Prioritize features by impact, not by request volume
The features your customers ask for most loudly are not always the features that will have the most impact. Loud customers are often edge cases. The features that matter are the ones that open up new use cases, reduce churn, or expand your addressable market.
The prioritization framework: score each feature on three dimensions. Reach: how many customers does this affect? Impact: how much does it improve their workflow? Effort: how long does it take to build? Divide reach times impact by effort. Build the highest scores first. Re-score quarterly as your customer base and market change.
Frequently asked questions
What should a year-one product roadmap look like?
Three phases: months one through three are learning, four through six are focusing, seven through twelve are scaling. Anything planned past six months is fan fiction; the year will outrun the plan.
Why avoid planning features beyond six months?
Because the information you will have in six months is worth more than the confidence you have today. Long-range feature lists exist to be defended, not built. Plan direction far, plan features near.
What belongs in the learning phase?
Talking to customers weekly, shipping the smallest useful thing, and instrumenting what happens. The output of the learning phase is not features; it is knowing which problem deserves the next two quarters.
How do I move from learning to focusing?
Pick the one workflow where users got the most value and make it excellent. Focusing means saying no to the other four things you learned. The roadmap gets shorter as conviction grows.
How often should the roadmap change?
Quarterly reviews, small corrections anytime. A roadmap that never changes is not being used; one that changes weekly is mood, not strategy. The quarterly cadence is the compromise that works.