
Ask HN: How to properly manage a product roadmap? - joantorres
Hi. I&#x27;m the PM for a small fintech startup and the business team is constantly changing priorities based on new client requests, so the tech team cannot cope with all the new features and these end up suffering continuous delays.<p>Do you let new customers drive your product roadmap, or just decide your own roadmap and stick with it? Which approach works best in order to gain more product velocity?
======
crazygringo
Welcome to being PM -- this _is_ the job.

And this is exactly what the agile/sprint process is extremely helpful for.

Every two weeks, check in with the business team to bring them up to date with
development and get them to prioritize/rank the features they want.

Then hold a big meeting with your team and use planning poker to estimate how
long the top-ranked items will take. Inevitably it'll add up to 2 or 3 months
of work.

Then go back to the business team with the realistic estimates for each task,
and get them to pick what is _actually_ most important to deliver or make
progress on in the next 2 weeks.

Then work on those for the following two weeks. Rinse and repeat.

The key thing here is that there is an objective process. Nobody can blame you
or any single developer -- there is a _process_. And after several of these
iterations, the process will build _trust_ among everyone, instead of blame or
suspicion.

Also, you might think this leaves you with no room for input of your own. And
in a way this is true -- welcome to being a PM. Your job is to manage and
balance other people's priorities, not your own wishlist of features. But it
is _crucially_ your job to advise well and point out
inconsistencies/dependencies -- e.g. sales wants feature A but the CEO wants
feature B... but if we deliver B before A then together they'll take half the
time, or will enable feature C earlier, or whatever.

And it's also your job to keep your eye on the long-term goals, which will
generally be set by the CEO or management team -- sometimes you have to
deliver feature X that management requires by the end of the quarter, over
_anything_ the sales team wants -- which you just gently explain to sales.

~~~
delusional
I get that this is a thought up example, but why is this role necessary in
this case. If the business team knows what they need next, and the software
team knows how long it takes, can't they just get together and work on it? Why
do they need a middleman here that just creates meetings? To be bit more
abstract: if the business team owns the roadmap, then what value does the role
add?

~~~
aidanlister
Get a piece of paper out and draw a bunch of circles on the left, and a bunch
of circles on the right. This is your business team and development team
respectively.

Now draw lines between all the circles. Those are your lines of communication
without a PM. This is a sad diagram, no one knows the whole story.

Now repeat the exercise but draw an additional circle in the middle of the
page.

This time, the lines on the left and right connect to the middle circle. This
is a happy diagram, the developers aren’t pulled in a dozen different
directions and one person has the whole picture.

That is the role of a PM.

~~~
nradov
Where are the customer circles in that diagram? Product managers have to get
out of the office (maybe virtually) and talk directly to real customers and
qualified sales prospects.

~~~
crazygringo
A full diagram has a circle at the bottom for customers and a circle at the
top for management.

The PM is the hub of communication between all 4.

Although on a day-to-day basis, it's the dev team and business/sales that make
up the large majority of interaction.

Check-ins with management are occasional, and conversations with customers are
just kind of an ongoing informative thing.

------
capkutay
There's no way to answer this in a comment...you can take a full course on
tech product management and still not have all the answers. But I'll at least
offer some advice:

Just be very good at measuring and presenting data from all the channels in
your company. Your customers, your prospective customers, your customer
engineers, your sales people, your support team, your engineering managers,
directly from developers too.

Understand the real cost of each feature. That's not easy. Try to predict the
real value of each feature. That can be even harder. How many customers are
asking for that feature? What's the avg LTV of that cohort? Will the feature
reduce churn? By what percentage? Own those metrics and tell the whole company
that's why you're prioritizing those specific features.

Be prepared to go back and check your assumptions and see if your predictions
were correct...If you were wrong, then your next job is figuring out why and
then working towards improving your own models to predict the value/cost of
each feature. The fact is once you start intensely measuring that type of
data, you'll find lots of gaps in your own process and fixing it as you go.

~~~
coder1001
Any good courses you can recommend on tech product management? Seems like very
relevant here.

~~~
nelsonic
Top 75+ Resources for Product Managers: [https://www.sachinrekhi.com/top-
resources-for-product-manage...](https://www.sachinrekhi.com/top-resources-
for-product-managers)

~~~
rige
Thanks so much! I'm entering a PM role soon and this'll be a great reading
list to get me up to speed.

------
buro9
No single customer owns your roadmap, your roadmap is yours.

Unless you're actually billing hours to customers for features, the features
you add are yours. Sell what you have now, do not sell based on a future
promise.

You need to balance the value of a single customer against the opportunity
cost of not building a feature that all customers want.

The way I've found to do this: Qualify every feature request. Get in touch
with 10 customers and have a list of the outstanding feature requests, and
give them a virtual $100 and say, if you can spend this $100 on these n
features and you only have $100, how would you spend it? Then take the answers
from the 10 customers and see which added to the highest $$$ income. If a
single customer is an outlier with all $100 on one feature, establish with
their account manager the state of the account, are they happy? At risk? and
prioritise accordingly.

Throughout this process, always have your vision hat on. Is the ask for "add
this toggle" or is there an underlying common theme that a different approach
could satisfy. This is the "most people wouldn't ask for a car, they'd ask for
a faster horse" (not said by Ford but always mis-attributed) symptom... you
need to see how features align to your vision, and bear in mind that the
customers today may not be the ones you need in the future, startups go
through wave of customers and you need to be working up that food chain, so
what are the right features to satisfy needs, but put you on a path to the
customer you want in the future.

Oh, and I'm an engineering manager not PM but had my own startup and had to do
this stuff.

~~~
satyrnein
I personally don't use this approach because I feel like it leads you to a
grab bag of features and not a cohesive product. A lot of product management
in my experience is laying conceptual groundwork that no client or stakeholder
directly asks for. That said, the following article expands on the "Monopoly
money" approach, but applied to stakeholders:

[https://firstround.com/review/This-Product-Prioritization-
Sy...](https://firstround.com/review/This-Product-Prioritization-System-
Nabbed-Pandora-More-Than-70-Million-Active-Monthly-Users-with-
Just-40-Engineers/)

------
renewiltord
Oh, this is literally your job. There are different takes on this, and the
detail is hard, but the broad strokes are:

* Follow your vision for the product - i.e. form a feature-set that combines the greatest compatible combination of requested features and your understanding of what the future of the product post those features will look like

