A] Productboard has some real benefits for smallish teams:
A number of roadmap templates to choose from.
Easy to create and share beautiful roadmaps in minute
Roadmaps automatically stay up to date because they’re all based on the same underlying data.
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.
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.
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:
Clarify the problem statement
Define the objective of the research
Define the target customer and key stakeholders
Select the right research method and explain it is the right research method
Set a timeline to execute for me and the user research team
Go and do research – meet weekly to review progress and make changes based on feedback
Collect data – qualitative and quantitative
Analyze the information and come up with insights (always keep the underlying data handy for the teams to look at)
Justify my stand with compelling evidence
Suggest concrete next steps and communicate findings
If we dive deeper into mapping a user journey, then we also need to look at:
The business objectives
User profiles and bio
User goals at every stage of the journey
User actions at every stage of the journey
User pain points at every stage of the journey
User emotions at every stage of the journey
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.
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
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.
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.