This reminds me of an interview question I got a very long time ago: "Is it
better to have a bad team or a bad manager". In both cases, you'd rather not
find yourself in either extreme. In both cases, there is no right or wrong
answer and a lot depends on additional circumstances and assumptions. The answer
will also depend on your value system and the experiences which have shaped your
core beliefs about human aptitude and potential.
For the sake of argument, if I had to pick, I would first apply the same
framework: which suboptimal option is more mitigatable.
I believe that most people have the capacity to learn the facts of the domain,
the technical aspects, I.e. the hard skills, with sufficient effort and time. On
some level, I see acquiring the hard skills in this contrived case akin to
suceeding in a college course you know nothing about but are highly motivated to
ace.
The soft skills can also be learned, but these are much more entangled with
personality, self-awareness, communication style, etc., all of which develop and
become ingrained over the years. They are harder to inculcate artificially or to
undo as bad habits.
Poor soft skills can burn bridges and set the course of nascent relationships on
the wrong trajectory, impacting your ability drive results far into the future.
No amount of hard skills may be able to offset that. Good soft skills can even
buy you time to get up to speed on the hard skills, and can get you critical
early support from the team to actively help you get there.
This is why if I had to, I would pick the soft skills option.
Product Management Subteams
1 answer
Sr Director II, Product Management, Walmart • June 8
2 answers
While infusing ML into a product can be extremely powerful to light-up new
scenarios for customers and to optimize current scenarios, it can take a lot of
effort to get it right. It all starts with defining and prioritizing the right
scenario/problem to focus on, working with data science and ML engineering teams
to map the business problem to an ML problem, trying out to different approaches
to identify the right one to go ahead with, experimenting and optimizing and
then operationalizing the approach and shipping it as part of product stack
working with ML engineering and development teams. In addition to focusing on
functional aspects and non-functional aspects like
performance/scale/reliability, ML scenarios bring in an additional critical
aspect of transparency and fairness which is broadly classified under
Responsible AI - this is required to gain customer trust and hence feature
adoption.
It is the responsibility of product manager to define the business scenarios and
success metrics to focus on, work closely with data science teams to map that
into ML problem and enable them with right data for them to come up with right
approach. Then work with ML engineers and developers to operationalize it as
part of the product. In summary, it take collaboration between multiple
teams/roles in order to ship great ML features as part of a product.
If you are interested in learning more, watch my session on AI/ML Product
Management:
https://www.linkedin.com/video/event/urn:li:ugcPost:6929801568753971200/
Director of Product Management, Speech and Video AI, Cisco • February 1
Implementing an ML feature vs a non ML feature is no different. The complexity
is how the ML model is integrated into the existing product, business or user
workflows, and how it might impact the overall end user experience. The goal is
usually to simplify and not complicate things. The goal is to reduce buttons and
not add buttons. The decision for ML features in a product is similar to the
other features -- ML is just the technology about how - under the hood. It is
not the end in itself.
As regards working with data scientists -- it depends on the feature. As PMs
where there might be significant impact on end user experience, it is helpful
that PMs keep in mind the ethics, diversity and inclusion issues to inform data
scientists about what to include when capturing data for training and testing.
It is important to have a good diverse test data set.
7 answers
VP of Product, Shopify • February 9
My personal take is that when I am speaking with strong product candidates, I
can see a few qualities shine through in their story. For me, those are:
1. They are constant Learners/curious
They are constantly asking questions and actively listening. They are readers
and constant consumers of information. To me, this shows that when they come on
the team, they will bring fresh ideas forward. Ask the team questions that
others may not consider and bring new information to the table.
2. They are persistent and don't stop at 'no'
In this, they are contantly trying to understand constraints and find
alternatives. They want to address a problem and flexibly driving towards a
solution that will do it. They do not get discouraged when someone says no.
Maybe they will flex their soft skills and coax a 'maybe' out of the person
saying 'no'.
3. Understand how to balance the art and science
Often times when we talk about product management, we talk about the science.
Your frameworks, how you manage backlogs, understanding data and tracking
metrics and all of those fun items. You'll find a lot of books on these topics
because they are measurable and easier to write about. On the other hand, we
often forget about the art. The way things get done. How you communicate, show
empathy, tell a compelling story and inspire others. How you connect with your
customers and their problems, lead individuals without authority. Normally when
a PM fails, it's because not enough attention is paid to the art.
4. Focus on problems not solutions
Often times when someone is describing a problem, you want to jump to a
solution. Technically product management is helping to solve a customer
problem... but to truly solve a problem, you must really fall in love with the
problem.
5. Able to represent multiple POV
They are able to advocate wearing different hats. So they can speak to engineer,
executives, marketing, the customer, you name it. They can comfortably devils'
advocate ideas and not settle for the first answer suggested. Often in the
interview process, you are meeting with different stakeholders and really they
are each approaching you with a different lens (or hat) to evaluate your ability
to breakdown a problem.
Product Management Area Lead, Asana • May 17
For me the biggest differentiator is having a growth mindset. This doesn't just
mean they want to make an impact and improve as a PM. For me it comes down to
three things:
1. They have a sense of what they know and don't know, and are always eager to
learn more. They question their own assumptions.
2. They're humble and curious in trying to figure out what they don't know and
leverage the expertise of others.
3. They frequently seek feedback from others and try to challenge themselves,
not just to achieve more but to be a better colleague and partner to others.
Senior Product Lead, Shopify | Formerly Salesforce, Google, Nest, Cisco Systems • July 26
1. They teach you something in the interview
I once interviewed a woman who had extensive experience working for a
telecommunications company. I have zero experience in telco – aside from being a
customer of Verizon Wireless. I walked out of that interview having learned so
much about telco companies, their business model, what they optimize for, how
they segment their customers, etc. In the stories the candidate told about her
work experiences she concisely weaved in the basics of the telco in a digestible
way and was very aware of the learnings and insights she had from her product
launch successes and failures.
As a product manager you’re responsible for the “what” and the “why.” What
should we build and why should we build it? If you’re able to succinctly
describe the what and the why of your current or previous roles -- no mater the
industry -- that’s a great indication of a strong PM.
2. They make it a two-way conversation. (See answer to “What are the most common
mistakes you see candidates make” question above)
Senior Director, Product Management, Headspace Health • August 22
A few things:
* A very deep understanding of the problems they are looking to solve. This
gets reflected in how they speak about past experiences (why did you choose
to work on a specific problem, what exactly was the need?) as well as any
case study (are they asking intelligent questions to understand the need).
* User-first approach: While solving the problem they identified, are they
putting the user at the forefront? Are they clear about who the users are for
the problem?
* Clear communication
* For more experienced positions and specific for B2B products, are they mature
to understand roll-out considerations for a large group of stakeholders? What
are the people and processes needed to make a roll-out successful?
Director of Product, Fulfillment, ezCater | Formerly Wayfair, Abstract, CustomMade, Sonicbids • November 7
I'll speak to commonalities in IC PMs since I have less experience hiring other
product leaders. It's really just 4 things in my view:
* A clear ability to break down complex, multi-faceted problems into
digestible, actionable chunks, as usually shown via some kind of case
interview.
* Excellent ability to ask good, tough questions
* A clear track record of having an impact and/or continuous
learning/improvement. This may not necessarily be demonstrated through
previous work as a PM, but the candidate is able to speak clearly to the
impact they distinctly had or the specificity of the learnings they captured.
* Genuine interest and energy around the problems discussed in the interview
cycle. This may show up in a case interview (ie. clear enthusiasm about the
challenge presented) or when asking questions about the role/company. I
always like to see how a candidate reacts when I answer questions about the
business/product, challenges we face, etc.
Head of Product, Enterprise Agility, Atlassian • November 9
Best product management candidates craft compelling, concise and inspirational
narratives when they interview. They demonstrate clarity of thinking, knowing
both the facts and the "why" behind their answers, and genuine curiosity. I
always walk out of an interview with a great product manager feeling like I have
learned something valuable, and inspired. I spoke to the skills I've seen among
successful product managers in another answer to the AMA, but if you are looking
to impress hiring managers specifically, I recommend practicing storytelling and
becoming a great conversationalist in addition to the core skills you need to
the job. The good news is that your conversational and story telling skills get
better the more you practice - and you are not limited to interviews only. Any
sort of verbal presentation mastery - Toastmasters, Improv and comedy, acting
classes etc. will help you become a master storyteller.
Product Leadership, Meta | Formerly Stripe, Flipkart, Yahoo • January 16
The best Product managers combine curiosity with structured problem solving
skills. Being curious helps them look at problems as opportunities to learn &
grow. Ability to frame & structure a problem helps them take others along in the
process. Both these skills can be learnt & cultivated over time.
Curiosity - Being curious is an under-rated skill. PMs who are curious keep
learning, adding new tools (ideas, PM techniques, s/w tools) to their expanding
toolkit and more importantly keep expanding their perspective.
Structured Problem Solving - Being able to frame a problem in a simple manner,
helps all cross-functional stakeholders & partners align on the problem
definition (yes, this is key), the solution and then the execution
I try to imbue these two values on a daily basis and this has helped me
seamlessly transition across AdTech, Consumer Tech, E-Commerce & Fintech. And,
it's a lot of fun!
2 answers
Group Product Manager, DocSend Growth, Dropbox | Formerly Mailchimp, Calendly • September 15
Ideally, you design experiments in a way that seek to answer a question
regardless of the result. For example, "do users not adopt this feature because
of discoverability or usability?" is a great question to be answered with an
experiment. If the exeriment execution puts that feature front and center of the
main page when a user logs in, and the experiment is flat, then you could be
pretty sure it's a usability issue. If it's stat sig positive, then you can be
sure it's a discoverability issue.
What's important is what you do after you've identified this finding. This new
information can inform your entire strategy of your team or you can pass it on
to another team for them to work on.
If the experiment results were flat or if the new variation performed worse, I
would suggest three steps in deciding how to pivot
1. Confirm it failed.
2. Dig into the data
3. Get user / qualitiative feedback
Confirm it failed.
* Did you run the test for long enough to get statistical significance? (How
long does an AB test calculator say you should run the test?) The most common
issue with AB testing is people calling the test with not enough data.
* Does the experience or part of the site you were testing does it get enough
traffic to be a good fit for AB testing?
* Review the user experience you just tested yourself. Were there any issues
with it you can see if you look at it with fresh eyes?
Dig into the data
* If the primary KPI you were testing is unclear/ low significance, is there a
clue elsewhere in the data which might give you an idea why the new variation
did poorly (worse results on mobile, better for returning users, or there
were more form errors - are all examples of issues which might give you an
idea on why the results were disappointing)
* What additional data sources can you look at to understand how users were
responding. For example, Amplitude, Hotjar, FullStory, Qualtrics, etc.
Watching some user sessions of people interacting with the variation can be
eye opening.
Get user / qualitiative feedback
* Ask users. You can survey test participants and see how the responses
different between variants, or if you have 'always-on' surveys on the site,
you can divide responses based on which variation they saw.
* If the experiment is critical to decide an important investment, you can also
do UserTesting.com style testing to understand how users were responding
better.
4 answers
VP of Product, Shopify • February 8
I personally believe this to be communication. Often times, we as PMs dive heads
down into a problem with understanding that we need to have a time with us to do
the work. It is important to develop a communication style that resonates
meaningfully with your audience. As a PM, you will need to communicate with:
1. Stakeholders
2. Peers
3. Direct reports
4. External partners
Each of these groups will require their own set of nuance that you will need to
determine based on the relationship you are working to develop OR need to
maintain. Often times when you see friction in organization, it comes down to a
miscommunication or lack of communication. It's better to set yourself up for
success here. My recommendation:
1. List your who your audiences are
2. Capture their needs and the required cadence for communication. Understand
the best mode to share communication, whether that is slack, in person or
email.
3. Kick off your process
4. Important step... ask for feedback frequently. You don't want to wait until
something breaks to know something is wrong. Ask people if they are getting what
they need from you until you feel satisfied you are meeting the mark.
Sr Director II, Product Management, Walmart • June 8
I'd love to answer this in a slightly different way: The single most important
skill, that cannot be rated highly enough is Communication. Many other soft
skills are fundamentally still rooted in or are dependent on communication.
Nuanced aspects of communication also matter:
* adapting communication to the audience and situation
* timing the communication
* communication in all forms: written, verbal, non-verbal/body language.
VP, Product & Operations (WooCommerce), Automattic • July 25
Sharp communication skills that enable proactive stakeholder management. This
doesn't just mean blasting memos and updates to everyone, everywhere – it
means:
* Speaking about what matters to who;
* Understanding what is the right timing;
* And knowing which channels are most effective for getting your point across.
In some organizations, you may be lucky enough to have a Product Operations team
to help you with that; in others, you won't.
Leaning into comms and stakeholder management means:
* Risks are assessed early;
* Issues requiring help are unblocked;
* Expectations are adjusted at the right time;
* And – most importantly – that your teams (from executive leadership to direct
reports to cross-functional collaborators) know they can trust you.
Product Leadership, Meta | Formerly Stripe, Flipkart, Yahoo • January 16
Empathy and the ability to connect with people across the board is the most
under-rated skill for high-performing PMs. Empathy enables PMs to connect dots,
build relationships, solve problems and dive-deep, to increase their expertise
PMs need to exhibit people skills that span three broad categories and empathy
for each of these different categories helps in its own way.
1. Managing XFN - PMs typically work with large cross-functional (XFN) teams and
need to adapt their working styles for each of the XFN teams, their involvement
in the product/ problem, the individual team members' seniority & their time at
the company. Initiatives that are amongst the top priorities for the company
might have a fully staffed XFN team and others would have varying degrees of
staffing. Likewise, new initiatives, esp 0-1 initiatives would have gaps in
resourcing and would sometimes be staffed with new hires or interns.
The ability to connect with people will ensure the PM is able to partner with
all XFN appropriately to get things done. For instance, at Flipkart & Rakuten,
we were resource constrained and I hired interns for our Tiger (Innovation)
teams. It was one of the most fun experiences I had since we could think big,
not fear failure and also time-box our work (to match with internship cycles) to
launch a prototype or pilot. Products such as Flipkart Merchant Ads, Flipkart
Funnel Attribution & R-Pay Merchant Rewards developed from these pilots
2. Team leadership - PMs, esp later in their careers, would be managing teams of
Product Managers, across their career spectrum. Every PM is different in their
approach, some lean on context, others lean on passion, yet others on structured
problem solving process and being able to identify what makes the team tick and
make them the best version of themselves in key! My team had Rakuten had PMs
that spanned multiple archetypes from the Captain (who likes to lead large
initiatives themselves), the Generalist (who can shape-shift to any project),
the Specialist (who likes to specialize in a domain), the Architect (Technical
PMs who like to build) and the Integrator (PMs who are good at managing large,
complex initiatives). Meta has an equally impressive range of archetypes for
PMs and more for TPMs & Project Managers.
3. Executive Presence - The last & most critical category of people
interactions for senior PMs is working with executives & Sr leadership in any
firm. Here again, empathy for the leaders, for the scale & scope of problems
they are solving, for what keeps them up at night, will go a long way in helping
the company, the org & the product team. Sr PMs need to think of themselves as
Chief Enabling Officers and the more they enable Executives, the more they
enable their own teams
3 answers
Director of Product Management, Carta | Formerly Salesforce, MuleSoft, Apple • February 3
There are different paths that each product manager takes, but the common ones
I've seen are:
1. Joining a tech company as an Associate PM or an intern straight from college.
For college grads, I suggest starting by connecting with other product managers
(e.g. via LinkedIn) to better understand what we do. There are great books
available on this topic as well -- "Cracking PM Interview" is among my
favorites. I also created a series of videos explaining tech jobs and what do I
do in more detail - https://www.youtube.com/channel/UCsAz_arwNkiPobhi09VrMFg
2. Transition from other roles e.g. Engineering, Professional Services, Support.
This path is easier, as it assumes that you are already in a tech company and
can make connections with internal PMs. Picking a PM as a mentor or just
becoming a friend with one is a great place to start. I also need to point out
that PMs sit at the intersection of Business, Technology, and UX (Customer) --
that is why engineers who transition to a PM team will have an advantage as they
understand the technology much deeper. On the other hand, someone in Support who
wants to become a PM brings a much deeper understanding of a customer.
Head of Product, Enterprise Agility, Atlassian • February 16
There is a fork in the PM career path road: one is becoming a people manager,
the other becoming an expert in a deep thinking product area sans managing a
team.
My recommendation is to figure out which one is right for you. Many folks want
to jump into management simply because they think this is the only way to grow,
make more $$$ and so on. That is not true. Big and small orgs I have been a part
of value senior individual contributors that are passionate about their
individual craft. Speak with folks from both paths, and see which one resonates
more with you. Try mentoring people and see if you like helping others succeed
through your guidance as a "management path" check.
Then, share your thinking with your manager to get them to help you moving along
this path.
Product Leadership, Meta | Formerly Stripe, Flipkart, Yahoo • January 16
This is a very interesting question and one that I keep touching upon on almost
all career conversations with my teams & mentees. There is no one typical career
path for PMs, which can be both liberating and challenging at the same time!
It's liberating since PMs have the chance to shape their careers to what they
would like it to be, playing to their strengths and having a fulfilling life &
career. It's challenging since every industry and many firms in the same
industry have different definitions & requirements for what a PM is! For
instance, even within FAANG firms, the definition of a PM is different - Google
requires PMs to market the work of their Engineers, Apple PMs are usually good
at their domain of expertise but execute on Sr Management decisions, Amazon PMs
are Business/ Program Managers with heightened focus on a few metrics, Netflix
PMs are very Technical (most of their PMs were former Engineers or Architects)
and Meta offers almost the full buffet but also the most agency & empowerment to
PMs. I touched upon some of the PM archetypes in another answer and its great to
see that PMs can succeed in any shape or form tht adds value to their firm!
PMs who are early in their careers will do well to join established firms to
understand the PM tracks and how senior PMs have shaped their careers. Working
in a start-up or a 0-1 environment usually turbo-charges a PM's career but only
if the PM is aware of their strengths & know-how to leverage them. I have found
that alternating between large firms & startups or between established products/
projects and 0-1 initiatives is the best way one can gain the most perspective
and shape their careers as PMs.
What do first time growth product managers get wrong, and how do you recommend avoiding those traps?
4 answers
Uber Head of Growth Programs, Riders, Uber • January 26
This is a tricky question. Lots of program managers struggle with prioritization
and impact analysis. They also struggle to get alignment on the prioritization
across among the stakeholders. Some of the best program managers are good at
understanding customer cohorts, their behavior on the application, and what they
like & dislike. Not understanding customer behavior leads to bad (or gut-based)
product decisions. Almost always, it comes down to first principles. Good
product managers invest time learning the customer.
Senior Director Of Product @ Upwork, Upwork • August 23
Avoid artificial growth! A good growth PM or a good PM, in general, will only
look for sustainable growth opportunities. There was this one time at Yahoo when
a bad growth PM said to me, "let's grow video consumption by auto-playing every
video on every page." This is a horrible idea because you will grow video
consumption at the expense of user satisfaction, and time spent. Doing these
types of trade-offs is NOT "growing," it's "trading". A good growth PM would say
"hmm let's find real opportunities where videos are not present but should be."
Group Product Manager, DocSend Growth, Dropbox | Formerly Mailchimp, Calendly • September 15
The number one thing first time growth PMs get wrong is only focusing on wins
and not involving their team. When creating a Growth squad, your number one
enemy isn't not making the number bigger, it's xfn attrition. Designers and
engineers who are new to Growth have historically been rewarded for releasing
new features. When joining a Growth team, you have to be able to prepare them to
launch something and then delete it. This is very new behavior and goes against
what they are used to doing.
So what do you do? You have to redefine how they value themselves. Essentially
get them to unlearn what they've been used to for the last 10+ years. It's no
simple task. But one of the greatest ways I've seen this get driven is by
involving your xfn partners (who are interested) in the strategy of what your
team will build. In that you are trying to move the number, but really, you're
trying to answer questions that will inform the strategy. By involving your xfn
partners there, they will feel rewarded when we answer a question and you help
proliferate that insight across the company. You want your team to feel a sense
of pride not just by moving the number, but by how you all affect the strategy
as a whole. Even if that means you didn't make any permanent changes to the
product.
Director of Product Management, ezCater • January 2
The key mistake new PMs make is focusing on delivering over impact.
It is inevitable that PMs hit a point where the backlog runs dry. The instinct
in this moment is to panic to get something ready for dev, push forward the
first idea that jumps to mind. The problem is this reduces the level of rigor,
making it likely the work will not have sufficient reach or impact to matter. It
also increases execution risk, increasing the likelihood specs are incomplete
and engineering has to work with partial requirements, like building without
design, that result in rework. In the panic to get this new feature out the
door, the PM likely won't have time to build a proper backlog and be in the same
spot a sprint later.
Instead, the PM needs to take the painful step of admitting fault and chart a
sustainable path forward. They can follow my process in a different question for
building a roadmap. Knowing that process will take time, the key is being clear
with engineering and product leadership on the process and rough timeline, so
that the team can be best utilized while the backlog is being built. This also
creates an opportunity for individual engineers to see the backlog building
process from scratch, giving them higher confidence and motivation when the work
is dev ready.
I should call out that it is not just new PMs who make this mistake. I've made
it myself many times in my career, so I know it is much more easily said than
done.
4 answers
Uber Head of Growth Programs, Riders, Uber • January 23
A traditional product manager is responsible for a specific set of features and
functionalities in an application. They focus on building the functionality with
great UX. A Growth Product manager looks more end-to-end and identifies
opportunities to deliver incremental growth. Let's take an eCommerce website
application. A feature product manager might be responsible for the checkout
experience. They will be thinking more about building capabilities in checkout
(like supporting new payment types). A growth product manager will take more of
an end-to-end customer journey perspective and think about capabilities like
driving more awareness for other related products in the checkout experience,
increasing the average order value, increasing customer engagement and
conversion on the checkout pages, etc. A growth product manager focuses less on
building a specific component in an application rather more on the customer
journey, conversions etc., across all application components.
Senior Director Of Product @ Upwork, Upwork • August 23
Great question.
1. One important piece of knowledge is that EVERY PM is responsible for having
a growth mindset. Growth PMs are NOT the only PMs responsible for growth.
2. Growth PMs are defined differently from company to company, and some
companies don't have titles called Growth PMs. The most common Growth PM
team that I've seen is usually responsible for user acquisition. This means
they own the product features that help users have a smooth onboarding
experience.
3. Sometimes the responsibilities go deeper in the growth process where they
are responsible for user acquisition, engagement, retention, and referrals.
However, in most cases from my experience, every PM owns a certain piece of
the entire product but their responsibility is to contribute to a certain
segment of this growth process. For example, I ran a team at 23andme called
the Engagement team, where we owned the homepage experience, and our goal
was to get our users to engage with our product more often. The more they
engaged, the more opportunity we had to upsell them.
Group Product Manager, DocSend Growth, Dropbox | Formerly Mailchimp, Calendly • September 15
I've wrestled with this over the course of ten years now. I used to think Growth
PMs and Core PMs should just be one in the same and every Core PM should be able
to do Growth work. However, I don't really believe that anymore. From my
experience, there's a place in the business to do optimizations (Growth) and a
place to do exploration (Core) work.
Core PMs generally have a stronger skillset around taking big bets which require
a lot of coordination and patience. Growth PMs require high analytical acumen
and rapid development, but much smaller bets, and not as much coordination.
Director of Product Management, ezCater • January 2
The skill sets for growth and non-growth PMs are about 85% overlapped. The key
differentiator is analytical sense. While all PMs need to ensure the team is
focused on driving customer and business impact, growth PMs always have a direct
tie to driving business KPIs. This requires a more advanced level of
understanding trends in the data to identify areas of leverage.
On the flip side, it is important to know what a Growth PM doesn't need to be
great at in a given role. For example, I hired a PM who led a mobile app working
with a small, dedicated team. That means the bar for collaboration skills didn't
need to be as high as other roles. Another time, I hired a PM who work on core
site conversion with a clearly defined scope, so they didn’t need as much depth
in product sense.
2 answers
Uber Head of Growth Programs, Riders, Uber • January 26
The roadmap process is no different from any other product manager. They work
closely with marketing, engineering, design, and data science to create the
roadmap. There are sprints & prioritization processes for all features. They are
focused on continuous experimentation and learning - which is an input into the
prioritization process.
Director of Product Management, ezCater • January 2
Focus Area > Problem > Hypothesis
First, the focus area for the team must be defined. This starts by mapping out
the possible areas the team could focus. My recommendation is to assess the
opportunity size using the product of "What's the business value if [x] area was
improved?" times "What's the likelihood of that happening?"
Next, you want to align on what problem you are tackling. For example, when I
first started at ezCater we decided to improve initial landing experiences for
visitors. I leveraged the Google Ventures style Design Sprint. That meant
working closely with stakeholders to map the customer journey, bringing in
analytics and data insights, inventoring customer research, and auditing
competitors. Consolidating that all in a Miro board, I could walk the working
group through these materials over a multi-hour session and come together on
facts and insights to identify the most fruitful opportunity areas.
Last, you generate solutions. To avoid group think, have people generate
solutions individually. From there, the PM can take lead organizing the ideas
and ensuring they have crisp hypothesis that tie back to known insights and
there’s a sizing of projected reach, impact and effort to inform relative
prioritization.
I think this process works best to do quarterly, providing enough fuel for the
team to run for a period while giving a recurring blast of fresh context and
ideas!
1 answer
Director of Product Management, ezCater • January 2
These 3 principles are presented in rank order, because each one only matters if
the ones above it are following
1. Empowerment - Everyone on the team feels ownership, understanding the
problem space and context to really make an impact. Without empowerment, the
team will inevitably be risk-averse or overly deferential, which is the
opposite of the motivated, go-getter attitude needed. This can occur either
because the team is not staffed or scoped appropriately, limiting what bets
they are able to take, or management is overbearing and doesn’t cultivate
independent thinking.
2. Rigor - Bets are thoughtfully taken, informed by data and strategic thinking
into crisp hypothesis. They develop end-to-end solutions, thinking through
the entire relevant customer experience. For a new feature, this spans
presenting information to customers contextually in a compelling framing,
providing easy actions that minimize cognitive load, and keeping the
customer on a journey that remains compelling and relevant throughout. A
team can be as empowered as they want, but if they take bets that are too
small, just strategically don’t make sense, or they aren't resourced to
cover the full user journey, their impact will be limited. Practice is the
best teacher, but process accountability can accelerate this by making sure
all initiatives have basic sizing (reach, impact, and effort) and execution
risks (dependencies, order of operations) are planned out before work
begins.
3. Agility - The team is scrappy, making a surprising amount of progress in a
short period of time. Speed to learning is of the essence. A team can be
effective if they just have the top two principles, but they’ll move slowly
without agility. Management can support this through pushing on speed
without rushing. My favorite question is “How could you learn [x] even
faster?”