As an E-learning product manager focusing on developing digital platforms to deliver staff training and personal development application, my day-to-day work involves requirements discussion with developers, testing/feedback sessions and engagement with key product stakeholders (mainly product owner and sponsor). In my blog, I used to write about some core skillsets that product managers must have. Depending on the nature of the product and the type of product users, the skillsets vary. For me, since I work in a B2B area and having a solid understanding about the business process is of great importance in the product delivery lifecycle, the business analysis skill can’t be sifted through my skills matrix. I spent 60% of my time on planning business analysis activities and managing requirements lifecycle, which includes but is not limited to requirements elicitation and collaboration, requirements analysis and design definition etc. For the rest of 40%, I will use 20% to do system testing and provide feedback whilst keeping the rest of 20% for relationship management. Since the product owner and sponsor of my product all comes externally, I need to make sure we have an appropriate communication plan to keep them accountable, informed, understood and more importantly, happy with our deliverables.
Looking back on how fast we were in upgrading our product in the past two and a half years, the small UI enhancement, along with continuous integration, not only fleshed out the product via hundreds of iteration, but also landed me a great team, which I can always trust and turn for support. There is no doubt that we have been through ups and downs, misunderstanding, loads of discussion around quality assurance etc, that all helped shape us who we are, an unbeatable team. As a person who likes to do reflection (this is also an essential skill for product managers) in a hindsight, below are the important lessons I would like to share when working with the development team and doing product management.
1. Convert raw requirements into actionable requirements for designers and developers
During the first year of my product management journey, I used to focus more on facilitating the requirements collection session and barely put those requirements analysis activities under my radar. Both designers and developers went through the initial requirements without verification or validation process and jumped into the action directly. This did not make a good impression on our sponsors and product owner whenever we had a system demo. Sometimes, the team will need a steersman to support them to see a broader picture ingrained in these requirements from various stakeholders’ perspectives. A great product manager should be able to “transform” these raw requirements to actionable requirements that are easy to understand by designers and developers. Here are a few techniques and tools that take always take matters into my own hands.; Users stories, wireframe, user journey description, data entity modelling, business process modelling, use case and requirements classification. It’s not necessary for you to master a programming language or some designing tools, but speaking a similar language with your designer and developers can avoid miscommunication and help lay a foundation for the comprehension of functional and non-functional requirements during the delivery process.
2. Users are not always right
We are all supposed to think outside the box when it comes to product innovation. This happens quite often when we brainstorm the feature enhancement or product upgrade based on users’ feedback. We are too eager to think of ourselves as end-users and sometimes, thinking it “too loud” without any data analysis as proof of evidence could put us into a deadlock and invest a huge amount of time in developing something non-essential. While treating users’ feedback as an important source for a product upgrade, we also take a data-driven approach to validate those requirements extracted from users’ feedback. Users may not know what’s good for them as they are not designers or domain subject matter experts. Sometimes, what a great function for one user type does not satisfy another user group’s needs. What we need to do is to find out the user acceptance criteria as well as the baseline, design and develop the features that satisfy most users. Most importantly, use the data collected from user behaviour to guide the decision-making process.
3. Forster a documentation culture within the team
I know doing proper documentation can be very frustrating sometimes. It requires the product manager to be equipped with critical thinking, analysis and business-technical writing skills. We are used to considering documentation skills as one of the most crucial disciplines the product manager needs to focus on and it’s a big fraction of product managers’ daily jobs. However, this skill should be a generic skill that can’t be taken off from any team member’s skill matrix. Both designers and developers need documentation skills to track, monitor, maintain and prioritise the requirements and requirement changes. They will also need the documentation if they want to review and revisit the features discussed before. Cultivating a documentation culture within the team will keep everyone engaged and accountable in the delivery process and ensure the items are trackable. Typical documentation includes business case, project charter, market analysis, competitive analysis, user research, user story, project roadmap, product requirements and product specification, KPI (key performance indicators), prototype and end-user material (user guide, user feedback, product manuals).