* Solve the immediate next problem that will bring you most money fastest. Apply debouncing. i.e. the next blocker to money is feature A in the shape of a customer saying "we're ready to sign if you have A". Rank all amount of money, likelihood of customer actually executing (if you aren't able to sign on to a pilot w/ "we'll have it next week"), and divide by time. Do that. Do not re-evaluate for some duration of time.

* Find what you're selling. Sometimes this can be very different from what you're making. And the customer may be asking for a feature because they think that feature in the thing they're being sold will solve the problem they're having.

Honestly, no one here can help you with this. I suspect not even a course
could help you with this. This you're going to learn by attempting to
constraint solve here. Just learn from the pain fast and do what's necessary
to keep the trust of your team (primary!) and your customer (secondary because
there's more of them than the team).

------
jSully24
You don't have a roadmap problem, your company has a sales leadership problem,
which if left unchecked will kill your company.

Sales leadership should know that they need to build a sales team capable of
selling what you have now while providing a vision of the future. Just
guessing, but it appears they are caught up in trying to sell using features
rather than selling your product as a solution to the problems your potential
clients have.

If they can not sell the solution and keep getting caught up in a feature to
feature competition, your company is in significant trouble.

That said... the feedback from potential customers, new customers, current
customers, what you see competitors doing, your support organization, and the
engineering team plus your vision of what the product needs to become are all
critical for you making decisions on what to build.

As many here have said, there is much more to your question than can be
answered here. I'd be happy to talk if you'd like to.

By the way, I have a single KeyNote slide for our roadmap. Not fancy, but it
is simple, cheap, and gets the job done so we can focus on the product.

~~~
specialist
Sales != Marketing.

Like the difference between Test and QA. Complimentary, but still distinct.

Marketing's job is to divine the business case. Size of market opportunity,
price points, window of opportunity, initial MVP thru mature feature set,
projected P&L, and so forth. While collaborating with devs, for sanity checks
and buy-in, ideally.

Real marketing is a real job with real skills. Once you've seen a pro in
action, it kind of ruins you for all the pretenders.

In my 30 year career, I've worked with precisely 2 marketing pros.

(Sales pros are pure gold too.)

PS- Lisa Horwich is one such marketing pro. If your product has a business
case, she'll find the critical path. Watching her in action still seems like
magic to me.
[https://www.linkedin.com/in/lisahorwich/](https://www.linkedin.com/in/lisahorwich/)

------
emilsedgh
I personally don't have any problems with changing priorities as long as the
cost/benefit calculation is done and some things that are easy for management
to miss are considered:

* Developer context switches are expensive (both in terms of developer happiness and productivity)

* Forks staying off main branch are expensive.

* Components/Modules being half-polished due to changing priorities are expensive (both in terms of customer satisfaction and introducing technical debt)

So for me, who is in a similar position, it's always a dance between what
clients want, what management wants and what would keep my developers
productive and happy and my product technical-debt-free.

If there's something that my clients ask for and it's _really_ easy to
implement, I would often ask my developers to drop other tasks and
implement/hotfix it. But I'll try to redirect some good feedback from the
customer side to the developer because I know they feel exhausted by changing
direction.

------
ian0
Been there, made all the mistakes. In small fin-tech startups no less. My
advice, assuming you have some sort of product market fit:

1 Clean up shop. Set expectations & bounds. Throw out your backlog. Tell
everyone you will release one BIG THING and X minor bug-fixes every month.
Your job is to give the engineering team enough space to do their job well
(including refactoring, compliance, security etc). And its their job to make
sure that one, well specced, well sized BIG THING releases on time.

2 Business team, with your help, has 12 attempts a year to try to release
features _that will significantly up the growth /revenue of your company_.
Make yourself available to them to learn more about the customer and business
needs and spec out your BIG THING each month. This _has to involve a huge
amount of actually talking to customers_. If not, its pretty much guaranteed
to fail.

Seems basic but theres a lot packed into the rational, like:

\- Non-tech folk don't know what a big thing is, so you have room to play and
overdeliver (important for your engineering team moreso than you).

\- Reduced feature throughput generally means you only focus on those features
that tilt the needle. Cant underestimate how important this is! Esp if your a
fintech startup. Our products are notorious - 5% of features account for 99%
of usage.

\- Reduced feature throughput also allows you to spend longer speccing /
talking to customers & business teams reducing the risk of mid-development
scope creep or problems on release.

~~~
jlbnjmn
Excellent comment, thanks for sharing.

You said:

> This has to involve a huge amount of actually talking to customers. If not,
> its pretty much guaranteed to fail.

Do you have any advice for doing that well?

------
apinstein
Lifelong Serial Founder/PM here. The one biggest thing I see missing from most
comments (which in general are quite good) is that the role of the PM and the
decision framework depends very highly on the stage that your company is in.
Are you pre product/market fit? Are you just seeing traction? Are you in hyper
growth? This should massively change your decisions.

There are endless frameworks for balancing these choices. For me, they all
come down to this:

Value

1\. Dollar value; in either revenue unlocked or money saved (and money can be
customer support time)

2\. Strategic alignment; how is the item aligned with overall vision & goals?
If this item is completed, does it make us stronger or dilute our value /
competitiveness? This is really where stage of company comes into play.

...vs...

Cost:

1\. Time; Estimated time to build/support. This can be a wag from the
engineering team.

2\. Risk; what is the uncertainty around the time and maintenance estimates?

Using a framework like this allows you to include architecture, technical debt
maintenance, etc into your overall planning and decision process. This will
help make visible to business stakeholders the true complexity of operating
the product and hopefully lead to better PM decisions. Everything is a trade-
off.

Remember: one of the most important jobs of a PM is to say NO. You are the
process gatekeeper to how the company spends a ton of resources.

Happy to discuss further.

~~~
blp
Well said. I will add that each different industry is different, and often
every company aligns the role somewhat differently.

If you are building enterprise software, vs hardware, vs consumer
products...the process can be very different, with different balances on risk
and very different timelines

------
PragmaticPulp
A lot of good responses here, but they're all missing the core problem from
your post:

> business team is constantly changing priorities based on new client requests

If you have a separate "business team" that changes the priorities, _they_ are
managing the roadmap, not you. If you have a situation where you are
accountable for the roadmap but other people get to make all of the roadmap
decisions, you are in a very difficult position. The most important thing for
you to do is focus on communication and clarity.

If you aren't already, you need to be tracking everything from week to week.
Record a snapshot of the priorities on a given week, along with any "business
team" inputs that change the priorities. You need to be able to show in detail
where each priority started, stopped, paused, or was re-ordered. You also need
to be able to show _who_ directed the priority change. Work on a report or
slide format that can clearly show how the priority list has evolved over the
course of the year, and don't be afraid to put names next to each priority
change ("Moved to #3 priority on Mar. 3 after request from Bob").

If the priorities are constantly churning to chase whatever client requests
are coming in, the sales team has hijacked the PM process for their own
personal gain. The best way to push back against that is to shine some light
on it by tracking it, visualizing it, and communicating it with leadership.
Once you make it clear and obvious, it's much easier to get leadership to
clamp down on priority changes and drive toward some commitment.

But as long as the business team can quietly reshuffle the priority list each
week and let other people suffer the consequences, nothing will change.

------
beckingz
A good roadmap allows you to take customer requests and go to the CEO/C*O and
say "We can build feature X for this client in 30 days, but only if feature Z
we're currently working on gets pushed back 35 days. This will push the whole
roadmap back 5-6 weeks. Is that okay?"

Reprioritization is good and normal, but decision makers need to understand
the costs and a good roadmap allows you to communicate that better.

------
skaber
What's been key to my startups on executing and following a roadmap was to use
OKRs at the company level. The roadmap has become a consequence of the
company's annual and quarter OKRs. As a product manager, you are responsible
to come up with a roadmap and priorities based on your team's (engineers,
designers) interpretation of the OKRs. The same way you won't be telling the
business team which client and opportunity they're chasing, they shouldn't try
to draft your roadmap as they have no understanding of the technical
challenges linked to your roadmap. Using OKRs has been a common ground for
multiple departments to agree on priorities and communicate progress. The
challenge can be that there must be mutual trusts across teams. I recommend
reading Measure What Matters. Ping me if you need more resources for OKRs and
I'm ready to share more personal stories and experiences.

~~~
tasubotadas
How do you pick the right OKRs?

~~~
nelsonic
The first step is: encourage everyone in your team to read "Measure What
Matters" [https://www.whatmatters.com](https://www.whatmatters.com) Then
decide what matters to the company and all those involved and write it all
down in a shared document.

~~~
zeece
Agreed. The first step is always to establish what matters most to your
company and your team. From there you'll have a clearer picture of what your
ideal destination is and then you can draft OKRs accordingly. Here's a simple
online guide on How to write great OKRs: [https://www.perdoo.com/how-to-write-
great-okrs/](https://www.perdoo.com/how-to-write-great-okrs/).

Another good place to start is the Ultimate guide to OKR:
[https://www.perdoo.com/the-ultimate-okr-guide/](https://www.perdoo.com/the-
ultimate-okr-guide/).

Hope that helps!

------
zabil
> just decide your own roadmap and stick with it?

While this may sound like it's easier to manage it usually ends up with a
product that does not solve the problem of the customer.

As a product manager solving problems of your user or customer must be the
first priority. The only way to do this is getting closer to the customer.

I find teams shielded from customers via business teams use the best part of
their product management and engineering skills (microservices included) to
manage their business team and not the customers.

There is a constant grooming of the backlog with features and pressure to keep
the engineers managed and busy.

Start measurning the value of each feature to your customers. Have short
customer feedback cycles for planned features. Your backlog should reflect
solutions that make sense to the customer.

The book "Escaping the build trap" talks about this. I highly recommend the
book.

Good books on the subject talks against roadmaps and shifting to a value and
goal based approach.

~~~
tarsinge
I agree, this is anecdote but a dysfunctional company I have seen had
engineering stick on their own roadmap disconnected from customers. The end
result was a product that failed to evolve to the market, no features were
added for years because the engineering roadmap was always to migrate to a new
exciting technologies, or improve fun features to work on but that no
customers were using.

------
fraserharris
Two approaches that can fix the root cause of mis-alignment between sales &
product:

1) Teach your sales team how to pitch your product roadmap, so that customers
are buying into the bigger vision. When customers are bought in, they will
accept that they don't get their small feature because they will gain
something larger faster. Sales LOVES when this is successful because then
their deal can close faster.

2) Challenge the sales team to find at least 2 other customers that need the
same feature before you agree to re-prioritize your product roadmap. This
creates alignment between them & your need to prioritize the most impactful
features.

------
jdale27
Communicate clearly with the business team about the consequences of churn: if
everything is a top priority, then nothing is a priority.

There are multiple reasons for changing priorities.

Are there multiple business folks all generating requirements independently,
insisting that their client is the most important? Get them all in a room to
hash it out. Either they all agree on a ranking of the clients, or they each
have to prioritize their own requests and choose a small number (say, 1-3) of
truly critical requests to put into the engineering queue. If they can't agree
on this, escalate to the CEO. If the CEO can't/won't prioritize, you're in bad
shape. Your best bet is to make a judgment call as to which clients/features
are truly critical and drop the rest on the floor. Be prepared to send out
your resume if you make the wrong call.

If the clients themselves can't decide what they want, or can't communicate it
effectively through the business team, you need face time with customers. If
you have a product-minded engineer who is good at speaking the customer's
language, include them too. The more direct exposure and intuition the
engineering team has about what's really important, the more support you'll
have in making those calls.

------
dberg
After seeing so many Product Managers get this awfully wrong sometimes it also
helps to understand what your job _isnt_

* Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs.

* Involve the Business, Support and Eng parts of the org when defining _what_ to build. They all bring fantastic perspectives and really helps focus on the MVP and creates shared buy-in. Remember you are trying to solve a business problem not just crank out features aimlessly as a team.

* When mapping out _what_ to build, it always helps to use the collective team (in previous bullet) to outline Effort vs Impact. Forces really good discussion to keep things hyper focused and efficient.

* Instead of focusing on features focus on the strategy and the vision, let the team figure out how to get it there. As a PM you need to understand the market, the competitive landscape, how people are pricing their products, what customers are saying, industry trends, etc.

* Roadmaps in general are somewhat useless bc you don't have enough information and they create a lot of emotional commitments. Things change (hello Covid-19) and you don't know what you don't know. Instead outline your vision and strategy at a high level and make sure they are aligned to your overall business outcomes. This prevents people from saying "You said we would get feature X in Q2!!!". Instead you focus on metrics (Decreased Churn, Increase engagement by 3x, returning users more than X times in Y days, Revenue, etc).

* Be religious about data. Define your business outcomes, have good tools to track the progress of those outcomes, have a way to test/validate quickly and pivot as soon as it doesn't work. Keep fine tuning the machine

~~~
brightball
Getting people to understand how useless roadmaps are is the hard part.

~~~
dberg
Unfortunately most companies don't know any better that it is not the job of a
PM to "invent" a whole bunch of features that may or may not work.

~~~
bmmccarthy
If a roadmap is a list of committed features, yeah, it's useless. A roadmap
should be a clear articulation of your product vision and the _problems_ to be
solved to get there, not what you think today are the solutions.

This is called a "thematic" roadmap or an "outcomes" roadmap. It is well
described in this article: [https://www.prodpad.com/blog/the-birth-of-the-
modern-roadmap...](https://www.prodpad.com/blog/the-birth-of-the-modern-
roadmap/)

------
BigBalli
After years of leading product, I came to the conclusion that there always
needs to be a process in place between customer feedback and development. All
feedback is appreciated, acknowledged, saved. If it 's not critical feedback
(ie crash), feedback/feature request bucket will be reviewed regularly and
then assessed based on: user benefit (how much does experience improve) impact
(how many users will benefit from this) consequences (will other
users/features suffer from this) ROI (how will it impact the company's, not
purely monetary) requirement (time/cost to implement) goal/mission (does it
align)

Long story short: we NEED user feedback but it cannot dictate the roadmap (and
therefore the mission). If you find yourself repeatedly needing to change your
roadmap it might mean you're too quick/loose adding elements to it.

Hope this helps!

~~~
csours
> "we NEED user feedback but it cannot dictate the roadmap"

Listen to your users but don't trust them.

------
dlevine
I have been a PM for a few years (and an engineer for many years before that),
and my experience is that you don't want your customers to decide your product
roadmap, but you definitely allow them to influence it. Your job is to balance
between features that will please existing customers and features that will
move the business ahead to new customers.

In general, you should have an idea of the next projects you are going to work
on. When customers give feedback, that can help to reorder the projects. If
you are doing your job correctly, there won't be any huge surprises.

There will be occasional one-off customer requests. We call these "customer
love" at my company. We reserve some percentage of our development time (maybe
10-20%) for doing these, because they do create a lot of goodwill with
customers. But you have to be pretty disciplined about making sure that they
are 1-2 days or less of work and not 1 or to months of work.

