Well, here’s my take on the question I posted.
If I could make one thing 100 times more effective, it would be to have a better understanding of the customer. We need to be better at understanding our customers and their needs, so that we can help them better.
I’m curious to know what particular task y’all think you would do to make it 100 times more effective.
9 Likes
I can offer some general insights into common tasks that product managers might prioritize. One key task that a product manager might focus on is developing a product roadmap, which outlines the vision and direction for the product over time. This task could be made more effective by finding ways to gather and incorporate input from multiple stakeholders, including customers, sales teams, and engineering teams. This might involve using tools or techniques such as customer interviews, surveys, or focus groups to gather feedback, and working closely with cross-functional teams to ensure that the roadmap aligns with the company’s overall strategy.
9 Likes
I think of the one task that might be a high priority for a product manager is market research and gathering customer feedback. This can often be a time-consuming process, but it is also crucial for understanding the needs and preferences of the target market and for informing product strategy. Improving the efficiency of this process could involve finding ways to streamline data collection and analysis or using automated tools to help with the process.
8 Likes
I would say aligning with other teams. Anything I can do either myself or within my team is fast and efficient. I was stuck between alignment with management and alignment with other teams but aligning with management happens less often so the time saved would be less.
7 Likes
Which teams do you align with, and on what topics?
7 Likes
Strategy/vision for our platform, shared ownership of certain flows, when which team will A/B Test (no infrastructure for parallel tests), how do we divide responsibility for overlapped KPIs…
6 Likes
In my opinion, the one thing that I would do to increase the effectiveness is to ensure customer satisfaction and loyalty, businesses need to understand their customers’ needs and wants better. Understanding the customer journey and what they are looking for can provide valuable insight into how to best serve them. This can be done through improved customer service, using data analytics to gain insights into customer behavior or using AI writing assistants to generate content tailored specifically for each customer. By understanding our customers better, we can provide them with tailored services that will make them feel valued, increasing their satisfaction and creating a deeper connection between the business and the customer.
5 Likes
First of all, a warm welcome to all the newcomers to the community. I see quite a few of them in here.
I would prefer more effective documentation. Not the text itself, but the lack of documentation review is the problem. Their natural tendency is to approach you and inquire. It’s a hassle to maintain paperwork up to date. How do you all manage?
4 Likes
All documentation lives in JIRA/Aha. Nowhere else. Then the status/history is clear to everyone.
4 Likes
Welcome to the community @HerbertWarnick. Agree with you to a certain extent. With smaller businesses, this may be effective. However, a developer won’t have the time to sift through hundreds of tickets in a national company with numerous development teams and boards active.
4 Likes
I was at a 5k person company with HQs in USA, London, and India. It worked great.
- JIRA tickets are tied to Pull Requests, so if a dev is working in the code, they can trace the code back to the original JIRA ticket.
- Tickets are tied to epics. Each epic discusses the group of tickets that will be released together.
- Each epic is tied to an initiative; the initiative details how a feature will contribute to company strategy
- Each Initiative is tied to a goal. Goals are your OKRs. This details how you are measuring success.
Devs need to manage their own documentation. This is not a product manager’s problem IMO.
4 Likes
I totally agree that documentation shouldn’t be left up to product! In my org it mostly is and engineering only focuses on a piece of it. Also, maybe we could use Jira if it was as organized as you outline. But in reality, different teams all have different rules for their boards. It’s a mess! 
4 Likes
Does Aha track documentation version changes? Where, if so? We have only recently begun utilizing it for roadmaps. Confluence is not available, but we use Jira for everything else.
3 Likes
@FlaviaBergstein, Every ‘ticket’ in Aha has its own history (just like in JIRA) - so if you have a roadmap item, and it’s moved off of the roadmap, when you click ‘history’ you’ll see that it was on the roadmap, then User X moved it off the roadmap on September 21st.
2 Likes
This would not scale. Wiki’s are much more manageable.
2 Likes
@TinaGreist, Wikis are for static documentation only (team processes, architecture, etc.). I think it’s simple. However, feature documentation (PRDs, goals, initiatives, API contracts, etc.) is updated at least once every three months. Each of these modifications ought to be associated with a ticket. The source of the truth should be the ticket if it is there.
2 Likes
Ah. Yes, wiki is not the best source for this kind of information. However, how are these still in Jira? Could Jira still be used if my project has more than 15,000 criteria and there are numerous other projects that are similar? How could I validate the external requirements that stakeholders have provided?
2 Likes
Referring to my comment earlier in this thread, please go through it and continue reading here…
This linkage allows you to easily find things. If you’re a dev trying to figure out why something was done, you can look at the code, see the pull/merge request in github/bitbucket, see the story it’s related to, then see the epic, and the epic will have all the technical design details.
If you want to look for related epics, you navigate to the initiative under which the epic lives, and see multiple other epics that you can work through.
If it’s a business requirement, it should be detailed at the initiative level and/or epic level (wherever appropriate). If it’s a technical/feature requirement, it should be included in the AC of the related story.
For context, the ‘descriptions’ of my initiatives and epics can be anywhere from 1 sentence to a full page or so.
The whole idea behind this is that PRDs are redundant and dumb. I don’t understand why you would list out all of the requirements in a confluence page/google doc, then go and create a story for each requirement. Makes no sense to me.
2 Likes
I appreciate your comprehensive response.
You have accurately stated the method that my team uses, however there are also design documents and genuine requirement specifications at work. How do you control data archiving? How about test coverage for customer requirements verification and validation? I would require ways to demonstrate how customer requirements were broken down into subsystem requirements, and I would need to validate at each level. Softest unit verification, software requirement validation, and system level requirement validation.
I’m still interested in your experience even though perhaps your products don’t need this degree of specificity.
1 Like
From a GDPR standpoint? We use a third party solution to automatically categorize and eliminate data
Like we would do with SonarQube? It’s just part of the status for each ticket… ticket can’t advance if it hasn’t been tested.
Validation/regression/UAT testing can all be automated and are a part of the story’s progression.
1 Like