The answer lies in the breakdown of how the organisation intends to hit it's
goals.
See this answer for context -
https://sharebird.com/h/product-management/q/how-do-you-handle-exec-input-in-the-roadmap-and-convey-a-point-of-view-while-also-accommodating-1
To take an extreme example, if 70% of the organisations revenue target is based
on the acquisition of new customers then that's a good guideline for your
investment levels, eg
65% - Prospects
25% - Existing customers
10% - Tech debt
Roadmap Planning
6 answers
VP Product, Airbase | Formerly Skype, Microsoft, Blink and Pipedrive • March 8
Director, Product, GitLab • March 31
I typically start from what are the annual business targets set by the company
to answer this question. Oftentimes, the sales organization, CEO, and
professional services organizations have targets around expansion, new logo
acquisition, and win rate which will help portion out what the backlog needs to
be to support the business goals.
In absence of these targets set by leadership, I would use a RICE framework
(https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)
to establish what is the highest value driver for the business. That way I am
not really focused on driving whitespace or greenfield, rather on what will
drive the most business results in total.
I find that this type of division can be misleading. In many industries, there
is little difference between what an existing customer would want vs what a
prospect would want. Many times, the two would like to see the same kinds of
capabilities built (but their priorities might be different). I think more about
the buying centers I’m targeting, the use cases they have that my product can
solve, and prioritize the roadmap based on the importance of those.
Director, Product Management, Splunk • September 13
Great question! This is something most product teams wrestle with when only
looking at the roadmap from a features perspective to balance what to build for
existing vs prospective customers. What I’ve found very useful to address this
is to revisit the product strategy and business drivers for the product and
align the roadmap accordingly. For example, if you assess your product strategy
and look at the data for your business drivers, you may see a trend that
customers really start adopting your product in years 2-3 with 10x revenue from
their initial purchase, what decisions would you make? One decision could be to
build more features to get more prospects because you know it will pay off in
years 2-3. OR, you could decide to focus on existing customers but learn from
your customers why adoption is lagging and then focus on solving your customers
needs to speed up adoption so they get value earlier from onboarding or within
the first year and shift that 10x revenue earlier in the cycle for your
business.
In short, I found it best to revisit the product strategy, and leverage data
from customers and business drivers to make an informed decision on how to
position the roadmap for existing vs prospective customers. Once you identify
the customer or business outcome you want to drive, use the roadmap to deliver
that outcome.
Sr. Director of Product Management, Splunk • October 31
In a perfect world, you want at least 80% of your roadmap to be applicable to
both! But, we don't live in a perfect world, do we?
Some startups focus on a small number of customers and really customize the
product to the desired features of those early users, but I like to first go
broad in appeal, and then deep into a few features that are highly impactful to
as many users as possible.
If you want to reach a new type of user, solve a new use case, or enter a new
market, you will have enough of a reason to build something exclusively for
prospects. This is a strategic decision to expand your business or market
footprint.
A great way to determine if your roadmap is mostly applicable to both prospects
and existing customers is to build a way for existing customers to submit ideas
for the roadmap, and let your entire customer base upvote their favorite ideas.
The more votes, the more likely both existing and new customers will benefit
from the roadmap idea.
Sometimes, however, you'll have a big customer needing something specific, and
there will be many reasons to build something unique, often influenced by the
size/revenue impact of the customer. I don't usually let more than 5-10% of the
roadmapa focus on one-off, custom features.
Director of Product, Splunk • January 8
Who to focus on often depends on the maturity of the product. At the beginning
stages of the product, we focus heavily on prospective users. When the product
is mature, we focus heavily on existing customers (the thinking is -- if you can
deliver impact to existing customers then prospective customers will likely find
the same features useful).
Additionally, who to focus on can depend on whether your company is driving to
satisfy existing customers vs working to attract new customers.
4 answers
Director of Product, Fulfillment, ezCater | Formerly Wayfair, Abstract, CustomMade, Sonicbids • August 14
I've had to manage a couple different pivots like in my product career. What's
worked best in terms of communicating is the following:
* Making clear the "why" behind the pivot, and the risk associated with not
pivoting
* Stating clearly the underlying first principles or vision for the pivot that
exists today (it doesn't have to be super detailed - but this more about
acknowledging what you do know or what you believe should be true)
* Acknowledging clearly that the roadmap will be in flux for some time, and the
short-term is around building learnings and certainty around a long-term
strategy
* Committing to some series of regular updates (I like every 2 weeks - if
you're not learning enough worth sharing in 2 weeks, you're not pivoting fast
enough)
* Following through on those updates, and keeping them as crisp and simple to
understand as possible. Bulleted lists usually work well for me.
Director, Product Management, Splunk • September 13
I’m wishing you a successful product pivot! You got this!
In this situation, you have your internal stakeholders (sales, marketing, GTM,
etc) and you have your customers you need to reset expectations with (mostly for
B2B products, less so for B2C)
For your internal stakeholders, the best thing you can do is be transparent and
bring them as close as possible to what’s happening. For example, share the
challenges, the tough trade off considerations, data you are using to drive your
decisions, etc. This builds trust and partnership. Once you do that, sharing a
short term roadmap will be more understandable and you can always provide a DFAD
(date for a date) on when you expect to know more or have more things planned
(milestones).
For your customers, also be transparent about the pivot and why you are making
this change. Hopefully this pivot is ultimately for the best interest of your
customers. Also, what works really well is if you take the opportunity to
solicit feedback from your customers about the pivot and get some insights from
them. This builds trust and a stronger partnership with your customers. And
since you can’t share plans too far out, a DFAD is also good to manage
expectations with your customers.
Sr. Director of Product Management, Splunk • October 31
I think you say exactly that!
"We're pivoting our product. There are a lot of unknowns. It's hard to plan our
roadmap too far out. We're resetting expectations on how much we can
communicate..." THEN, I would add this...
"We are focusing on these 3 themes in this priority - 1... 2... 3...Our goal is
to deliver these X, Y, and Z customer outcomes by pivoting our product. We plan
to have an update on these themes in ABC timeframe."
It's ok not to have all the answers in times of big change and ambiguity. If you
did, you'd probably be guessing at best! And that's the fun - figuring it out.
Director of Product, Splunk • January 8
Say exactly that "We're pivoting our product. There are a lot of unknowns and
it's difficult to plan too far out." It's perfectly fine to communicate
honestly. If there's a good reason for the pivot, no one will fault you for it.
If you're able to have direct conversations with customers, it's important that
you set up these conversations. Having open and honest conversations is
important to build trust despite the pivot. It is also an opportunity to solicit
feedback and listen to your customers.
Resetting expectations internally within your company will be much easier if you
have already held conversations with customers. You can leverage these
conversations to prove that the new direction has been validated by your
customers.
In any case, pivoting a feature or a product can be stressful. But it's also
fun.
How do you balance "must do" work (compliance, maintenance, etc.) with objective/goal oriented work?
3 answers
Director of Product, MikMak | Formerly Discover, IRI • September 30
The balance/percentage should be agreed upon by the EM and the PM and shared
with the broader org for visibility. For example, in a team of 5 engineers, one
engineer's time could be set aside for 'must do' work and the rest will continue
to focus on goal strategic efforts. Similar approach can be applied if the
organization is big - eg. one pod assigned for maintenance work and 2 pods
working on strategic efforts.
In the end, key is alignment with the broader organization and stakeholders so
right expectations are set!
The main risk is constantly deprioritizing the Compliance and maintenance work
and building a tech debt at such a level that it will take forever to pay it
back.
There are two kinds of situations:
1- you do not have a vast tech debt, and you can manage compliance and
maintenance work by allocating a fraction (10 to 30%, depending on the amount of
work)of your capacity to this work. The remaining capacity work on
development-related work.
Alternatively, whenever a developer touches a part of the code, you impose that
he improves (or maintains) a part related to what he just changed.
2- You have let the tech debt grow out of control: you will have no more choice.
You will need to allocate your capacity to pay the tech debt before you go "tech
bankrupt."
When the tech debt is back under control, you can apply the rules stated in 1st
paragraph.
Director of Product, Splunk • January 8
Before jumping into the "must do" work, it's best to understand the reason for
doing the work.
Sometimes the "must do" work is warranted. For example, compliance could have
high customer impact which naturally means that it'll get prioritized anyways.
Sometimes the "must do" work is not impactful. For example, there might be a set
of maintenance tasks that is necessary but it's highly manual and repetitive.
While it needs to be done, it's more exciting for the team to reduce/eliminate
this work through automation than continue doing it over and over again.
At the end of the day, there will always be some level of "must do" work. The
key is to reduce the unimpactful/repetitive tasks. Once those things are
eliminated, the team is often happy to take the more impactful (even if mildly
annoying) "must do" work.
6 answers
Director of Product Management, Braze • February 8
Let’s say that a product team and an executive team are aligned on the goal of
improving customer satisfaction with the product (measured by a CSAT survey).
The product team will then do research and perform experiments to validate the
best way to impact customer satisfaction. Including executives in the research
process via stakeholder interviews is a great way to get input early -
executives are viewing things from a much different perspective than team ICs
and often have great ideas. When the team prioritizes opportunities to pursue,
the framework they use for prioritization can also be used to convey their point
of view on the best way to impact customer satisfaction.
If an exec suggests making an adjustment to the roadmap during the team’s
roadmap review, seek to understand why and dig into their thought process. Then,
seek the truth. Is there a quick way to validate or invalidate the feedback?
What does the objective evidence point towards as the best opportunity to impact
the goals?
For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro
which has a chapter on working with executives.
VP Product, Airbase | Formerly Skype, Microsoft, Blink and Pipedrive • March 4
Exec input is key so that you're aligned on the company goals.
First get a breakdown from the Execs and finace on which levers the company
intends to pull so that it achieves it's goals, and then categorise, eg, X% from
new customers acquired , Y% from existing customers , Z% from cost savings.
Then map the biggest customer problems to each of these categories - this gives
you your key themes.
Now that you have this mapped out
1. First playback your understanding of the importance and priority of each
category / lever
2. Second highlight the customer problems that align to each category
3. Finally flag high level features that map to the each customer problem. -
Ideally you don't even need to show this as the feature level conversation
becomes far less relevan once 1 and 2 are understood
You should now be getting useful feedback at the appropriate level and steering
clear of the feature level discussion which will likely be a distraction.
Director, Product, GitLab • March 31
This is certainly a tricky one! I like to think of a roadmap being made up of
four sensing mechanisms:
1. External stakeholders - investors, board members
2. Market landscape - competitors, analyst reviews or reports, and prospects
3. Internal stakeholders - CEO, leadership, cross-functional teams
4. Customers - install base or existing paying and free users
When you are able to attribute the sources of your roadmap features
transparently, it becomes a trade-off conversation with executives - rather than
a top-down mandate. Being able to show that certain bodies of work have been
sourced from competitors or analyst reports which show that you may be lagging
behind, for example, is a great dialogue to have when it comes to prioritizing
the input from the executives.
If the feature request should get done because you have applied a RICE score or
some other type of validation, sequencing behind the most impactful items will
be a great way to accommodate the request while delivering the most impact.
The most helpful way to maintain alignment with the exec team is to align early
and often on the product vision and strategy. Those conversations will likely
surface gaps or areas of misalignment that you can address or close at the
strategy level before you ever get into a roadmap discussion.
If however, you find yourself at the receiving end of some exec input that isn’t
aligned with a strategy you have socialized, there are several ways to handle
it.
1. Pull the suggestion into your input process and work the idea through your
product development lifecycle to see if it will make it through your process
fairly and as intended. Many suggestions will likely fall into this bucket
and will eventually land on the roadmap, but the tricky part will be keeping
the exec in the loop about the progress.
2. Sometimes, the suggestions are fantastic, but the team is occupied with a
longer-term project that is sequential in nature and it would be extremely
disruptive to their progress or their morale to reprioritize something else.
In this case, I’d raise this concern to the exec in question. Compliment the
value of the idea, and mention that the team is not quite in a good place to
take it on, but that you will explore it with them as soon as they complete
their current work stream.
3. The suggestions could be coming quickly and often, and way too frequently
for your team to be able to accommodate them. In this case, I’d leverage
tradeoff conversations. If this new idea is going to be prioritized on the
roadmap, what item (of equal or greater effort) comes off?
4. There are scenarios in which the suggestions are not aligned with the
product strategy and vision the team has agreed to. If that’s the case, it’s
important to surface it so that either the strategy can be adjusted to
accommodate more of what the broader team was expecting or to stop
investments like these from distracting the team.
Sr. Director of Product Management, Splunk • October 31
Executive alignment on your roadmap is pretty key to getting funding and
resources to deliver on your roadmap.
Your executive team probably cares about customer success, growth, and
potentially things like margin/security/compliance.
Tie your roadmap to these outcomes very clearly. If you can communicate very
clearly HOW your roadmap item helps achieve more than one of these outcomes /
benefits, you are more likely to get buy-in.
What happens when you disagree with the executive? Well, that depends on whether
the exec is challenging your roadmap prioritization to understand where you're
coming from as a mechanism for providing feedback OR if the exec is
communicating a mandate to accommodate a strategic initiative. There's a
difference. For the former, you can make sure to communicate how your roadmap
helps achieve those desired outcomes. If the latter, accommodate away.
Director of Product, Splunk • January 8
It's always good to review roadmaps with leadership on an ongoing basis. These
touchpoints allow you to keep your leadership informed and give you the
opportunity to solicit feedback.
At the end of the day, gaining alignment is key to getting funding and
resources. The leadership team is often looking to understand how your product
is doing (e.g., usage, adoption, success stories) and how your roadmap can
deliver additional impact (e.g., growth in usage, adoption, customer happiness).
Clearly communicating how the roadmap can deliver outcomes will help you get
buy-in.
While unlikely, your leadership can use their power to overrule and change your
roadmap. When this happens, kindly ask your leadership to help you understand
why they are asking for the change. If the rationale isn't sound, it's ok to
push back. If the rationale makes sense, use their line of thinking to help your
team understand why the roadmap has changed.
3 answers
Director of Product, Fulfillment, ezCater | Formerly Wayfair, Abstract, CustomMade, Sonicbids • August 14
Everywhere! Users themselves, colleagues, market research, competitors, randomly
in the shower. Generally, I like to consider each idea seriously and work
through a few questions to help decide if they are worth building:
1. What, fundamentally is the problem this idea is meant to solve? How worth it
is solving that problem vs. others I know about? Does solving this problem
create opportunities or risks in any form that I should think about?
2. Is this a problem I need to solve now, in 6 months, in 2 years, etc.? What's
the risk of just putting it off?
3. Has this idea been validated in some form already? What's the "why" behind
this being an idea? Is there a good hypothesis around it?
4. If it hasn't been tested yet, is there a low-cost iteration of this idea
that my team could build and test quickly? What (rough swag) impact or
learnings could a low-cost iteration yield?
This feels like a lot of questions, but I've gotten good at answering them
quickly with a few driving assumptions to help keep myself moving. This is
really hard early in one's product career, and potentially when you're working
in a very new job or problem space - but as you ramp up, you start to be able to
answer them faster.
Group Product Manager, HubSpot • October 9
This is a two-part question. Let me first articulate how I like coming up with
ideas for new opportunities, followed by how I like to make decisions about what
to build. Hopefully, you don’t mind that I’m thinking about “opportunities”
because it might not always be a feature that’s the right solution.
I should start by saying that there isn’t one right approach to coming up with
ideas. In my experience, I’ve had success ensuring that there are:
1. Insights from the four lenses: Customer, Business, Market, Technology
2. Effective methods to facilitate ideation
At the core, you have to have a deep understanding of the underlying user pain
point you’re trying to solve through a thorough investigation of the Customer by
talking to customers and product usage. You might actually learn very quickly
that the user problem is around discoverability or activation, not necessarily a
feature gap. Ideally, the customer impact is so deep that it translates
effectively into Business impact. The Market context is critical to help
understand how your user will experience the product within the broader
competitive landscape and the direction an industry is headed. Finally, the
Technology lens offers insight into what capabilities could be used as part of a
solution.
Preferably, these four lenses come together through cross-functional ideation
that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market
teams). In a hybrid world where we’re working across time zones, I’ve enjoyed
having the opportunity to ideate together synchronously and asynchronously.
In terms of decision-making, the ideation process should lend itself to initial
layers of prioritization. I won’t go into prioritization frameworks here, but
there are many out there. They do tend to distill back to impact and effort and
sequencing. At HubSpot, depending on the type of decision we are trying to make,
we may use a “driver, approver, contributor, informed” DACI model used by other
companies we admire like Atlassian.
Director of Product, Splunk • January 8
Ideas can come from many places. They include customer feedback calls, customer
troubleshooting sessions, customer submitted ideas (at Splunk, we have an idea
submission portal called ideas.splunk.com), conferences (at Splunk, we host
.conf where we have the opportunity to meet many customers in person), ideas
from your engineering team (they generate some of the best ideas), and ideas you
dream up yourself.
Once there’s a list of ideas, we typically do a full re-prioritization at annual
planning. Throughout the year, we also slot in new ideas and do minor
re-prioritization as things change.
1 answer
Director of Product, Splunk • January 8
When I prioritize or stack rank a list of items, I typically find it helpful to
understand how each item can (a) deliver customer impact and (b) increase
engineering happiness. Additionally, I also find it helpful to understand each
item's level of (c) feasibility, (d) urgency and (e) effort.
I weigh customer impact and engineering happiness at 50:50 -- after all, you
need to make your customers happy while also keeping your team excited. Things
that are less feasible are often pulled down the list. Whereas things that are
higher urgency or less effort might be pulled up the list. At the end of the
day, prioritization is an art.
5 answers
At Momentive there are several stakeholders that have input into our roadmap, a
few main partners and collaborators are listed below:
* Other Product & Design Teams
* Sales/CS teams
* Marketing & Growth
* Research
* And more…
Most cross-functional partners just want to be heard and want to understand
whether their requests will be addressed or not. This is why transparency is a
key element in all 3 of the following tips to help you maintain the balance
between influence and control:
1. Give your cross-functional partners an acceptable avenue to advocate for
customer requests and surface themes they are hearing from the market. We
have a very specific process for capturing requests. All requests get routed
through a feature request or feature feedback form that is centralized for
our product team to analyze and address. We look at the data coming through
those channels monthly and roll up the insights quarterly. The expectation
is set that we will evaluate all requests but that there is no commitment to
addressing any specific requests. An important aside is - As a product
leader, be grateful for the feedback that you receive, there are many
organizations that aren’t benefiting from the insights you are getting
straight from the customer-facing teams.
2. Help your cross-functional teams feel heard; be transparent about realistic
outcomes they can expect. In all of the organizations I’ve had the privilege
of working with, the friction between cross-functional product requests and
roadmap prioritization was anchored on a misunderstanding of the product
management function. Helping your cross-functional partners understand your
process, their input’s role in it, and the outcomes that result should help
alleviate some of the pressure to “just put it in the roadmap”.
3. Close the loop - even internally. My team has a quarterly meeting with our
cross-functional partners to give them an update on 1) the requests we’ve
received, 2) which items have been delivered, 3) which items are in
progress, 4) what our current expectations of delivery are, and 5) which
ones we’ve recently received. We also address the items they have requested
that we will not be delivering and do our best to explain why (e.g. not
aligned to our current strategy, not a point of differentiation, we don’t
have resource capacity for another large initiative right now, etc). This
meeting alone has had an incredible impact on our ability to keep our team
aligned with our cross-functional partners.
Director of Product, Fulfillment, ezCater | Formerly Wayfair, Abstract, CustomMade, Sonicbids • August 16
It depends on the role and problem space, but I try to invite (1) virtually
everyone I collaborate with on a regular basis, (2) their management/leadership,
and (3) fellow PMs as partners in the roadmapping process. I think it's
important to think of stakeholders more as partners in the roadmap creation
process, since their ideas and input really shape my POV on what's important
there.
Influence vs control is interesting. I've been in situations where stakeholders
are pushing for specific features on the roadmap, which isn't necessary bad in
itself - but it's important to (1) make sure it's clear *why* those things need
inclusion, and (2) that if they are not included in a roadmap, you have a clear
justification as to why. That could be for a lot of different reasons (eg.
sequencing, technical effort, lack of certainty/understanding of impact, etc.)
but it's important to clarify why you, as the PM, have decided to deprioritize
thing A instead of thing B. A helpful tactic here to suggest influence without
losing control is to propose an alternative placement for the given thing on the
roadmap. For example, if it's risky to tackle thing A in Q1, don't just explain
why, but also provide some rough guidance as to where thing A may end up as a
result.
Lastly, I think word choice matters here, and commnunication tactics help. I've
found success in "proposing" a roadmap, alternative prioritizations, alternative
framing; giving stakeholders a deadline by which to provide feedback; expressing
support for ideas even if they are not the most important ones at the moment.
Director, Product Management, Splunk • September 13
I appreciate this question! Generally speaking, we get inputs mostly from sales,
customers and product/engineering. I’ve used the approach of building
partnerships with stakeholders and that takes care of the influence vs control
dilemma. When you have a strong partnership with your stakeholders, they trust
you that you’ll make the right product decisions and in turn, you show that you
value their inputs. So I would encourage you to think more about building
stronger partnerships so you don’t have to struggle with influence and control.
Sr. Director of Product Management, Splunk • October 31
Prioritization is more art than science. My goal is to actively listen to all
stakeholders and help communicate how I make tradeoffs and how that impacts
timeline to deliver a requested feature.
But as a rule...
Customers have the most impact on roadmap.
Then engineering (especially on tech debt, architecture, compliance, and quality
improvements needed).
Then, I weigh any influence from market trends and changing competitive
landscapes. Here, I consult with analyst relations, product marketing, and
competitive intelligence.
Then sales/CSM/support to learn trends/issues they're experiencing directly with
customers or issues selling.
And sometimes, executive input will trump everything else - but that doesn't
happen as often as you'd think unless you work in very top-down work culture.
Ultimately, as the product manager, it is your job to make the final call on the
roadmap prioritization. It is your primary responsibility!
Director of Product, Splunk • January 8
In my mind, several groups of stakeholders often influence the roadmap. They
include your customers (both internal and external), your product team (e.g.,
engineering, design, data science), your internal non-product stakeholders
(e.g., legal, compliance, sales) and your leadership.
From these stakeholders, it's important to put most of your focus on the ideas
coming from your customers and ideas generated by your team. While we all like
to work on things that benefit the customer, it is equally important to make
sure that your engineering team has the opportunity to work on technically
challenging projects even if these things don't always directly benefit the
customer.
Then, there are times when your leadership would trump everything. Believe it or
not, this doesn’t happen often.
6 answers
Director of Product Management, Braze • February 8
Good framing is essential for effective prioritization, especially in cases
where departments have different perspectives on what to prioritize. In many
companies, including my own, the sales team is an important stakeholder in the
product roadmap.
When working with other departments or teams, you want to ensure that there’s a
common language in which to communicate. For example, are both departments
aligned on the prioritization of high level business goals? Is there a clear
ownership model?
Once there's tentative alignment on these topics, it's much easier to have an
objective discussion about the opportunities to influence a goal. At Braze,
feedback and observations from Sales and Sales leadership is one of the many
inputs that we incorporate into forming a perspective on the best way to achieve
high level business objectives.
VP Product, Airbase | Formerly Skype, Microsoft, Blink and Pipedrive • March 4
What are your company goals for the year, and how much is dependent on new sales
vs retaining exist customers and growing customers?
It's important to know, as It can cost five times as much to attract a new
customer, than to keep an existing one. But if there is no clarity on this, ask
the execs - What % should we allocate to new sales? An effective leadership team
should be representiative of other voices too , like marketing, customer
success, support etc. Make sure you reflect that voice back effectively.
Bring your data to the table so that you can share your perspective on the risk
to losing existing customer as well as the oppotunities to upsell or cross sell
to them.
Bear in mind that sales typically drive incremental growth not exponential
growth, so manage expectations accordingly The Roadmap is a reflection of your
leadership's priorities, and it's your role to help them make informed decision
on investment priorities.
Director, Product, GitLab • April 6
Well, I often incorporate multiple sensing mechanisms into the roadmap - the
field and sales team are definitely an important lever to drive revenue, which
really is why product managers exist.
So, a tactic I use is to show how much of my engineering capacity is dedicated
to enabling revenue, technical debt, and long-term vision. The long-term vision
is often a "big bet" that is about making a splash in the market or analyst
review. Oftentimes, sales and the field are supportive of carving out time for
long-term bets because analyst ratings, whitepapers, and affirmations of the
product in the market are great supports for the sales cycle.
Director of Product, Fulfillment, ezCater | Formerly Wayfair, Abstract, CustomMade, Sonicbids • August 14
Autonomy is certainly a desirable aspect of product work, but it comes with
time. To gain autonomy, you need to first build trust. Start by not assuming
your sales team is wrong (I realize this is blunt, but worth saying). They spend
their days talking to users and prospective users and probably have a good idea
of their pain points. They may not always be thinking about creative solutions
to those pain points, or have a good product sense, but it's unwise to assume
those ideas are fundamentally wrong - they may just not be ideal, or quick to
market, or they may be a red herring for a different underlying problem.
Engage with your sales team and really invest in learning their perspective,
offering your own fresh insight and perspective and working together on the
solution. This helps build camaraderie and trust, builds your understanding of
the customer problems you need to solve, and potentially gives you some quick
early wins to work with. If the roadmap that results is not 100% "yours" and
involves a lot of heavy input from sales, that's okay. It's important to note
that no PM is truly fully autonomous - you lead and support a team of different
people in different functions, and inputs from those folks are invaluable.
Over time, you'll have a more confident understanding of your users, and your
sales team will trust you with that confident understanding.
Director, Product Management, Splunk • September 13
I like this question because it is such a classic situation. I’ve seen this
played out at companies and it’s likely a culture issue that it’s very hard to
change unless the Product and Sales leadership teams get together and have a
heart to heart about it and come to an agreement on the best path forward.
Getting the autonomy you are looking for starts at the top and it has to be a
coordinated effort to address the culture and behavior.
On the other hand, it’s great to get sales input into your roadmap because they
are out there daily with customers. If you are looking for a grassroots approach
to autonomy, one suggestion would be to ask sales for a prioritized list of
their requests (with a business case) and agree on a number of requests you’ll
directly add to your roadmap each quarter. This provides sales a window to your
roadmap while providing a balance for you.
When departments have different opinions on prioritization, the product manager
needs even more to have a transparent and data-driven prioritization method.
Sales is a very important source of prioritization, and the art of product
management is to find the right balance between supplying features that will
unlock further sales, features that will please existing users, and resolving
bugs and tech debt.
The old say "it is less expensive to keep an existing user than to acquire a new
one" remains true and needs to be embedded in the method.
But a good product manager is one who knows how to stay firm with his
prioritization in front of all stakeholders without confronting them.
2 answers
Director, Product Management, Splunk • September 13
Thanks for the question! You, my friend, are in a coveted position. I would
encourage you to shift your mindset and look at it as an opportunity to
influence and educate your leadership team on what you know about your customers
and create a vision and strategy for your product to share with them. Since the
leadership team is new, you have the opportunity to show them that you are
proactively thinking about the product direction and execution versus waiting
for direction. So take a shot and give it your best.
This is the role of the product managers to bring up what the users want to see
built.
This is usually not good practice to have the executive giving too much
guidance. The executive should give the vision, and the product managers should
determine the features on the roadmap based on the prioritization they
determined with the users to achieve the vision.
It could be an advantage when the leadership doesn't provide guidance as it
prevents the bad top-down approach of product management. The executives keep an
open-minded approach and fairly evaluate the proposals made by the product
management.
2 answers
Our product development lifecycle process looks very similar to a double diamond
design process but with an adapted approach for our organization. While there
are best practices for a product development processes, I've found that there is
a decent amount of adaptation and adjustment that needs to happen to customize
an approach for the needs of the organization. I've not seen 2 product
lifecycles that are the same.
At a minimum, a product development process should help reduce friction for the
R&D teams, create clarity around what we need to know before we invest, and
insight into the variables that influence those decisions. The most mature and
refined PDLC programs also create consistant expectations of each role that
participated in the product development process, sets criteria for high quality
output, and provides clarity on what to do next through each stage. This is
extremely benefitial when you think about onboarding new PMs to the team, as
well as supporting the growth of PMs new to the role.
Depending on the needs and maturity of your organization, you can chooste to
implement a light version of this process that focuses solely on alignment and
rescource allocation, or lean more into a more detailed process that provides
more clarity on activities you expect the teams to execture for each stage.
A good process provides time and space for the team to engage in activities
focused on discovery, exploration, and time in a particular problem space. In
this stage. you should avoid solutioning at all costs.
There should be a stage for concept exploration, and I strongly encourage my
teams to explore more than 1 concept. Sometimes the first concept we surface is
not the best for the job, but inertia and time constraints prevent us from
exploring more. I recommend my teams take the time, because it saves us on the
rework later.
Once a concept has been validated, there should be a stage that allows you to
define the high level requirements and start thinking about an experience that
would make it as easy as possible for customers to realize value from your
chosen solution for the problem space. For me, customer validation of the
specific execution is critical, because we are very rescource constraigned on
the engineering side. If I can prevent rolling out soemthing that needs major
rework, I will. Some organizations are more constraigned on the research or PM
side in which case you may use the experience itself for validation.
There are many types of product development lifecycles, and you should choose an
execution that solves the most prevalent R&D problems your organization is
facing.
Senior Product Lead, Shopify | Formerly Salesforce, Google, Nest, Cisco Systems • November 16
I don’t believe in a universal end-to-end product development process. I believe
there are key rituals and elements that should be present on every team to
ensure great outcomes, but each team needs to tailor the development process to
their unique situation.
My must-have product development elements & rituals:
1. Common Language - Your company should have a common language for the product
development process. This is not a prescribed way to do product development
for every team at the company (this needs to vary team by team for good
reason).
At Shopify, we call it GSD (get sh*t done). The base elements are a common
language around Product Development stages: 1) Proposal 2) Prototype 3)
Build. We have an internal system at the company where you can look at all
development projects and the stage that they’re in, how long they’ve been in
that stage, when they’re expected to go to the next stage.
We also have a common calendar of 6 weeks sprints that is used by the
company wide. This helps when you’re having a discussion around when do you
think you will have x? This transparency and common language is key.
2. “Agile Research” - This is a term I coined to describe the act of always
conducting user interviews. The problem with well-designed research projects
is that they take too long and tend to deliver the insights after you’ve
started building the thing. Advocate for a “rolling recruit” of your key
personas so that you can tap into talking to users *every week.* This
ensures you have feedback and insight in the moment you need it most before
the product is built and decisions are made. Alternatively, you can create a
type of Customer Advisory Board where members opt into research questions,
providing feedback, etc on an ongoing basis.
3. Continuous Product Discovery - A common misconception around PMs is once a
project is kicked off and being prototyped their discovery work is done.
Discovery is a never-ending job. There is a lot of work to be done up front
to define the problem and opportunity more broadly, but throughout the
development lifecycle there are endless sub-problems that need to be found,
defined and shaped.
4. Unstructured Live time with the Product Squad - At Shopify, we refer to this
as "Jamming." This is the schedule I tend to implement on my teams:
Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh
Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live
time with the Product Squad. PM, Eng, UX, and Data get on a call and stare
at the Problem or Prototype together. PM guides the Problem Shaping meeting
and UX guides the Live Prototyping meeting, but the purpose is to tap into
all the brains on the team to get to the best outcomes. It can be terrifying
for a lot of people. It’s like getting in the car without a destination in
mind. You need to create a culture on your team where it’s ok to not have
all the answers. To prepare, the PM can have “intended outcomes”, “problem
definition” or “options” prepared. During the meeting, the PM facilitates
getting insights from the group around what else to consider, what’s
missing, etc.
5. Progress every week - Another cultural thing - you need to have rituals on
your team to encourage and ensure progress is made in some way, shape or
form every week. My favorite way to do this is the weekly demo AND ensure
that not only eng presents, but also folks from PM, UX, etc.