There will occasionally be things that customers demand as part of a deal
cycle. In some cases you have to build these, but it is important to
explicitly highlight what you are foregoing and to be conscious of this
tradeoff. Note: hiring contractors doesn't really work well, because someone
will have to support it (just went through this).

------
gregdoesit
Priority changes, expanding scope and switching work from one project to the
other all have a cost. Too much of this and you don’t get anything done:
you’re just treading water. It doesn’t matter if you or customers drive your
roadmap and it’s changes (though you would want to have a prioritisation
framework to decide based on what business metrics you prioritise projects).

The first thing you should do is create stability within an ever changing
business environment and also capture the cost of the priority churn. So
create a roadmap, and have a process to capture priority changes, and how much
WIP work is wasted (=not shipped, as it’s deprioritized) as a result.

There’s a bunch of tools and methodologies you can use for this. Sprints,
scrum, OKRs etc.

As an engineering manager in a similarly fast-moving environment, the two main
rules I follow are: 1\. We don’t do any work that does not have impact
defined: what happens or what we expect to happen when this project is
shipped. This is usually in some numeric value. And we always work on the best
impact/effort project next. 2\. The team _always_ finishes what we start and
we do small enough work items/milestones that enable us to iterate quickly.

Good luck!

------
nurettin
Hi, I'm also in the industry and in the same situation. The best life changing
advice I can give is to introduce a one week delay between finishing features
and releasing them. Adjust your software versioning so that you only release
what was done a week ago. You have to stick to that one week delay as much as
humanly possible. This gives a lot of confidence and room to breathe so you
can enjoy work again.

