One of the most important skills for a Product Manager is the ability to write perfect features.
A “perfect” feature must be exhaustive and unambiguous. It should contain the minimum relevant information to be self-contained and self-explanatory.
When thinking about a new feature or an improvement, the product manager has to consider all the implications of its implementation. You need to step back and look at the big picture. The task will not be implemented in the vacuum. On the contrary, features and improvements must be integrated with the existing product seamlessly.
After such “fly over the mountain” look, the product manager has to drill down to the nitty gritty details to be sure that the ticket contains all the information needed. No space for doubt or personal initiative must be left to the engineering team. All the steps must be clearly listed, the whole flow carefully described.
I find it extremely useful to structure a ticket using the following sections:
- Status Quo
- Acceptance Criteria
It can be extremely powerful to write the feature down as a short story which illustrates the business logic behind it. One of the best way to do so is using a user story.
Writing a story helps you explain to the engineering team why we need a feature, which is the strategy behind it. It is also important to include the developers in the discussion so as to increase their motivation and improve the quality of the result.
The starting point is to understand which is the current situation. And even more, it is important to know if you are correctly estimating it. Therefore, it is wise to describe the current flow as you understand it and use it to discuss with the engineering team and create a common ground.
That is even more relevant when filing a bug because – in the status quo section – you can describe the necessary steps to reproduce it and the configuration (browser, operative system, etc.) used for the test.
When a modification is necessary, it is a good practice to explain why the implementation was created the way it is in the first place.
The goal is the heart of the ticket. In this section, you explain what you request of your engineering team. Depending on the specific type of ticket, attachments and/or images are fundamental to create a clear picture of how the feature has to be implemented.
When filing a bug, a good way to explain the steps to reproduce is to create several screenshots and highlight the actions performed. To facilitate the job of the developers, snippets of code, links to forums, references to previous tickets should be added to the goal section. When submitting a new front-end feature, it is necessary to attach wire frames and design specifications to convey all the details related to the UI.
All in all, what is important is to include the minimum amount of information to realize the feature. Bullet points are great at it.
When managing a multi-languages platform, it is useful to include the keys for the translations – and the translations themselves – inside the ticket. The developers will have the chance to experience how the UI behaves using different locales and they will be able to work effectively with the design team to fix it.
After a feature has been implemented, a bug has been fixed or any task has been carried through, it has to be tested usually by QA. It is important to clearly state what has to be tested and how. In case the ticket to test has many threads and conditions, it is wise to divide the section in different scenarios with specific steps to reproduce.
More about features
If you are interested in digging deeper, you can find more information on how to design perfect features by downloading (for free) the e-book I wrote:
Latest posts by Maurizio Bellemo (see all)
- How to connect inbound leads to your Pipedrive sales funnel - January 24, 2016
- The (not so) secret affair between ads and gaming industry - March 18, 2015
- How To Write Features Like A Pro - February 23, 2015