Notifications
Project Submitted for Job: Product Manager emp0302 2 by testkrish 0602
×
Advanced screening Submitted for Job: Product Manager emp0302 2 by testkrish 0602
×
Job Application for Job: Product Manager emp0302 2 by testkrish 0602
×
Advanced screening Submitted for Job: Ats Product Manager US - United States by testkrish 2201
×
Job Application for Job: Ats Product Manager US - United States by testkrish 2201
×
Mark all as read

Tools and Best Practices for Product Management

Welcome to our Product Newsletter, a biweekly email highlighting top discussions, and learning resources for product managers.

What We Will Cover In This Edition:-

Top Discussions: 

1) What’s your favorite lightweight Roadmapping tool?

2) Which tool do you use to collect bugs from internal stakeholders?

3) What are the best practices for a PM to document user research?

Top Learning Resources:

1. What is an API?

2. What are Webhooks?

3. Identifying good design in 6 steps.

__________________________

Top Discussions

Question 1) What’s your favorite lightweight Roadmapping tool?

– Amy Walker

Discussion

A] Productboard has some real benefits for smallish teams:

  1. A number of roadmap templates to choose from.
  2. Easy to create and share beautiful roadmaps in minute
  3. Roadmaps automatically stay up to date because they’re all based on the same underlying data.
  4. Roadmaps are linked to underlying customer feedback so it’s easy to close the loop with colleagues and customers when features go into discovery/delivery or are launched.

– Dave Kim

B] I can’t say it’s my favourite because I haven’t been able to test this hypothesis… but if I was thinking really lightweight, I would fashion the tool myself with Airtable + Miro. It’d be a means to an end, not a permanent solution, but I think this approach could help a team “form” its working plan quickly and organically (so you can get to “storming” next.)

– Risa Butler

C] I would say that it really depends on the problems you are trying to solve and how any tool might help you solve that. Best, lightweight, etc. really depends on your workflow, process, and what you’re trying to achieve. There are plenty of tools out there, all approach PM and road mapping from a different perspective. I can recommend Airfocus, since I have been using it and it is flexible in terms of integrations and adaptability with other project management tools such as Asana and JIRA.

– Juan

D] A google sheet with team/entities swimming lanes might just be fine. you can develop a set of conventions and colours to track various things (drifts, idea maturity, etc.…) to make it work well and be understood/used by everyone. you can comment and track history. This is a very raw idea but works quite well in practice.

If it does not change too often, you can draw and ask your designer to make it look nice for a presentation, online publishing, etc.… you have full control of the story and branding like that.

__________________________

Question 2) Which tool do you use to collect bugs from internal stakeholders?

I’ve seen some companies allowing everyone to access Jira and they would directly open a ticket there. In other companies they would text the PM on Slack, the PM then creates the ticket.

How do you make sure that the reported bugs are detailed?

Thanks !

– DonovanOkang

Discussion

A] JIRA Service Desk, create a Form for them to follow with some custom fields with key information to segment them across dev teams if necessary. You can also create Slack integrations with the dedicated channels to monitor them as they come in, it works well currently but we are not inundated with tickets at the moment.

– Karan Trivedi

B] The main reason is to have ONE source of truth, in this case, Jira. The moment your tickets are tracked in multiple systems, you’re doomed.

The second reason is discipline. No ticket – no work, sorry. My team can’t follow up on everything in chats.

The third reason is the update status. Instead of replying to every stakeholder on the status, I say, “read comments in the ticket. They, and the task status, are the latest updates on your request.” When there’s an overflow of such tickets, I use a Triage board – a dedicated board with filtered tickets submitted by stakeholders.

– Risa Butler

C] Agree not everyone knows, wants to learn, or should be allowed to use Jira, but then you need “dedicated loggers” of some kind, whether that’s frontline support, QA, PO, PM, or semi-trained minions. Also agreed that the more roles who are entering bugs, the lower the quality of the bug report will be (filled in, described well, or missing repro steps, images, data, etc.). In general, people closer to the action, log better bugs (QAs, developers, product owner/manager) because they know they will have to deal with them later.

