.jpeg)
Interviewing for Senior
Product Manager
This article assumes you have gained currency and credibility as a Product Manager first and foremost, and you are ready to reach a senior product role within an organisation.
Interviewing for Senior Product roles is a bit
different to when you started your career interviewing for graduate product
management roles or rotations at companies like Google (Associate Product
Manager) or Microsoft (Program Manager). Those interviews were seeking out your
potential through estimation problems and thought questions, while Senior PM
interviews seek out your philosophy, gained through years of
painstaking experience.
This article will go through some of the common
questions that hiring managers (usually Head of Products, or C-Suite tech
leads) will ask of you. This is not comprehensive by any means, and the answers
reflect my own thoughts rather than yours – which are best formed through your
own experiences.
What is your plan for
first 90 days?
This
reveals a lot about the candidate. If they’ve worked at a number of other
companies, they’ll have a very good idea of how their first 90 days will go. It
will also help identify early red flags, like candidates wanting to make
changes on week one. When I answer this question, I start by explaining no
company is the same – the method I’m about to explain may take a month at some
companies, 90 days at others, or longer where the organisation is complex.
Company
1/3
The first
30 days is all about learning the “Three Ps”. People, Problems, and Priorities
– in that order.
The Product
role is very much a people orientated role, and the first 30 days is all about
building the groundwork for lasting, valuable relationships at work. This will
involve a lot of coffees, lunches, and sitting with colleagues just getting to
know them better.
Problems really
relate to the current operational and future strategic problems the company
faces. Every company has problems, some more than others, and as a PM, you’ll
be tasked to sort these out, so get in early and start learning them with great
intimacy.
The
priorities relate to where the company wants to go. Note upfront that this is
different to problems – the company may be going a different direction than the
problems to be solved, and this will be another thing for you to work on.
Customer
2/3
Last month you learnt about the company, this
month you want to learn about the customer and the product. The Product Manager
is the voice of the customer, and this is often forgotten in the weeds of the
backlog and the enthusiasm of your enterprise sales team. Make it a point to
talk to at least a customer a week, and start understanding their business
thoroughly. By mentally mapping customers, you’ll start to develop a working
understanding of customer needs and wants, and will eventually be able to tell
if a customer will want that feature or not – without having to ask them. The
groundwork for that starts here.
This phase is also the starting point for gaining subject matter expertise on your product. Sit in on sales calls, customer success tickets, and start writing minor feature requests for low risk items.
Control 3/3
The last 30 days is what I call the “control”
phase, where you start taking over control for the product from others, and
become the sole Product Manager for it. This phase is really flexible, but
typically, this is where re-establishment of metrics, introducing new
processes, and drumming up team rapport really comes in. You want to gain
organisational buy in for the product, and confidence in yourself. From here on
in, you’re the PM, and every problem is your problem!
How do you deal with
technical debt?
Almost always asked by an engineering person,
this question is trying to draw conclusions for one of two problems faced – an
engineer who doesn’t get enough love for the frustrating technical debt they’re
facing, or a Product Manager constantly annoyed by engineers wanting to replace
the whole system for the 20th time.
Before
answering this question, it’s important to set some ground rules:
-
Technical
debt ranks equally alongside features and bugs
-
It’s
a trade-off – working on debt reduces time for features and bugs
-
Anything
we build will incur debt, even today
-
Old
technology is not technical debt
-
Developers
love shiny new things, and this can incur false technical debt (e.g. switching
frameworks to work on something new, by saying the “old” is debt).
I answer
this question with a few statements.
1. It’s the responsibility of the
Product Manager to ensure technical debt has a seat at the backlog decision
table, equally alongside features and bugs.
2. It’s the responsibility of
Engineering to be vocal about technical debt, and its consequences
3. Reducing technical debt can be
pitched as an investment to management – by reducing technical debt, developers
are freed up long term, allowing them to output more.
4. Reducing debt can also be pitched as
a cost to developers – by focusing on technical debt, we forgo immediate
features which can generate revenue, and mean less resource for more.
Basically,
the PM needs to know whether to prioritise technical debt, and then spin the
message accordingly to the relevant audience.
What do you do when
someone is wrong?
This question is really to assess your personality.
For this question, I refer back to my first 30 days – developing relationships
with people. I make it a goal to learn my colleagues and treat them as friends
first, colleagues second. I also make it a point to say they’re not wrong – we
just can’t agree on the solution. I solve this by sitting down with the other
person and figuring out how we’re deriving our conclusions, and if we can’t
figure it out, getting others in the room to help us. If all of us collectively
can’t agree, then the company has bigger problems.
How do you prioritise the
backlog?
This is the bread and butter for a Product
Manager, and there are numerous strong arguments online for various approaches.
I don’t think there is a best practice for prioritisation as every organisation
is so different. I take a two-stage approach to this question – qualitative and
quantitative.
Product
Managers just know when something is important. We know our customers,
we hear the anxiety in the customer support agent’s voice, we see the dollar signs
in the sales teams’ eyes, and the curiosity on the faces of engineers. This
qualitative approach is developed over time, and is pretty good for the most
part. Product Managers also prove something is important with data. Data
reveals patterns, processes, and usage.
I want to
emphasise these are not two separate decision tools, but the same tool, one
after the other. Both qualitative and quantitative information should be
combined to make the best decision.
What’s your strength and
weakness?
This is going
to be personal for everyone. For me, my strength is that I’m an extrovert and
love people – I’ve developed effective communication skills, can read people,
and try my best to come across as a laid back, easy going leader. My weakness
is my hate and impatience for slow process – I’m not sitting around filling out
forms for a minor product release or spending hours with marketing because its
procedure.
How do you estimate a
feature?
Estimation is the hardest part of any project
or feature. Getting it right is a combination of three things – Product Manager
competency in conveying the requirement, Engineering maturity to grasp what’s
required, and sheer luck. There is no science to estimation, but there’s a few
things I do to make it easy. The first is t-shirt sizing. Small means it’ll
take less than 6 hours, Medium means it’ll take between a day and 4 days. Large
means more and requires a Business Analyst or a team of developer to sit down
with me and work it out.
What do you write on the Jira
Cards?
The what,
why, and when. The how is decided by engineering. I usually set up sprints so
that once I’ve completed my sections, it gets handed over to engineering who
beef it up and have it ready for dev.
How do you like to
release?
This
depends on the company and product, and there is genuinely no answer to this
one. If you’re building mission critical solutions for aircraft
instrumentation, you shouldn’t be releasing anything unless you have to. If
you’re developing a website that’s viewed at scale, deploy as much as you want.
What do you think of
agile?
This question really differentiates the pencil pushers versus critical thinkers for me. It’s also a great way for the candidate to assess the manager. A good Product Manager knows the advantages and disadvantages of the various software development methodologies. A great Product Manager knows you can pick and choose from various methodologies to create the perfect Frankenstein for your organisation. Organisations that religiously follow a certain methodology generally never find their rhythm or mojo.
---
Hope this helps you on your PM journey!