filmov
tv
How do you plan a product roadmap? with Praful Poddar #FWDRadio

Показать описание
Learn Product Management and new age trending skills on FWD App, the fastest way to learn and develop in-demand skills.
First of all, very personal but I don’t
like the word roadmap at all.
The reason for that is,
when we say roadmap,
it is almost translated into deliveries
that our product tech team is
supposed to do versus results.
And I am a big fan of moving the notion
of product tech teams,
more towards outcomes,
rather than outputs.
We really want to focus on driving
results versus trying become this,
feature factory again, in the context
of digital product development to say,
hey, these are the features
that you deliver.
You will not really care
about the results.
So I think roadmaps just throws
out that notion,
while on the flip side, I do understand
it is very much needed
in a lot of settings for visibility
of what’s coming, predictability
and planning for other functions and you
are dependent for things to get adopted,
or do you need operations support
on the ground work to be done?
All of that needs to become
more and more visible.
The way I look at roadmap is that,
and to give you an example
of how we are doing it at OLX,
and what some of the things
that are working is
we are almost looking at first planning
an entire financial year for ourselves
and financial year planning is around
very hardcore business metric planning.
You are saying at the FY-22,
what are the business results that
as an organization I want to get,
and these are somewhat sacrosanct, right?
The means to get there is where it
becomes more and more fluid.
So, we are saying,
hey, this is what we need to hit.
Now how do we get there? And let me
try to break it into chunks or timelines.
And with OKR best practices in our
environment, quarter works fine.
So we say, hey, let us break this
entire area into four quarters.
The quarter that is right up front that
you are going to hit in the next month,
you should have a lot of clarity
on what you want to build.
Where you are saying, within this quarter,
how my results are going to ramp up
during the last three quarters
of the year,
up to what I want to get at the end
of the year.
So as you get more and more away
from your current timeframe,
it should become more and vaguer
in terms of actual deliveries
and it should become clearer in terms
of quantitative measure.
So you are saying, hey, in Q3,
we actually want to hit this result.
I don’t really know how, but I know this
could be a thing that I want to do,
but in Q1, I want to get to this business
result with these particular hypothesis
or features or initiatives
that I want to do.
So, that’s how fundamentally roadmaps
should be built, as you move away,
it should become clearer,
just on the quantitative,
not so much on the actual
delivery that you are trying to do.
And just have some these there. And
even if you extend that further to say,
hey, I want to actually think of three
years down the line at that point in time,
you probably don’t even have quantitative.
You probably just have a vision.
There you are saying, hey, this is how
I feel the product experience should be
for my users three years down the line,
which could be a collection of many big
hypothesis that we put together to say,
I really want to imagine this new
experience.
So that’s how I look at roadmap when
you are thinking of building it
for a year or a larger timeframe
in that respect.
The second input on roadmap, and again
this is going back to what I was saying,
is getting people bought in early.
Again, product managers
I feel like operate in silos
and this could be valid
for product leaders as well.
And they are almost trying to construct
this roadmap in isolation to say,
hey, this is all I have done.
This is how I am going to deliver
all these features to you
without taking as much input
by a collective knowledge
of all the other functions.
I think getting people signed on early and
taking feedback very critically and openly
is really important to building the right
vision towards the roadmap,
I think is really important.
And the third I feel roadmaps
optically also you need to work
on this really carefully, optically
if you start putting a list of features,
that’s going to be assumed that
those are the things you want to do.
Optically, the thing should
be in black and bold.
And the largest are the numbers that you
want to, they should not be the features.
Even in the template of the roadmap
in every quarter on every area,
what you are trying to hit really,
the focus should be the results,
and not how you get those results.