~~~
nurettin
To clarify, let's say you are asked for a feature. The normal workflow is to
determine when it will finish and crunch for the deadline. Once the deadline
arrives, you are going to finish and release at the same time and hope that
you have done enough testing during development. At this point get ready for
embarrassment because you will inevitably make a few mistakes and cut some
corners.

What I am suggesting is, you take a bunch of requests, but manage two
roadmaps. One is the feature roadmap with reasonable dates, the other one is
the release roadmap which lags one week for each feature. So once you release
that awesome backtesting feature, you've been testing it internally since a
week and finding bugs as you go. Do not release when done with a feature.

~~~
satyrnein
Ok, I think I understand better now. We typically turn on the feature for
internal users first and then do a gradual rollout using feature flags so it's
not as high stakes and can be rolled back easily in case of problems.

~~~
nurettin
That's interesting, I understand the need for feature flags, but don't they
reduce code readibility?

~~~
satyrnein
Yes, feature flags are technical debt and need to be removed after rollout is
complete. But undeployed code is debt, too, and the ability to do gradual
rollouts or pull features back in case of issues makes feature flags worth it,
in my opinion.

------
bgdnpn
There always needs to be a balance between external forces changing your
priorities and your internal vision and strategy.

This being said, if the roadmap changes mostly based on new customer asks..
then you're not building a product, but doing custom development /
professional services work.

------
mud_dauber
I'm still diving through all the answers (this is GREAT, btw). 2 of my
previous PM organizations were hamstrung by exec teams that would decide, in a
vacuum, what projects & features would get green-lit.

This interference-from-above characteristic can work if a PM is new to the
job, but ultimately results in a PM having all the exposure (ie,
organizational risk) and zero influence. That's a hopeless scenario & all too
common because the vast majority of orgs have no idea what a PM truly is.

So I want to know if the OP has the freedom to defend his convictions. It's
not about tools. It's about responsibility.

------
scaryclam
To (ab)use a completely overused quote "If I had asked people what they
wanted, they would have said faster horses" \-- Henry Ford

You should most certainly listen to your customers, after all, if you're not
serving them, what's the point in the product? However, you shouldn't be
reacting to their requests to the detriment of the product either.

Do you AB test new feature ideas? Do you gather data to suggest that the
requested feature is actually going to make a positive impact? Do you measure
impact after releasing a feature to see if it was the right call? If not, how
the heck can you ever actually know if you're building something better?

You don't need to ignore your customers, but you also don't need to change
priorities so often. Make a roadmap for X months and stick to it (we use 3
months, but something else might work better for you). Use the time that the
roadmap is being worked on by the tech team to do discovery and research so
that you know what the most valuable requests from your customers are. Collect
metrics, create prototypes (design/ux prototypes, not technical prototypes)
and test them with your customers, do customer interviews. Then when you're
ready to, you'll have better prioritisation, and your teams will have had the
space and stability to release the previous features (and hopefully had tech
investment time as well to keep your systems maintainable).

------
mfrommil
"Do you let new customers drive your product roadmap, or just decide your own
roadmap and stick with it? Which approach works best in order to gain more
product velocity?"

