As a product manager it’s not uncommon to feel pulled in a million different directions as you work to meet the needs of your customers, developers and company stakeholders. While there are a large number of tools which claim to help you to create value, for me, quite frankly, it boils down to only a few secret weapons which do not (most of the time) involve buying fancy software or subscribing to the latest project management doodads.
The practices I describe are not an exhaustive list of tools and methods. But they are good examples of what my team and I have developed together over the last four years at Zalora. They show what has worked for us successfully day in day out, and demonstrate that the powers of a PM boil down to communication, documentation and data!
Communication Powers
Stakeholder Meetings
I meet my business stakeholders once a week. We meet at a regular time – which we block out in our calendars – specifically to sit and talk.
There are times when we are done after a five-minute check-in with each other because everybody is pretty much up to date. At other times our meeting can span over an hour because there are lots of different topics to cover or we want to discuss the battle plan for one specific project in depth. The important message here is that you reserve time for each other and that everybody knows that this is the place and time to show up and discuss things.
I have seen many honest attempts and promises between both parties to “meet more often” or to “keep each other in the loop”. But in reality both the PM and the stakeholder are so busy that this can be easily neglected. Without this weekly meeting, you can find yourself lost between feature releases that your stakeholder doesn’t know about yet and email threads which talk about new projects that you’ve never heard of.
If you have several stakeholders to take care of, schedule a meeting with each one of them. If you feel like meeting once a week is too much, in some cases fortnightly or monthly check-ins are enough.
Retrospectives
Retrospectives are a great way to check in with your development team. Although you don’t have to be the initiator to organise a retrospective, you should certainly make a move to organise one if this has not yet been adopted by your engineering team.
At Zalora we let every development team decide for themselves how often they want to hold a retrospective and who should be a part of it. It is open for PMs to join and for those who are working very closely with the team it is mandatory to participate.
Slack
This one doesn’t need much introduction. Just about every IT team I’ve come across in the last 12 months has adopted Slack as their communication tool. Since it comes with a fantastic range of customisations, it helps to notify a group of people in real time and in a more meaningful way than an old-school email inbox ever could.
We have adopted Slack as the main communication tool for the Zalora engineering team. Some of the business teams have also adopted it and created their own channels for collaboration.
Release Notes
This is particularly important in large-scale organisations or when you build a customer-facing product. There are thousands of ways the rest of the company can find out about the new stuff coming out – word of mouth, asking for an update on chat, stumbling over a new feature when using your website. Give your stakeholders and users the comfort of announcing new stuff via release notes!
Make sure you notify them proactively – no one will go to a static web page of release notes and hit the refresh button every day – and present the information in a way that is easy and fast to digest. But please note that release notes are not meant as a user guide – level up your documentation powers for this weapon of choice.
At Zalora we send out a nicely designed email for every major release to a large number of people in the organisation to reach as many people as possible. And we store every release note in a company-wide shared Google Drive folder to make sure people can go back to one place in case they missed out on it.
Templates to Report Issues
Are you flooded by a ton of issues? And for every poor soul who encountered a bug you need to write another five questions back to find out how to reproduce it? You can empower your stakeholders by giving them a template to fill out whenever they find a problem.
Google Forms is your friend here. Letting people fill out a form will speed up time to resolution. It creates fewer communication loops and forces people to send you all the relevant information in one shot. You should spend some time and thought into how to design each field the stakeholder is supposed to fill out. You can even customise the form depending on the type of issue being reported by the stakeholder.
Documentation Powers
Write a Handbook
Internal stakeholders need to know how the products you build work. So make sure you have a company Wiki or similar in place, somewhere people can learn about the inner workings of your platform. This should not be confused with technical documentation. Your stakeholders will be intimidated quite easily if they have to fish for information in between the code samples that can be found in a tech document.
We use Atlassian’s Confluence for how-to articles on specific features that are targeted for an audience which is already using Jira since both can work nicely in conjunction with each other. For a complete handbook on how to use a certain software product we use Wikipedia’s open source MediaWiki to create our own company Wiki as a knowledge base accessible to anyone within the company.
Strategy Paper
Never heard of this one? Let me explain. In a strategy paper you lay out why a certain topic is important to the company. You explain the business opportunity, the challenges that come with it, the measures you plan to take to overcome them. The paper should cover a larger initiative which can then be broken down into separate experiments and features in order to execute the strategy laid out in the paper.
Examples might include your product recommendation strategy if you are an ecommerce company, your payment strategy if your game app offers in-app purchase or how you plan to reduce manual workload with automation in your company’s warehouse – there is no limit to the range of topics that you can cover with such a paper.
At Zalora, we choose a very simple structure for this document:
The Vision – The vision lays out the target audience, what they need, and how you plan to deliver a unique offering. The vision can (but doesn’t have to) include details of the market opportunity, size of target customers, positioning, competitive analysis, and goals, as well as open questions you have before starting the journey.
The Goal – The goal is defined by of a list of output KPIs which measure whether you attain your goal. These are then broken down into input KPIs which contribute to reaching your output KPIs.
Strategy and Actions – This describes the strategy and the actions you plan to take to execute it.
Milestones – Milestones can be used to link back to the product roadmap and can even point to tickets with the detailed specifications for development. List the features that you plan to develop so that stakeholders can refer to them and have an overview how many resources you need to deliver the strategy.
The strategy paper can be a living document that is edited along the way. It’s very hard to know upfront which of your actions will be fruitful. Sometimes you will not get the result you expect and you will have to change course. After all, if the problem is easy to solve you wouldn’t need a strategy paper to guide you.
Tickets
There is a large range of ticketing tools available and I won’t go into evaluating them here. Rather, I want to highlight why such tools are important to document your thoughts and expectations for any given development task.
For me a good ticket is one that has a structure which is easy for anyone to understand – even if the reader is not aware of the context or doesn’t have a deep domain knowledge. In larger organisations especially you need to be able to explain why a ticket is important as well as what you plan to achieve with it. Not everybody can have the same topic expertise as the product owner, so keep that in mind when writing a ticket.
Once this is nailed down, a developer is much better prepared to follow your thoughts and contribute effectively to what you plan to achieve. That’s why all of our tickets at Zalora (including bugs) start with a section called “Motivation” where this is explained. For bugs you can then explain how to reproduce the issue and what the expected behaviour should be.
When you develop a new feature, you can explain what the feature will look like and how the end product should behave. This topic alone is probably worth another post so just remember that the structure of a ticket is important and that it is worthwhile defining a template that the whole team agrees on.
The Power of Data
Big Data
We all want reliable data to guide and justify our decisions. And that’s why you must make sure you have enough data, the right tools in place to collect it and that you take the time to analyse it.
There is an abundance of tracking software available. If you are starting out fresh I would advise you to explore Google Analytics and Google Firebase. Both tools allow you to make sense of what is going on and either confirm your assumptions or visualise problems you were unaware of. Data can give you an abundance of inspiration for your development process and confirm if you are on the path to a successful product.
Small Data
If you come from a data-driven organisation then this is a tricky one. Small sample sizes will be shut down easily since they lack the statistical significance of big data samples – there is some good news here. User research studies show that 85% of usability problems are discovered after interviewing and observing a sample size of as small as five people.
I think this good news for anybody who cannot get access to large samples of data. User research and user interviews are your friend when you test new waters and want to know not just what is happening but also why it is happening. My message is that both small and large data sets are important – so get familiar with both of them and use them as the third superpower in your arsenal of product manager skills.
I practise all of the above tools and methods myself and they have been a great help in building a strong product organisation. Each one of them is easy to pick up and can work alone as well as in conjunction with each other. What do you consider to be your superpower? I am curious to find out in the comment section below.
Comments 1