Most technology roadmap planning happens once a year, in January, built on intentions and best guesses about what the business will need. That's the wrong moment to plan the second half. By July you have six months of actual evidence: what shipped, what stalled, what got used, what got ignored. Technology roadmap planning for H2 should start from that evidence, not from a fresh whiteboard.
I see the same mistake every year: teams treat the mid-year roadmap review as a chance to add new ideas rather than a chance to be honest about the old ones. The result is a roadmap that keeps growing and never gets lighter. Here's the method I use with clients to fix that.
Start with a kill-or-continue list, not a wishlist
Before you add anything new, go through every initiative that was on the books in January and make an explicit call: kill it, or continue it. No third option, no "let's revisit next quarter." Vague continuation is how dead projects keep consuming budget and attention for years.
For each item, ask one question: did this earn its continuation, or are we continuing it out of habit? A pharmacy chain we worked with had a loyalty app redesign sitting on their roadmap for three straight quarters, never fully killed, never fully resourced. Once we forced the kill-or-continue call, it got killed, and the freed-up dev time went into fixing their stock sync problem instead, which is documented in A Pharmacy Chain Synced Stock Across 8 Branches. That reallocation only happened because someone was forced to say "kill it" out loud instead of letting it linger.
Practical version of this exercise:
- List every initiative from the H1 roadmap, shipped or not.
- Mark each one: killed, continued, or shipped-and-done.
- For anything marked "continued," write one sentence on what evidence justifies it.
- If you can't write that sentence, it's actually a kill.
Use H1 results as evidence, not intentions
Plans are cheap. What actually happened in the first half is the only reliable input for the second half. Pull real numbers before you plan anything:
- Which features shipped got used, and which got ignored after launch?
- Which vendor or tool decisions turned out to cost more time than they saved?
- Where did staff quietly route around the new system and keep using the old spreadsheet?
- What broke in production, and how long did it take to notice?
This is uncomfortable because it often means admitting a Q1 or Q2 bet didn't pay off. That's fine. Technology roadmap planning that can't tolerate admitting a miss isn't planning, it's marketing to yourself. If a rollout didn't get adopted, the cause is rarely the technology; it's usually change management, covered in Change Management: Why Staff Reject Your New Software.
Pick one new bet, maximum
This is the part clients resist the most. Every planning session generates five new ideas: a new POS module, a customer portal, an AI assistant, a website overhaul, a CRM migration. The instinct is to greenlight two or three of them because they all sound reasonable in isolation.
Don't. Pick one. A second-half roadmap with one new bet and full follow-through beats a roadmap with three half-funded initiatives every time. If you're not sure which one deserves the slot, run each candidate through a simple filter:
| Question | Why it matters |
|---|---|
| Does this fix something that's actively costing money or customers today? | Urgency beats "nice to have" |
| Can it be finished in this half, not just started? | Unfinished bets are the H1 mistake repeating |
| Is there a named person accountable for it? | No owner means no finish line |
| Does the team already have the skill or a clear vendor to close the gap? | New tech plus new skill plus tight timeline is how projects stall |
If two ideas tie, pick the one closer to revenue or retention, not the one that's more interesting to build. An automotive workshop client of ours resisted this for a while, wanting a flashy customer app before fixing the basic booking chaos that was costing them walk-ins every week. Once they picked the one bet that mattered, the result is in An Automotive Workshop Ended Its Walk-In Chaos.
Put a named human on every finish line
Every item on the roadmap, carried-forward or new, needs a named owner and a date. Not a team name, not "engineering," a person. Roadmaps that assign ownership to a department instead of a person are the ones that slip quietly for months because no one individual feels the deadline.
This matters more than the tooling you choose. I've watched well-resourced teams with good tools miss deadlines because ownership was diffuse, and I've watched lean teams with mediocre tools hit every date because one person's name was on the line and everyone knew it.
A workable format for the second-half roadmap document:
- Initiative name
- One-sentence definition of "done"
- Owner (a person, not a team)
- Finish line date
- What gets killed or descoped if the date slips
That last line matters. Without a pre-agreed consequence for slippage, "the date" is just a suggestion.
Don't skip the technology strategy conversation
If your H1 roadmap was really just a list of features rather than a reflection of where the business is actually headed, the second half is a good checkpoint to fix that gap. A roadmap without a strategy behind it is just a task list with better formatting. We wrote about the distinction in Why Your Business Needs a Technology Strategy, Not Just a Website, and it's worth revisiting before you lock in H2 priorities.
Practical takeaway
Second-half technology roadmap planning isn't about generating more ideas, you already have enough of those. It's about being ruthless with the kill-or-continue list, picking exactly one new bet, and putting a real name and a real date on every line that survives. If you want a second set of eyes on your H1 evidence before you commit to H2 priorities, that's a conversation better had now than in December, reach out through /partner.