Customers' needs should always drive the product roadmap. That said, it's not
uncommon for customers to not know what they really need until it's already
been built. This is where the Product Manager comes in to the picture. The PM
needs to ensure everything added to the roadmap is of the highest priority and
will solve real customer problems or have a positive impact towards the org's
key objectives.

A couple tips that may be helpful for you as you navigate this situation:

1\. Before any feature-specific debate, you need to be closely aligned on the
overall vision and objectives with your key stakeholders, including the
"business team". What are your most important objectives to hit this quarter,
this year? Growth in active users? Increased transactions? Improved bottom
line profitability? etc. Once this is aligned on, it becomes much easier to
have these prioritization/tradeoff discussions.

2\. Many "business" teams and the leaders of those teams don't understand the
basics of software development. Over time, it's beneficial for the PM to help
educate key non-technical leaders about the costs of constantly changing
direction. Help them understand how technical teams plan and execute, and show
the impact to timeline and quality when reckless decision-making gets in the
way of the engineers doing their jobs effectively. I like to this of this as a
"help them help you" mindset.

------
bmmccarthy
A 2-week sprint backlog is not a roadmap. Yes, you can and should reprioritize
every two weeks, but at a tactical level to better meet your long-term goals
based on what you've learned since the last sprint.

A roadmap is a tool for communicating long-term direction and priorities. By
making clear what the ultimate destination is, a roadmap helps you keep steady
on the those priorities when doing your sprint planning. When sales says "we
want this feature to close this deal," if it's something already on the
roadmap, great. If it really doesn't fit with the long-term vision, you have a
basis for saying no.

I wrote a book on this topic, Product Roadmaps Relaunched, Setting Direction
While Embracing Uncertainty, for O'Reilly a couple of years back that goes
into more detail: [https://www.amazon.com/Product-Roadmaps-Relaunched-
Direction...](https://www.amazon.com/Product-Roadmaps-Relaunched-Direction-
Uncertainty-
dp-149197172X/dp/149197172X/ref=mt_paperback?_encoding=UTF8&me=&qid=1586462478)

------
blizkreeg
Managing the roadmap (and delivering value) is the hardest and the key part of
product management.

It's hard to give generic advice not knowing more about the context but here's
one way that I've found useful and successfully executed. Bucket your roadmap
into 3 rough buckets - delight features (no one has specifically asked for but
that deliver high value), customer requests (obvious), and your/company's
product vision (not something you just concocted but based on real data and
validation).

The % of your roadmap and sprint allocated to each bucket depends on your
specific business, current situation, and startup/product stage.

Don't let customers hijack your roadmap. Talk to them, listen to their needs,
understand the requirements coming from the business team, evaluate the
severity and sensitivity, and ultimately prioritize yourself. There are times
(sprints/months) where > 60% of my roadmap has been customer-driven and times
when only a third of it are customer requests.

------
warp
Have you read Basecamp's shape up?

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

------
deltron3030
> Do you let new customers drive your product roadmap, or just decide your own
> roadmap and stick with it? Which approach works best in order to gain more
> product velocity?

Both, but you need to learn how to listen and translate customer wishes into
the actual jobs to be done. "I want feature x" from customer A, and "I want
feature Y" from customer B might be related to the same context and underlying
problem, so it's best if you create a level of abstraction to sort customer
wishes into. How the actual feature works and how it looks like should be your
core competency, not the customers imo.

------
tablet
I really recommend to check GIST [1] as a replacement for pure roadmaps. It
focuses on goals and some kind of experiments to define what should be
implemented sooner.

GIST is as close to scientific approach as we have right now.

RICE model might help as well [2]

However, being 100% honest, I tried all the models above and they did not
stick to me. I'm playing Product Manager role for 16 years already and rely on
customers feedback + intuition. When you have deep experience in the domain,
you internalize many models and your neural network in the brain quite often
just makes the right decisions. Don't decide quickly though, rely on your
"slow" subsystem, decide as late as possible (and collect evidence).

Another trivial observation is that customers almost always ask you about some
kind of solution. They rarely provide real problems. PM job is to dig into
problems as deep as possible and then find a solution. In many cases solution
is completely different from what customers asked. In some cases problem can
be solved without new features.

[1] [https://medium.com/@itamargilad/why-i-stopped-using-
product-...](https://medium.com/@itamargilad/why-i-stopped-using-product-
roadmaps-and-switched-to-gist-planning-3b7f54e271d1)

[2] [https://www.intercom.com/blog/rice-simple-prioritization-
for...](https://www.intercom.com/blog/rice-simple-prioritization-for-product-
managers/)

------
knbknb
Just yesterday 2020-04-11 Shreyas Doshi (@shreyas) posted a long thread of 30
tweets about "Good" vs "Great" product managers. Some pearls of wisdom are in
there:

