I’ve been interviewing for a new Product role over the past few weeks, and one question keeps coming up, and I’m not sure how to answer it. Is there a framework for describing your product, or should you mention certain things when describing your product technically?
10 Likes
I don’t believe you should ever describe your product technically. The only instance I see this happening is if your product is purely technical, and your stakeholders are technical. Sort of like having MS azure backup services as your product which is being described to the technical support team who need to understand everything to aid their end clients.
Other than that, your product should essentially be described in a fairly simple way. Pure English. What is the Challenge and how does the product benefit this challenge and why.
If you find it hard or feel that you need to be technical to explain it, then I would challenge the product and it’s benefits directly.
8 Likes
@KaranTrivedi, You can speak to it on a broader scale. API integrations, cloud repository, SSO security, etc. If they want you to talk code or database diagrams you are interviewing for the wrong role.
But if you don’t know how your systems work technically on a high level as I described, you may not know your product well
9 Likes
@Ana, Agreed… You must know the high level stuff on your product to manage conversations technically - but purely to hold a conversation in a technical manner which shall shed further light on your product.
Of course, very much depends on what the product does.
8 Likes
All of this ^
A broad understanding is all you need from a Product view and a good relationship with your Architects plus Dev Leads.
7 Likes
I just recite this:
6 Likes
I don’t think there’s a template for this.
But I’ve use this one before:
First sentence:
[product name] is a [product type] which allows [list of primary, secondary users] to [main product function] <with/without> [one or two primary product differentiators].
Second sentence:
This [product name/type] was built using [stack or internal/external tool], and is [why product was built problem 1], [why product was built problem 2].
Third sentence:
[product name/type] will be available [date/release calendar/sprint], and we plan on [immediate next step that includes users].
Example:
generateQaUser is a user credential generator tool which allows product managers, marketing managers, and QA to quickly generate fake user credentials without needing to provide a real email or phone number, or go through the new user creation flow.
This user credential generator tool was built using React, Node, and PHP, and is capable of generating new user credentials on the browser, without needing serverside authentication.
generateQaUser will be available next week 12/31/22, and we plan on migrating QA workflows to use the tool ASAP.
This doesn’t work for everything, the the whole point is to share:
- product identifier
- what product is
- who the product is for
- stack/high level tech (not an explanation, engg just needs to know if they know the stack or not)
- where it can be used
- when it can be used
The person reading this email/message should know exactly what is being introduced, and what their involvement could be (to decide if they should pay attention, or just ignore).
I have been told to make this as high level as possible in the past- enough for anyone in the company (PM, PDM, PMM, engg orgs) to understand something is new, and that it exists. 
5 Likes
I think it depends who is asking. If you are talking to an engineer or architect, they might be trying to understand your level of technical understanding of how the product works.
I build technical products for highly technical users including platform features for internal. Understanding how that works is important for my collaboration with engineers to build the right product.
If you worked in less technical products maybe that matters less.
4 Likes
The word “technically” is widely misused and misunderstood.
Try to understand your audience and give them a range.
For product and business you want to be able to have your elevator pitch and understand the value and conversion.
If you’re talking to UX then speak to the details of design.
If you’re speaking to an engineer then let them know you can communicate at their level.
Read your audience and be overt about it.
3 Likes
Not quite sure if I’m getting the gist of why it comes up in interviews for PM… likely is a gauge to assess whether you can communicate value of the features you’re launching for the product to support marketing, sales and go to market efforts.
I would structure a bullet point to list out all features launched so far for the product, how this feature supports user needs/use cases, in what ways does the feature drives value proposition of your product to be the preferred solution for a user need and finally detail the user experience and capabilities it contributes to
2 Likes
Along those lines, I keep getting asked if I am a “technical pm” or a business pm. I ask what do you mean? I try to explain that the word “technical” is relative! Like another person said, do you mean complex or difficult?
Maybe more to your point, when I get asked to describe a product “technically” I usually explain the workflow and interaction between the front end and backend. For example, when the user clicks that order button, sends a command via API to the control plane, which generates a key, which then… blah… blah… blah…
1 Like
I would say Complex & Difficult 
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.