Yes, you will always have to triage the bugs. Usually, there is a separate project for receiving bugs/tickets into (holding tank), they get triaged here and then moved to the appropriate backlog (if serious, worth fixing, etc.). QA, Project Manager, developer, etc. are the ones who usually carry out the triage. Anyone who calls the shots, in the end, should be the Product Manager or Product Owner. Bugs that are deemed not worthy should be closed quickly with a note as to why (not a bug, can’t reproduce, won’t fix, etc.).

Enhancement/feature requests are not bugs and should go into a separate list altogether and be prioritized differently.

– Angela Blue

__________________________

Question 3) What are the best practices for a PM to document user research?

I want to know how an experienced Product Manager and UX Researcher documents the user research data, are there any specific frameworks or tools out there? Secondly, what is the structure they follow over a broader perspective?

– Zayne Kazme

Discussion

A] I like to keep things simple when it comes to documentation and research by using Google docs and slides. I almost always write things down in detail, run them by the team and then work on a summary visual. It takes a bit longer but it avoids the back and forth on some fundamental things.

In terms of structure and framework, I use the following approach:

  1. Clarify the problem statement
  2. Define the objective of the research
  3. Define the target customer and key stakeholders
  4. Select the right research method and explain it is the right research method
  5. Set a timeline to execute for me and the user research team
  6. Go and do research – meet weekly to review progress and make changes based on feedback
  7. Collect data – qualitative and quantitative
  8. Analyze the information and come up with insights (always keep the underlying data handy for the teams to look at)
  9. Justify my stand with compelling evidence
  10. Suggest concrete next steps and communicate findings

If we dive deeper into mapping a user journey, then we also need to look at:

  1. The business objectives
  2. User profiles and bio
  3. User goals at every stage of the journey
  4. User actions at every stage of the journey
  5. User pain points at every stage of the journey
  6. User emotions at every stage of the journey
  7. Our solution mitigates the pain points and brings delight.

The second part is a lot more detailed and requires coupling our solution with the user’s needs. The user research part requires us to focus on the problem while keeping our solution far away to avoid nudging or biased data collection.

I hope this helps.

– Himanshu Singh

__________________________

Top Learning Resources

What’s an API?

Application Programming Interfaces (APIs) are like drive-thru windows, but in code: they take inputs and give you predictable outputs. When you give an API a bunch of inputs to get the outputs you want, it’s called calling the API

What are Webhooks?

The thing about APIs is that they’re passive – you need to send a request to get a response. APIs will never reach out to you, ask you how you’re doing, and why you’re behind on your car payments. Webhooks, on the other hand, are active – instead of taking a request and returning a response, they send out data when something happens internally.

Identifying good design in 6 steps.

Art is subjective, it’s like a game where there are almost no rules. Design is different, and the fact that someone can put together a list of principles should already tell you that there are some rules to the design game. If there are rules, then we can tell whether or not these rules are being followed, which means that design is not subjective. However, to be fair, I can’t really say that design is 100% objective, there are always things that come down to personal preference that is determined by your culture and experiences.

__________________________

If you enjoyed this newsletter, please consider sharing it with a friend by asking them to sign up here.

Who’s Prowess? We are optimist product managers, engineers, and educators working on creating a world where merit meets opportunity. On Prowess, aspiring and experienced product managers showcase skills, learn from the community, and connect with employers to advance their careers.

How can you grow with Prowess?

  1. Learn from curated learning resources and community
  2. Work on curated projects or join expert-guided group projects
  3. Receive personalized feedback from product leaders
  4. Build a portfolio to stand out as a product manager
  5. Access and apply to curated jobs
  6. Prepare for interviews with Q&A from top companies

Latest Posts