[https://threader.app/thread/1249039638829793280](https://threader.app/thread/1249039638829793280)

(He also admits he doesn't knwo any Great PM who has all of the 30 traits and
does all those actions, all of the time.)

------
bisRepetita
Vision, passion, and being realistic. All the management techniques won't
replace that.

You need vision to gain a credible and influencal seat in front of management
and customers, and hear from them. And not just saying yes to the last one who
spoke.

You need passion to cope with all the crap (difficulties, management,
engineers, customers, nay-sayers, finding ressources, etc).

And you need to be realistic and pragmatic to make something happen, even if
not perfect/ideal. Maye next round.

------
brightball
I was running into a similar issue and after a lot of research ended up
adapting the scaled agile framework (SAFe) to our team.

SAFe is designed for larger companies, so you have to learn enough about it to
understand where you can trim the fat. The big applications to your issue come
from 2 places.

1\. Lean Portfolio Management 2\. Program Increments

LPM is a process of setting priorities by using real numbers where possible
and best guesses otherwise. The result is a process that tries to measure
value and urgency against your development capacity. Small things with high
value float to the top. Big things with low value drift to the bottom and
don’t bog down your team.

The Program Increment (PI) is an intense process that lets your dev team put
out a plan for the next 8-12 weeks and gets the business to agree to it. Aside
from getting everyone to agree to the current plan, it changes future business
requests to “be prioritized for the next increment” which happens via the LPM
process.

The PI plan still adapts to new feedback and can change, but those changes
come with “if we do this, we can’t do that...is that acceptable?” Time for
small changed and some variability is built in, so those conversations only
happen for something major.

~~~
darkerside
The first item (LPM) sounds a lot like our current process, which has worked
well for reactive work based on business needs, but all of our long term work
feels like it is prioritized ad hoc, based on gut, or worse, doesn't even get
done. If be interested in hearing more about PI and how it works.

~~~
brightball
I’ve been meaning to write a blog post about it soon.

------
csytan
I'm bootstrapping a simple scheduling SAAS with my wife
([https://www.cozycal.com/](https://www.cozycal.com/)). As the sole developer,
I definitely can relate to the feeling of constantly putting out fires.

We use Canny ([https://canny.io/](https://canny.io/)) for feedback tracking.
It helps us with:

1\. Transparency with our customers. On the support side, we can show that
we're tracking their requests, and where they fit into our existing roadmap.

2\. Less stressful development cycle. I'm still completing some work in our
backlog, but after switching to Canny, it's much more clear what the next
features will be.

Also, here's our public Canny board which lists our feature requests &
roadmap: [https://cozycal.canny.io/](https://cozycal.canny.io/)

------
satyrnein
As everyone says, it's a careful balance. However, I want to emphasize how
much slicing features down to the absolute minimum can help. What you
absolutely don't want is many half finished, unreleased big features. However,
using tactics like continuous deployment and feature flags, you can slice
features into small bits, always be deploying, and launch to customers as soon
as the feature is minimally viable. Then, you have the choice to continue
improving it, or pivot to a different feature depending on how people like it,
new sales opportunities, etc. Plus, having even minimal versions of features
out in people's hands opens people's minds about what they want. You want to
move that churn upstream from development to product at the very least, but
possibly even further up to stakeholders or clients.

------
arendtio
You have to include multiple perspectives. Make a list of the top 5
features...

\- you think your customers need

\- your customers want (ask them!)

\- which offer the highest return on invest

\- your product needs when being compared with your competitors

When you have answered those questions, you should have a good feeling about
which features you want to implement first. Next, ask the devs how your
priorities match up with the development of the application and how much time
it would take to build them. Some features might technically depend on each
other.

Edit: Btw. changing priorities is okay, as long as nobody has started to work
on a feature. As soon as the implementation started you better finish it. Make
sure your business team commits to the things you start implementing and get
the commitment from the dev team to finish things in time.

------
Leherenn
On top of all the good advices here, I would say one important thing is to be
able to fail quickly.

This is more on the engineering side, but if you can shorten the idea to
client feedback cycle, then it's much easier to deal with all those requests.

It's also much easier to tell the business team "let's work on the what's
necessary to get feedback on this feature (which probably mean not even an
MVP) and we'll get result by the end of the month" than "I'm sorry, your
feature has been deemed priority 12, we expect it to be complete in 6 months
to 1 year, provided priorities do not change (they will)".

Once you get this feedback, then it's much easier to quantify things.

------
maliker
What's helped our team has been just writing down the product roadmap. It's as
simple as a bulleted list in a google doc with some estimates about how long
things will take, who's working on them, and what's already been completed.

Every feature request from the business and customers goes on the roadmap,
along with any features engineering needs like supporting infrastructure, and
there are regular meetings to make sure the list is always in priority order.

We've found having everyone looking at the same roadmap greatly reduces
tensions. Instead of arguing over badly-remembered, vague requests, we work
together to strategize the best approach. It's actually fun.

------
mikkom
There is really no simple answer but I would start by clearly defining roles
on who is responsible for priorities, who is responsible for facilitating the
prioritization process and who is responsible for defining what processes are
used to change priorities.

If it is decided that business us responsible, utilize a single backlog that
the business can see and let them fight over the prioritization with defined
practices.

Depending on the size of the company and overall development model I might use
some framework (or pick suitable parts) like Less or SaFE to kickstart the new
development process and then utilize larger scale retros to optimize the
workflow continuously but in a structured manner.

------
m12k
Lots of good suggestions about questions to ask, thinking about aligning
business and development needs, settings expectations with customers, giving
them a chance to pay for development and other 'what are you even doing?' sort
of ideas. So instead I thought I'd give a very simple recipe and set of rules
how to deal with customer requests that I follow, to try to align with this:

\- Never promise a feature immediately when receiving a feature request. Say
"Thank you for the feedback, we'll discuss this with the development team and
get back to you if there's any news regarding this" (tag the user, so you can
actually do so)

\- Never choose to develop a feature until you've gotten at least three
separate requests for it. This will help you not over-adapt to random noise,
and make sure the product stays relevant to a majority of users.

\- Never promise a timeline if you choose to promise a feature. Keep stress
levels manageable for you and your dev team.

\- If you have something 'up next' on the roadmap already, you may choose to
share the estimate with the inquirer - but favor not doing so, and underline
that it's an estimate not a promise if you do. Estimates also become much more
reliable if random stuff doesn't get to jump to the top of the priority list
all the time. Your roadmap is a priority queue, not a stack

\- Consider thinking of it as two priority lists. One is for smaller feature
requests and improvements, the other for larger projects and system/business
needs (e.g. refactoring, features to target new demographics rather than
existing users). Not progressing on either list is frustrating for everyone,
so think of yourself as a scheduler trying to guarantee progress on both
threads. For example you could have a rhythm where it's ~1 month of work on
one or two big projects (until completed), then ~1 week of work on smaller
feature requests and polish, then repeat. This way you batch up many smaller
tasks so you don't incur the cost of context switching for your dev team while
they are working on a bigger feature (which typically require deep
concentration over many days), you don't block major projects, but you also
get to be relatively responsive to customer requests.

\- Remember that things take time. Your job as a product manager isn't to
cater to every user's every need immediately, it is to plot a path through an
endless and evolving roadmap in order to 1) Keep the business alive and
prospering 2) Keep the development team productive and sane 3) Make customers
happy. In that order

------
csours
There are a lot of really good comments here so I will suggest just one thing:
Usage Metrics.

You need to know how much something is being used before you decide what to
improve; so you need to collect usage metrics on everything.

I would also suggest getting quick and dirty Proof of Concepts/MVPs out there
for people to use and validate. The very hard thing about MVPs is getting
customers to realize that it is an MVP and it is incomplete and not "real".
The value is that you can start to see usage information without a huge
investment.

------
Zigurd
I'm currently exploring the intersection of agile project management,
establishing key milestones, product management, and real options analysis
(ROA), among other things.

I think there's a way of tying these things together that reveals value and
costs that can remain hidden. if you want an advance look at the manuscript,
let me know.

It's definitely not for everybody, but maybe your fintech colleagues would
find it interesting. it might prompt them to value what they learned along the
way as well as the cost of changing course.

------
meerita
It is impossible. It depends the scope of the project and the company
mentality. In my 12 years as PM, I understood that no roadmap is useful unless
it is a short-term roadmap with achievable objectives. It is much easier to
plan and scope.

I really don't appreciate when other PMs come to me with a 1 year roadmap. Who
knows how many thing we will not do, or change or pivot based always on the
data we're getting? That's why I preffer better planned things (docs,
teamwork) than a document with a nice unrealistic roadmap.

------
pdubs1
Uhh... I imagine it's different with each situation and product.

But look-- if you're letting other people come in and define your vision for
you... well, you're no longer doing management-- you're following someone
else's vision and they're managing.

You own the product vision. You choose what to incorporate.

I'd ask google so you can find some books and in depth knowledge. A comment or
two in a forum is decent for tips, but if you want knowledge, I'd go seek it
where it is developed in depth: books.

------
j45
Are you building your product for yourselves, or customers?

A roadmap isn’t concrete. You haven’t mentioned if you use agile methodologies
or not, but sprints can buy some breathing time and deliver progress.

Once a feature request made sense to the product to add universally, if it
wasn’t too disruptive, and depending on the feature, I might let clients vote
with extra dollars to move it up the backlog.

Sometimes, a feature was requested by enough clients that hey might even split
the bill on a extra body to get it done.

------
youeseh
You have people constantly changing their minds.

Before you can make a roadmap, you need a sense of direction.

Maybe you need to zoom out a bit. What do you offer? To whom? Why? Why them?
What do you not offer? Why not?

Can you get those answers without asking your engineers to constantly build
shit that they'll need to throw away?

Can you collect information cheaply? Can you ask your bizdev people to get
answers to questions that will help you? What is the cheapest way to learn?

The more you build, the more you'll have to support.

------
Jugurtha
First, everyone needs a place at the table. There is an ungodly amount of
distortion, omission, and loss in transmission between prospect/customer and
engineering. If you have a prospect, meetings should include people from
business, and engineering. If in any case only one person was there, this
person should write up their notes or be downloaded/debriefed while the memory
is still fresh. If someone is updating you on the phone get the most you can
when they just got out of the meeting. Sometimes you ask a question and they
can go back to the person they just met who's probably having a break by now
and ask, take copious notes and dispatch them. If you got anything wrong,
they'll correct.

Written meeting notes should be disseminated, and then corrected and augmented
so that:

\- Those who weren't there get an idea of what was actually said (we have
meeting minutes in version control and anyone in the company can pull them and
know exactly what I discussed in X town at which hour with whom)

\- Those who were there realize they didn't hear/understand the same thing or
plug holes. One catches what another has missed.

\- Track rationale and decisions: All development through issue tracker. Avoid
the "why was that feature added/removed two months ago again and now it's to
be removed/included?" and not knowing why.

This should bring everyone to the same "initial conditions". If you don't do
that, it's telephone game and you get a human-centipede like result.

Include form to request a feature in the product itself. Directly from the
users so there's no distortion. Everyone should get that issue.

Also, if there's no product there is no business, which makes me wonder why
the tech side is taking the backseat in a fintech startup. Fintech is like an
airplane: you take a bus, you add wings, and you have an airbus that can
travel faster and farther. Remove the tech, and it's just finance.

Add monitoring and analytics. We're working on that ourselves after putting
out a lot of fires that looked the same.

Second: customers drive product roadmap in terms of _raw data_. Whenever users
or customers ask something or raise an issue, ask yourself what is the
underlying issue and what are they _really_ trying to do. "Job to be done".
Drill vs hole. Customers complaining is similar to patients complaining:
they'll tell you about _symptoms_ and then want you to fix those symptoms and
they'll propose solutions and features. You gently take notes, and then dig
deeper.

The analogy I use is that customers will ask for a robot with IoT and
blockchain support that automatically integrates with Amazon API and orders
mops, tracks the item, and has AI and image segmentation and recognizes Amazon
drone, and receives the mops and automatically loads them. Because AI,
blockchain, and IoT. Yes, it's not a sentence.

Your job is to ask why, figure out they always find water on the floor, and
then look up and find there's a leaky pipe, then fix the leak.

In other words: do not really listen to the "implementation" or the "solution"
customers propose. These only fix symptoms and are easily swayed by whatever
piece with a clik-bait title prefixed by "This AI robot" someone with 2 minute
attention span has written that the customer half read taking their morning
coffee, and wanted to bring to the product not to be left behind by the
competition.

What one really looks for is the problem. The problem almost never manifests
itself, you have to dig to get it. It's muddy. People could be pissed at you
because "What do you not get in an AI IoT robot that orders mops?". This is
where having social skills and getting good at interviewing comes in handy.

People demands and their behaviors are the solutions _they_ have come up with
to a _problem_. The problem is that they almost never tell you about the
_problem_ , and you may have a better solution. Think of it like code review:
code I push is my implementation or a solution to a problem. The
implementation is dictated by my skill, experience, sophistication, sleep I
had yesterday, etc. Code review helps find better ways.

Third: all developers do support. This focalizes and aligns everyone. You have
a hundred issues in your issue tracker. You have thought of great features. A
lot of the issues are about bugs.

We opened our internal ML platform to about 30 students of our colleague so
they could get a one click notebook with all libraries installed, a lot of
RAM, a sweet K80, and hundreds of gigabytes of data for their project. We
added the students to a dedicated Slack workspace. The platform is not ready,
but precisely. This is a jolt.

Users would complain about something. We would notice a pattern. We would
investigate, then figure out what to do.

They're doing two things:

\- Exposing things we wouldn't have found

\- Putting the finger on what hurts the most amongst the issues we are aware
of.

One person who complains about something is one thing. Ten people complaining
about the same thing that prevents them from working, that's another thing.

We have worked differently in the past. There have been changes to the company
and changes in how product development is done. The business side of our
company used to talk to the executives of the client company. We have been
paid for all our products, whe have shipped them to spec, none of them is
used, none of them can be reused, all of them left us with scars, and that way
of working almost destroyed the company.

Fourth: everyone should be clear on what the team is doing, and what the team
is _not_ doing. This issue is not a priority. We will handle this one, this
one, and this other one by this date. This part is handled by this person.
Avoid the "I thought Alice was working on it".

Fifth: -good engineering practices go here-. Good test coverage. Patches get
their tests, good commit messages, root cause analyses, and eventually
knowledge base. A test harness is not "directly" good for the customers, but
it gives confidence that you won't break everything. Loosely coupled, modular
code: it allows for people to develop with different speeds and reduces
dependency on unrelated parts, which is _really_ frustrating.

~~~
pianoben
What a thorough and valuable comment. This is really valuable stuff - thanks
for sharing your experience!

------
davismwfl
It is completely normal to include feature requests in a product roadmap and
to be getting them developed when appropriate, that definitely isn't a
problem. Things are also different when you have 1 client versus when you have
10+ clients. When you have 1-2 clients you generally do things you wouldn't
and shouldn't normally do under good product management standards.

So let's assume you fall into the 10+ client category. The company should have
a defined and published product roadmap that is being worked, new features
should be vetted against the client demographic (e.g. it should benefit more
then 50%, I usually set the bar higher early on like 80%) and if it passes
that then it would be defined and put on the development schedule, but it
should not disrupt the existing planned sprints on the roadmap. That means the
client might have to wait to get this new feature, but the benefit is the
product can be designed, kept reliable and stable and not get polluted with a
bunch of make shift code and hacks. None of this has to be a crazy long
process, it can be simple and quick and if sprints are 1-2 weeks, most likely
many features can fit within the next 30-60-90 days at most (obviously
assuming proper staffing etc).

The sales side of the business should never be in control of the development
schedule, or product roadmap, it is a direct conflict of interest. Product
management should be owned by an operations type person, CTO, COO but for sure
a non-sales, and/or marketing focused person. This is what will make the
company successful faster and help keep the product stable and on schedule.
Founders when small have to wear many hats so they will be violating this all
the time, but by the time they have hired a product manager, sales teams etc,
the hacky crap has to stop if they want to succeed.

None of this means a client (or business) can't get a new feature turned
around pretty quick, it just means that there is alignment of features to more
than one client and that product stability, reliability and schedule are
managed as first class problems. Startups struggle with this thinking it will
slow things down, and they will lose deals, when in fact it speeds things up
and makes everything more predictable. The key is requests can be done faster
when the development teams can keep tech debt low and design things into the
product properly. It also prevents the scrap it and rewrite it that happens
when you don't plan well enough. To be fair, there is almost always 1-2 scrap
code repositories early in the life of a startup, but it doesn't have to be
that way, just usually works out that way because of people repeating
preventable mistakes they haven't yet learned.

I do think it is important to recognize when you are first starting the
company it is more free for all, scrappy and hacky, but even in those
circumstances you should not be implementing features just because one client
made a request.

------
jokull
Your job is to bridge business and engineering. If both of these sides trust
your judgement your job is easy. You will win arguments when you can translate
between these sides. Turn business concerns into engineering projects and
express engineering projects in terms of business outcomes.

------
metreo
Are the clients paying you to fulfill their requests or are you just making
their unfunded dreams come true? If they are paying is it a reasonable
proportion of the cost for your teams development work? How strong was the
product vision originally?

------
ddrt
Use roadmunk or Asana because they have timeline view. Stakeholders love that.

The right way is to collaboratively change your roadmap over time. The wrong
way is to restrictively stick to spec from the start.

Roadmaps are not things like Jira tasks, and vice versa.

------
johnxie
> the business team is constantly changing priorities based on new client
> requests, so the tech team cannot cope with all the new features and these
> end up suffering continuous delays.

I would recommend...

— keeping a list of feature requests sorted by popularity, number of client
requests, and impact to your KPI / north star metric

— prioritize each milestone / sprint based on this list, this can be for the
next week, month, quarter, depending on the complexity of the project, then
measure

— agree with the management team to not change the priority midway unless
there is a very good reason to do so

You can use a variety of tools to do this, from the traditional Google Suite
of tools to more specialized task management tools like Asana, Trello. We
mainly use a combination of GitHub issues and Taskade (our own tool) to do
this.

------
z3t4
there are two types of features: 1) Features that affects the overall product
2) Features that makes life easier for users

