Creating tickets is a collaborative effort between me, the engineers, and the designer. Once I have described the issue and provided wireframes and flows, the engineers take over to create the actual tickets based on their technical expertise. This ensures that all aspects of the issue are properly addressed and implemented in the ticket creation process. How do you create tickets? Do you do it yourself, or do your engineers do it once you’ve described the issue and the wireframes and flows that the designer has provided?
– Anthony Smith
Discussion
A] In our organization, creating tickets for issue resolution is a collaborative effort between multiple teams. As the product manager, I typically start by describing the issue and providing wireframes and flows to the designers. Once the designs are ready, our engineers take the lead in creating the necessary tickets to address the identified issues and implement the required changes. This approach ensures seamless coordination between different stakeholders and streamlines the ticketing process for efficient problem-solving.
By involving multiple teams in the issue resolution process, we are able to leverage the expertise and perspectives of each team member, leading to more comprehensive and effective solutions. Additionally, this collaborative approach fosters a sense of ownership and accountability among team members, as everyone is actively involved in finding and implementing solutions.
– Gerard Kolan
B] It depends significantly on the nature of the product and the team dynamics. It’s frequently more effective for the PM/PO to stay at the higher level (Epics in Jira, for example) for highly technical products (services, infrastructure, etc.), but to collaborate with a tech lead to create the stories that meet the objectives and specifications specified in the Epic. There are several requirements to make this work, such as collaborating with engineers to develop backlog triage, but in my opinion, when done correctly, it’s much better (having tried it both ways many, many times).
I’ve seen it work well for PMs and POs to write the stories and have engineers handle the subtasks for less technical products (UI, etc.).
Setting expectations with your team by addressing that question collectively is more crucial. If a PM writes every story, there’s a risk that they will become a backlog janitor and lack the time and resources to truly offer the value they are hired to add, which is to keep the team moving forward and fulfill the needs of the client. Instead of the true value of keeping the team focused on results for your customers and business, your perceived worth becomes the tangible contribution of a tale.
Having said that, most businesses find this to be a very dysfunctional area since project management, program management, operations management, and so forth are all closely related to the role of project manager. Because they don’t know what you really do, people assume that the only thing you contribute is writing stories. That overlooks the value you provide when you perform the product properly.
– Pauline Francis
C] It’s explained really nicely here. In my opinion, Usually, I submit tickets for more UI features. similar to a fresh search filter. Submitting tickets for UI features, such as a fresh search filter, is something I often do. I find that it greatly enhances the user experience and makes navigating the platform much easier. Additionally, these additional UI features can also help improve overall efficiency and productivity for users.
However, I am more inclined to supply the business requirements that guide technical design if we are discussing a modification to the indexing process. Engineers then draft the tickets. This allows me to provide a clear understanding of the desired outcome and ensures that the technical implementation aligns with the business goals. By involving engineers in the ticket drafting process, we can collaborate effectively and make informed decisions regarding the modification to the indexing process. This approach helps streamline communication and fosters a more efficient development process.
I occasionally have a tendency to forget the precise details of meetings with the customers or stakeholders. Which is why I record the meetings so I may review them later and make sure I haven’t missed any important details? I would like to relisten to the conversation in order to obtain a deeper grasp of the topic that was covered and to gain a fresh perspective that was not immediately apparent to me during the meeting.
Do you face a similar problem?
– Alana Martin
Discussion
A] I take notes in front of everyone during crucial conversations by sharing my screen with a notes sheet. I also occasionally jot down actions. Everyone will be able to view the meeting minutes, the requirements, and the activities that need to be taken afterward. Reviewing the notes and needs with the team and stakeholders in real time makes a lot more sense in my opinion. Following the meeting, I email out the link to the notes page.
This ensures that everyone has access to the information discussed and can refer back to it whenever needed. Additionally, by sharing the notes with the team and stakeholders, it promotes transparency and accountability within the group, fostering a collaborative and efficient work environment.
– Priya Varma
B] In virtual meetings, how do you (or can you even) manage this? Is it possible to share a split-screen window that displays more than just the notes document while keeping the other material visible?
(I’m picturing zoom on a laptop screen; there probably isn’t enough space to share notes and product artifacts, etc., at the same time.)
– Ahmad Bashir
C] Yes, it is possible to share a split-screen window in virtual meetings that allows for displaying more than just the notes document while keeping other material visible. Many video conferencing platforms offer features like screen sharing or content sharing, which enable participants to show multiple windows simultaneously. This allows for seamless collaboration and presentation of various materials such as slides, documents, or webpages alongside the notes document. Additionally, participants can utilize chat or annotation tools to further enhance engagement and interaction during virtual meetings.
This work is quite vague, and there aren’t many deadlines for large projects. It’s probably a good idea to speak with customers frequently, but if you don’t, it can take some time to notice. Likewise with market research and a plethora of additional product-related endeavors.
How do you work long hours every day? I am easily sidetracked—far too easily. What advice would you give?
– Bethany Grey
Discussion
A] I put in the hours when and where they are needed, not all the time. There are days when it’s twelve hours and days when it’s two. Flexibility is key to my approach to work. I prioritize efficiency and productivity, adapting my schedule to meet the demands of each day. This allows me to maintain a healthy work-life balance while still delivering exceptional results.
My employers (flat rate DX contract) rely on me to perform my duties; therefore, if I’m indolent at the wrong moment, I may really hold up the show and cost them a lot of money. My team’s developers put in long nights and work weekends, so I make sure they always have what they need (most of the time), and anything else can wait until I’m feeling particularly motivated. By prioritizing my tasks and being efficient with my time, I am able to meet the demands of each day without compromising the quality of my work. Additionally, I understand the importance of supporting my team and ensuring they have the necessary resources to succeed, which ultimately contributes to our overall success as a company.
– Elvin Henriques
B] Specify deadlines. Bemoan the lack of accountability in your retro and take action. Establish a structure with others involved. etc. During our retro, it became evident that there is a lack of accountability within the team. To address this issue, we need to establish clear deadlines for each task and ensure that everyone understands their responsibilities. Additionally, it is important to create a structure where team members can regularly check in with each other and provide updates on their progress. By implementing these measures, we can improve accountability and ensure that tasks are completed on time. Let’s set a deadline for implementing these changes within the next two weeks and set a schedule.
– Angela Blue
C] To be honest, this is the exact reason I’m hesitant to move from sales engineering to project management. Though, as a SE, you show up to scheduled calls and know your crap, I truly would like to. That is the task. Not in doubt. Sure, there’s always “other stuff,” but the essence is clear-cut. As a project manager, I would be responsible for overseeing the entire project from start to finish, ensuring that all tasks are completed on time and within budget. This role requires strong organizational skills and the ability to effectively communicate and collaborate with various stakeholders. While sales engineering may have its own unique challenges, project management offers a different level of responsibility and the opportunity to see a project through from conception to completion. It would be a new and exciting challenge that I am eager to take on.
Great product companies have four things in common: a clear product vision; a product strategy; a set of priorities; and a way to measure outcomes. We’ve already discussed the reasons companies struggle with these, and discussed how to create these tools for product success in other articles, but we’ve heard from readers that they’d like more details on Product Strategy and how it fits into existing product environments.
A calendar skeleton helps you focus on your top priorities. Here’s a template – you’ll be able to copy it if you’re logged in to Google. This piece is a companion to Mapping your company’s year, which talks about planning time efficiently as a company. As an executive, everything flows from how you spend your time. You set a meeting, everyone rearranges their schedule. Time is emphasis, and your calendar very directly affects what gets done in the company and how you spend the dollars of the people who work for you.
Certainly part of why Steve Jobs “always got it right” was that he was a genius. You can’t operationalize or imitate genius. But genius was only part of the story; there are plenty of geniuses with brilliant ideas who can’t turn them into anything tangible. More important than genius was the way, Steve led people at Apple to execute so flawlessly without telling them what to do. In fact, both Google and Apple achieved spectacular results without a purely autocratic style. This leads to important questions: how did everyone in the company decide what to do? How did strategy and goals get set? How did the cultures at these two companies, so strong and so different, develop?
__________________________
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.
