Fibrus
Decide what to build before anyone starts designing
Product strategy decides which customer and business problems a product should solve, and how you'll know it's working. A roadmap then turns those choices into an order of work, with the biggest impact first.
When to call us
When the roadmap is a wish list
If what gets built depends on who asked loudest, strategy gives you a fair way to choose.
Your roadmap is a list of requests from whoever asked loudest.
You have five good ideas and no fair way to choose between them.
Engineering is being asked for estimates before anyone has agreed the problem.
You need to know an idea is worth funding before design and build start.
The website, the portal and the product are heading in different directions.
Why it matters
A lot of effort goes on the wrong things
Most digital initiatives miss their targets, and a lot of what gets built is rarely used.
-
40%
of product teams surveyed do little or no experimentation, and base their roadmap on leadership preferences instead.
Source: Atlassian, State of Product 2026, September 2025, vendor research, opens external site
-
6.4%
of features generate 80% of clicks in the median product, in Pendo's customer benchmark.
Source: Pendo, Feature adoption benchmarking, July 2024, vendor research, opens external site
-
52%
of digital initiatives miss their business outcome targets, according to CIOs surveyed worldwide.
Source: Gartner, CIO and Technology Executive Survey, October 2024, opens external site
What we do
-
Gather the evidence
Stakeholder interviews, customer and user research, your analytics and a look at competitors, so the decision isn't made by whoever spoke last.
-
Score the options
Each idea is scored on value to customers, value to the business, effort and risk. You see the scores and can argue with them.
-
Draw the line
We agree what goes in the first release, what waits, and what doesn't get built at all.
-
Turn it into a roadmap
An order of work tied to outcomes you can measure, with the assumptions written down so you know when to revisit it.
-
Estimate the first release
Scope and cost for the first release, from the people who would build it.
Worth knowing
What good strategy looks like
Three things worth knowing before you start.
A roadmap is a set of choices
Not a list of features with dates on. Each item should say what problem it solves and how you'll know it worked. When the evidence changes, the roadmap should change too.
"Don't build it" is a good outcome
Some ideas should be parked, bought off the shelf or tested cheaply first. Finding that out in a few weeks costs far less than finding it out after launch.
It shouldn't slow you down
Strategy work is timeboxed and ends in a decision. The point is to start building the right thing sooner, not to produce a deck.
Self-check
Is your roadmap a strategy?
Five questions to ask about the roadmap you have now.
- Can you say which customer problem each item solves?
- Does each item have a measure that tells you whether it worked?
- Is there anything you've decided not to do, and is it written down?
- Could someone outside the leadership team explain why the first item is first?
- When did it last change because of evidence, rather than a new request?
If two or more were hard to answer, you probably have a backlog rather than a roadmap.
Questions
The things people usually ask
Plain answers about product strategy and roadmapping, what's involved and what we need from you. Anything else, just ask.
How long does it take?
It depends on how much research the decision needs.
Who do you need from our side?
The people who'll make the decision, someone who knows your customers and someone who knows the technology. A few hours each, plus access to whatever data you have.
Will you only recommend things you'd build?
No. If the answer is an off-the-shelf tool, a change to something you already have, or nothing at all, we'll say so.