For the first category you need to look at the whole picture, as they often
affect many parts of the system, and there need to be a coherent
strategy/plan.

For the second category, just go ahead and implement any such feature if have
the time to do so. But don't forget that all new features have a future cost,
as users would miss those quality of life features if you remove them in
future versions.

------
aprdm
I would actually recommend reading Steve Jobs biography. I know it seems weird
but the guy launched products that changed the world. I think seeing how his
brain worked with products could help a lot.

I believe a big problem for getting a good product roadmap is very
fundamental... we don't truly believe on the products we are working on or in
the company we are working for. Is just a bunch of people with no real vision
trying to influence one another over ego.

And then you have Sales of course who can actually talk smooth and influence
better those who aren't sure about why they do what they do...

fraserharris (1) is about bigger vision. That's what I think makes a good
product road map. A vision, extreme focus and caring about it.

~~~
jariel
The sales team is more important than 'vision' 9 times out of 10.

In consumer, where the customer may not really know what they want, and can be
convinced, it's more about vision and how that aligns with smart marketing.

With B2B the sales teams are it. Customers may also not know exactly what they
want, but some discussion there will suss it out.

Note Apple was always pretty terrible in B2B, you wonder why?

~~~
aprdm
I think with no vision is really hard to build a good product and without a
good product what exactly are you selling?

