This week’s publications consists of Four parts. Feel free to directly browse to relevant section:
📚 Part 1: What are other options to document other than PRD? (+ some sample formats)
🧐 Part 2: From my experience as Interviewer : Common pitfalls you should avoid
👉 Part 3: How to get better at Product Sense Interview Rounds
📈 Part 4: Interesting Poll Results on what Twitter thinks about Product Management
Part 1: Not everything has to be a PRD.
Here are 5 kind of short-form documents that get the job done for product managers
1. One pager
Nothing beats a one-pager specially when you're just trying to introduce a concept or kicking off an initiative or want to give context.
Add links to other documents within the one pager, add bullets not explanations.
2. Product FAQ
Lot of times people want to know how, why and when the product works and they don't always care about the depth of a PRD. Product FAQ document is series of most asked questions about your product answered in a concise manner with link to more documents if neeeded.
3. Product Concept
This is typically 1-3 pages and is meant to give designers/researchers/engineers information about what happened in the past, what's the next big problem to focus on and abstract level idea of how it could be solved through collaboration. Can include mockups.
4. Async Brainstorm Document
Need to brainstorm on something but your team/stakeholders cannot get into a meeting (timezone issues for example) - start a document with background, problem, metrics, vision and then ALL options on the table. Invite stakeholders to comment.
5. Decision Logs
This could be a separate document or a section in above documents. This is to log all concerns, questions, action items and decisions taken in a meeting - it is a running log of decision making.
Bonus Some one pager templates:
Part 2: Five common mistakes I see candidates making in product and engineering (manager) role interviews
Sharing my observations as an interviewer
1/ Underlying complexity of handling stakeholders
Candidates can sometimes over-simplify how they convinced stakeholders (specially senior ones who were against the) idea you believed in. Best to bring in the nuances/complexities and the to-and-fros of these interactions.
2/ Working under constraints
Great ideas sound better when you also mention how you managed to prioritise them. Include the nuances : how you prioritised them (frameworks, approaches), what if you had not prioritised (the downsides), and what was the outcome.
3/ Not mentioning 'not so obvious' insights
On the surface, some user pain points are obvious but if you have really dig deeper, you can come up with new insights- the one layer deeper ones. It is refreshing to see candidates sharing what they discovered that was not so obvious.
4/ Iterative Mindset
Iteration > big bang launch
Candidates saying they launched a big feature and got the accolades is a red flag because in more complex environments, it is easier to launch in small iterations than roll out the perfect feature. Share how you phased out + Why.
5. Metrics to measure success
It doesn't matter if you launched something successfully unless you back it up with which metrics were you targeting (early in the answer) and how did you end up fairing on those eventually. Talk Metrics.
Part 3: Importance of Product Sense Interview Rounds
Product Sense Interview round has become the go-to method for big tech companies to figure out candidate's:
1. Structured Thinking
2. User Empathy
Here's my biggest takeaway that has helped me clear every product sense interview round 🧵
The Takeaway: Imagine you also have the Customer and the CEO in the room along with the interviewer.
Because this will make you stand out vs other candidates in 2 ways:
1/ The general problem solving approach in product sense rounds does not take into account company's context (its vision, strategy, current situation) and the senior stakeholder is NOT interested in solutions that have nothing do with company's vision / market reality/ goals.
2/ The customer in the room makes you think about the customer segments, their problems and approach to solving them .. a lot more deeper. You will not say things for the sake of it but genuinely because you care. (The customer is sitting right in front of you)
Another takeaway for me has been "storytelling". Own your ideas/approaches and in the end of interview -> share your final product pitch that maps to user problems, business goals and tied to success metrics against which you hold the hypothesis accountable.
In-fact, I summed up my hard-earned learnings into a 36 min video + some practice content (at <10$). I am inviting early feedback. Email your thoughts bandanjot@gmail.com with possible improvements. Click below to access.
All new subscribers to Productify will be getting a 30% discount code to early access kit in their welcome emails. So if you haven’t subscribed yet - this might be a good time.
Part 4: Conducted 7 polls over last two weeks on various product topics on Twitter
Experimentation, Promotions in Product ,PM Skills, Product Strategy and more.
Here are some pretty interesting findings
1/ 55% believe that following ideal product practices have no correlation with getting promoted/ growing in their organisations.
2/ Product Sense interview rounds are thought to be the toughest ones (35% votes) followed by a tie between Behavioural Rounds and Data/Design rounds.
3/ On experimentation: there seems to be two extremes (accounting for 70% of votes) : Either experimentation infrastructure doesn't exist for product teams to test or (in some other cases) every feature starts as an experiment.
4/ Product Strategy is most closely understood/ perceived to be best represented in the form of Strategic Objective and KRs. (40% of votes)
5/ Most of the product twitter community ( 51% of votes) looks forward to non obvious / non bookish knowledge here, followed by tools and resources (~30%)
6/ UX/Research (35%) followed by Project Management (30%) is thought to be the most helpful skillset in Product Management.
7/ 63% believe/perceive Engineer has the most contribution in a successful feature relative to PMs and Designers.
Of-course, these results could be biased - example -> depending on time of the day, geographies, representative of product twitter community and not product in general.
But some of the insights are interesting.
Which one is most interesting to you?
Follow Productify on Twitter for daily product tips
Get early access (<10$) to Product Sense interview Toolkit. Send your feedback to bandanjot@gmail.com
What are your thoughts on PMs writing PRDs (or similar) for mostly backend features? When the goal of the feature is _very_ simple and most of the complexity is code/backend, would you still write a whole PRD?
@Bandan - Thanks for the article! Are there sample write-ups (the 5 different kinds of doc that you have mentioned) of yours that you can share for the community's benefit?