Prelude
This is an opinionated guide. There’s many aspects I glaze over for brevity and because I’m not aware of the finer points of being a product manager (PM). This guide is written in context of a workplace where product delivery is “waterfall-y” in the sense that departments hand over intermediary work, in the last step to the developer team. Plenty advice contained would be different for a cross-functional team covering the whole value delivery process. Still, some experiences and opinions might be re-usable and save some repetition when onboarding PMs to my team in the future.
From idea to ticket
TLDR: It’s fuzzy how to get from idea to ticket. As PM, you create most value in this life cycle.
How an idea results in a ticket depends on the topic. Some ideas might come in from the support team, others from user research. Some might come from user behaviour uncovered from analytics. Some ideas might be our own. Depending on the idea, different stake-holders need to be involved. One expectation you should always have: an idea will go through multiple iterations before it reaches the development team.
From problem space to solution space
When an idea comes up, it should first spend time being thought about in the problem space, not the solution space. Coming from the problem space allows us to better understand and solve the core issues, allows for more flexibility in how we decide to proceed. The solution space follows from understanding the problem space.
The ideation is a good phase to think about why we’re doing things, and how they are valuable. It’s the time to be strategic. As PM you should create most value in this phase — even though you likely spend more time orchestrating the idea execution. If we as a team don’t do a good job in ideation, we do stuff to the product, but we don’t consciously drive it to the destination where we’d like it to be. It’s easy to forget conscious, open, long-term thinking. The fastest way to deal with a problem is to ignore it. There’s thousands of things we could do, but we don’t have the resources. Let’s filter the noise of ideas to the most important ones and do those right!
Collaboration
We are a team of specialists. For new features extensive collaboration is required. The earlier people from every function are involved, the better. Since we want most engineers to be focused on implementing already agreed upon tickets, don’t pull random engineers into ideation. Default to the engineering’s team leads. It’s their job to have the big picture in mind, to deal with hypotheticals, uncertainty, and to make sure that ideation remains in realistic solution spaces. Pulling in engineering team leads first keeps things efficient. Team leads will pull in more engineers if and when required. If the problem space is well-explored and understood, and good context provided to designers and engineers, it’s likely that we don’t need to do a lot of the things we would have called mandatory, if we had immediately jumped into the solution space. To save resources, ask all involved people in every ideation iteration, which aspects of the current solution proposal are the costly ones, and how we could further simplify.
Estimations
Ask engineers for estimations. Engineering team leads are comfortable giving answers even when a lot of details are not yet defined. Estimations get more reliable the better defined the solution becomes.
Return of investment of good preparation
Traditionally the following rule holds true: the more time we spend in ideation and ticket polishing, the faster we are overall on delivery. Don’t push the process through quickly, that’ll backfire.
Your power: define scope or deadline
You can’t tell engineers how long your acceptance criteria are allowed to take to implement. You can either define acceptance criteria and accept the resource costs for them, or, for problems with deadlines, you can start solving a problem space by starting with the available time budget, and collaborate on finding the best solution given the available resources.
Accounting for learning early on
If we want to learn, we need to define expectations / hypothesis for tickets. This could be a measurable KPI like a conversion rate / usage count, or quantitative user research feedback. Without clear targets, we won’t know whether to call our solution a success or not.
Preparing the ticket
TLDR: Be thorough. It’s hard to spend too much time on tickets.
Why well-prepared tickets are important
Tickets define what we do. If they are bad, we do stuff shitty.
Tickets are the way that PMs trigger the execution of desired product changes. They are a primary communication channel between designers, engineers, PMs, and QA. You can even think of tickets as a cross-functional work agreement, a contract.
A well-written ticket will be implemented without a lot of interruptions, and the outcome will match PMs and designer’s expectations. A well-written ticket might make it unnecessary for PMs, engineers, and QA to talk about the ticket. It will just flow through all the implementation stages without hiccup. A badly written ticket will take longer to be implemented due to back-and-forth questions during implementation, and likely introduce bugs or even not match expectations, because not everyone has the same understanding of what was meant. Such tickets are frustrating to all who are involved.
Designs
Ensure that the designs are final.
- “Final” means, that they show all desired changes of the product, but do not include any other differences to the product that is visible to users. The designs should be consistent with the current product.
- “Final” means, that the shown wording has been agreed upon.
- “Final” means that there’s designs that show all the relevant states (e.g. button disabled / enabled), and clarify how the product change will look on smaller or larger viewports.
- “Final” means that designers don’t plan to make any further changes to the design. This can be signalled by including the word Handover in the file name. Attach screenshots of the designs to the ticket. The benefit is that they can’t be changed by accident. The engineer will have a fixed target in terms of design.
Deployment & QA
Decide on deployment strategy and QA requirements. By default, engineers will split tickets into sub-tasks and deliver them individually whenever the tasks are ready to be released. This way, we deliver small increments of value often. Moving in small increments is less risky and cheaper to manage on the engineering side. As long as the increments are well-scoped, it doesn’t even increase the QA overhead, as only clear, isolated changes need to be QAed (admittedly that’s not always the case). If you want the ticket to be delivered at once, e.g. because releasing in increments will leave the product in strange intermediary stages, please specify so in the ticket. All changes that could affect users in negative ways through newly introduced bugs require QA from a specialist. There will probably never be a frontend ticket that you write as PM that does not require QA. Since code is reviewed by at least a second developer and a QA specialist, you can trust the work output to match the ticket. By default, developers will release changes once QA approved that the implementation matches the acceptance criteria and doesn’t introduce new bugs. Still, for big or high risk releases you might want to verify a release before it happens. Specify this requirement in the ticket. The QA specialist will push the ticket to you after his / her QA. If you find no issue, comment on the ticket that it’s ready to go live.
i18n
Decide on internationalisation and request translations on time. There’s a cost to every locale we support for every single product change that adds or changes copy. The less translations are required for a product change, the less potential blockage from missing translations we’ll have. Of course that doesn’t mean that the product should not include all copy required for good usability. It just means that you should think carefully what translation requirements follow from a ticket’s acceptance criteria: If we change a user flow that touches users in all locales and that is crucial (e.g. the login page), it means that we can’t ship the new feature until we have all translations for all languages that the product is in (for exceptions see below). If we add a feature that is only available in certain countries, we only need to translate it for those country’s locales. If we change an obscure feature with low usage, it might be acceptable to ship the feature with just English translations, and add the rest later. Translations are PM responsibility. It’s the PM’s task to request them from the translation agency with enough time buffer so that they don’t turn into release blockers. Ideally engineers don’t start to work on a ticket, before all required translations are there. State in the ticket, which locales are required for release. Engineers and QA will use this list to verify that the product change matches the internationalisation requirements.
Delivery time
As PM you probably have an expectation of when the ticket will be delivered. The expectation might even be one of external stake-holders. Verify with engineers that the desired delivery time is realistic. If there’s an expected delivery date, add it to the ticket. If it turns out that the expectations are not realistic, scope must be cut, or it must be agreed that other (ongoing) topics will be dropped.
Analytics
Define analytics required to measure the ticket’s success or to understand user’s behaviour. Don’t track everything just because we could, as that’s expensive in implementation. Analytics are fragile, as analytics are invisible, not QAed as often, and failures are often silent and only detected with considerable time delay. Be consistent with existing event names.
Delivery quality
Communicate expectations for code quality, if they are lower than usual. Engineers don’t like to be forced to deliver worse code quality than their base-level quality. Our code review creates a certain preference for well-written code, as otherwise peers won’t understand the code, point out issues, and request re-work. That’s the natural and desired result of doing code review.
But why do engineers fear decreasing code quality for this one small ticket? It’s not a big deal for those few lines, is it? It is, because it’s much harder to keep a system maintainable than to make it unusable. Once a system’s code quality deteriorated past a certain level, it will be hard to ever recover. The system will contain bugs, be hard to understand, and it will be close to impossible to do any changes to it without introducing further problems.
Of course there’s valid reasons to fall below the base-level quality at times. For instance there might be reasons to ship a change as a short-term fix that will be removed a month later. If you clearly communicate reasons to deliver something with a reduced code quality, engineers are open to it. Just know that the generic reason “we want to ship faster” might not make the cut as motivation alone to change habits. The more context you can give, the better. But in the end, it’s engineers who have to work with the code for years to come, so if they are not willing to take some short-cuts, please accept it as the unavoidable cost of running a long-term business.
Misc
There’s more stuff to do outside the ticket, like aligning with other teams like marketing team to prepare communication to users and campaigns.
Getting tickets into the work-stream
TLDR: deciding that a ticket should be worked on requires agreement in the group.
If you consider the ticket as ready to be worked on, there’s two steps:
Grooming
Groom / kick off with a meeting, if the ticket is complex enough that just reading it might not answer all questions from engineers who are new to the topic.
Announce the grooming a couple of days up-front, e.g. during standup. That allows all interested engineers to participate. Share the ticket link in the grooming meeting invite, and ask participants to go over ticket and design upfront. This allows engineers to mentally prepare and bring up better questions.
The grooming is there to align all people on the acceptance criteria and raise remaining questions, if any. They can be answered on the spot, or asynchronously by updating the ticket.
Engineers might annoyingly come up with last new concerns, and try to cut scope or change acceptance criteria to reduce the amount of work.
Skip grooming for simple tickets
Grooming meetings are not always needed. If a ticket is straight-forward, the engineering team leads will say so, and you can skip right to the next step without grooming:
Get the approval of relevant engineers that the ticket is ready for development. It’s usually easiest to send them to the engineering team leads, they’ll check the ticket or delegate the check to team members.
Please address all concerns the reviewing engineer has. Usually those are only about missing clarity of some acceptance criteria. Less such questions / comments might come up, if you beforehand let the ticket be reviewed by a fellow PM who is not deeply involved with the topic and comes at it with a clear, unbiased set of eyes.
Subtasks
The reviewing engineer will break the ticket into sub-tasks that match the stuff that engineers need to do, to make the ticket’s acceptance criteria happen. You need not worry about this task-level breakdown.
During implementation
TLDR: Be present, responsive, and transparent.
Stand-Up
Participate in stand-ups. The engineers working on the ticket will mention progress, and might ask questions, if they have any. In reverse, you might ask the engineers questions if the update leaves out details you want to know about.
Ticket status
You can always follow the ticket progress by looking at its status. It’s the engineers responsibility to keep the ticket status up to date and your expectation can be that the status is true to live.
Blockage
Pay special attention to blocked tickets. The most reoccurring reasons for blockage are missing translations, and cases where there’s dependencies between backend and frontend changes and the dependency is not ready.
Asynchronous questions
If the ticket is an epic or a story involving a lot of people, we create a story / epic specific slack channel. Pay attention to the slack channel. Without slack channel, engineers are supposed to ask questions about ticket as comments on the ticket. Respond quickly to questions.
Acceptance criteria changes
On acceptance criteria changes during implementation: There always can be cases, where the implementation phase uncovers that acceptance criteria are not possible to fulfil, unattractively expensive to fulfil, that major amounts of time could be saved or the UX improved by making adaptions to the agreed upon acceptance criteria, or that the existing acceptance criteria did not cover all user flows / cases.
The PM is responsible for acceptance criteria.
In the case that an engineer runs into one of the cases described above, it’s up to the engineer to bring the information to the PM, and help to make a good decision on whether / how to change the acceptance criteria.
It’s the PMs task to ensure that the ticket keeps reflecting the acceptance criteria. Decisions, whether they happened verbally, or on slack, need to be put into the ticket’s acceptance criteria. Otherwise the ticket will get stuck in code review or in QA because the implementation does not match the acceptance criteria, or, worse, some engineers might not know about the agreement and implement the old acceptance criteria.
Information duties
Inform engineers pro-actively… …when translations arrived. …there’s been acceptance criteria changes. …when responsibility changes. Don’t leave for vacation without having mentioned and documented in the ticket who is now responsible. Onboard your replacement properly so that he / she is able to drive the topic like you did. Missing clarity on who is responsible is annoying.
Change review
If you specified that your “ok” is required before the release, review quickly when the ticket is ready. Maintaining code that’s ready to be deployed without deploying comes at time investment and context switching costs on the engineering side.
Post launch
TLDR: a release is only valuable if we share it with the audience, learn from it, and measure the outcome.
Retro
For bigger tickets, schedule a retrospective with all involved, so that we as a team learn how to get better together. As retros are time intensive, it can be a good idea to collect points asynchronously.
Release announcement
Make sure that a feature release is communicated with stake-holders. For bigger changes, a demo at all-hands is a nice way to celebrate the release.
Learn from the hypothesis
Set yourself reminders to check whether the ticket’s hypothesis fulfilled itself or not. Schedule user interviews / check analytics. Share the outcome. Not having a follow-up is demotivating. If no one ever speaks of a feature release afterwards, it feels as if the feature is not being used and the work was wasted. Without follow-up we miss a valuable chance to learn.