I think sales is super important yes but it sort of works after having a
product.

It is just as important for a company since no sales == no money coming in.

I guess in the context of this topic I believe that to manage a product
roadmap effectively having a strong vision for the product is fundamental.

~~~
jariel
Sun had vision, I don't think Oracle ever did.

I don't really think salesforce's early 'no software' bit counts as vision
either. Maybe.

There are huge swaths of mundane companies that make up most of the econony,
wherein I would say there's a lack of vision in the way we understand it. What
they have is operational tenacity, rigor, professionalism, and a near term
vision to 'make money'. For better or worse, that's what we have.

------
HatchedLake721
I haven’t personally used it, but I keep hearing good things about
[https://canny.io](https://canny.io)

------
trastentrasten
Won't solve your problem as it seems more structural. But perhaps a tool could
bring som clarity - check out Featmap (www.featmap.com).

------
evanwolf
You already know the answers. Sprint to build flexibility, infrastructure,
table stakes, and other goals that are broader than any one customer.

------
coder1001
Any good courses anyone can recommend on tech product management? Seems like
very relevant here.

~~~
skaber
Strategyzer.com has great resources and courses, and all of their books have
been valuable to me. Starting with value proposition canvas and business model
generation would be my suggestion.

------
werber
I feel like it’s a lot of listening and some black magic.

------
sgammon
productboard.com

honestly the best tool i've ever used for this. and phenomenal software in
general.

~~~
tomashertus
Amazing tool. Won’t solve this problem. It might help with clarity and
organization. But he is talking about structural problem.

~~~
mud_dauber
Seconded.

------
sturza
what do you mean by product velocity? is it development team velocity?

------
lantyr
agreed

------
qwertyuiop12345
bfgv

