Are you looking to up your product management game, or are you looking to break into a new role as a product/project manager. In this article we will cover some of the project management principles that we use to get product out of the door and have everyone walk away with a smile. Stick around to the end, we will and give you some pointers too.
Product management is a crucial function of any organization. If an organization creates product or takes on projects, they will need to do some product/project management to some degree which can manifest in many different forms.
At the end of the end of the day, we can break down a project/product managers roles into its most important aspects, which are universal.
- Communication to relevant participants (stakeholders, management, customers).
- Setting long term vision and strategy for product/projects.
A product manager needs to have a good understanding of the products needed and specifications/expectations set by its stakeholders and customers.
The product manager should be able to communicate clearly and effectively with the parties concerned and understand their needs,frustrations and such. They need to think of how much they would like or need to involve the client in the products development. To what extent will the client be involved in goal setting, revisions, timeline, decision making some clients love and feel the need to be hands on while others may take a more laissez-faire approach and have the confidence to let you handle everything.
A product manager should choose at what stages in the products development would the client need to be involved. It will be important to agree and set communication lines and response deadlines for both parties to avoid delaying or stalling the project. It would be best practice to document the important aspects and details of the communication so as to keep track of how the client participated in the product development. If there is ever a need to look back you can reference this. This documentation can help you explain conflicting proposals from clients, missed deadlines, increased budgets and many other issues that may arise.
Basically, a product manager needs to understand how they feel and go back to the technical teams handling the product development and communicate to them exactly what issues are at hand. The product managers along with the technical teams need to brainstorm, prioritize issues and choose what direction will be taken. The product manager does not exactly need to be part of the technical team building and working on the products, but smaller companies would benefit from it.
There are many methods which companies use to help them decide how the want to allocated and prioritize their efforts.
Below is a list of some methods you may use to develop a project roadmap, a game plan.
- KANO model
- Story mapping
- Opportunity mapping
- MoScOW method
You will have to research these as they are not exactly the focus of this article, however, we will look into one of them.
Here at Digitize Africa Online, we typically use the KANO model when working on our products. We don't have the resources to build everything we would like, so we need to prioritize and choose direction when working on a product. Typically when we have gone through an brainstorming session and looked into multiple ideas and directions that we could take a product in, we would need to score these different ideas grouping them into distinct categories.
The first grouping category would be the "must haves". These are specifications/features that a product would expected by the customers as a bare minimum. It won't make them happy but a product will come across as incomplete with out them.
The second category is the "performance" set of features. This category may very well dictate how well the product will be expected to satisfy its customers as including these features will mean the product will performs well.
The third category is the "attractive" set of features. These are features that tend to excite the end users and generally make them feel some satisfaction when these features are included. Leaving them out won't may go unnoticed to the users however.
Fourth is the "indifferent" category. These are features which are not expected to be really noticed by its users. Whether it is included or not, the reaction to the product may remain the same. These features may be left out as features that fall in this category they are probably going to be a waste of time and resources.
Two other notable categories are the "questionable" and "reverse" set of features. The features that fall in the questionable category end up there because they do not give any actionable insight. They seem to be in contradictive and often point to a fault in how the evaluation of the question. A user can not dislike a feature and also want it included in a product, it is 'questionable'.
Lastly are the features that fall in the "reverse" category. These features cause the dissatisfaction when included in the product. They tend to make the users dislike the product more if included.
The KANO model is a century old model which has stood the test of time, it works! It however may have gone through some minor iterations over the years
So now that we understand the different sets of features we can group our ideas/features into, we may then move forwards to showing you how an evaluation of all the different ideas/features would be done. An evaluation will help us will help us understand and predict how much the customers may like the features and gauge its importance. Later the team will then estimate how difficult and resource intensive building the features may be and also what kind of timeline would be projected to ship this product.
Typically we want to stay away from working on features that are difficult to work on that will probably not make the customer feel satisfied or even worse, make the feel dissatisfied. These feature generally fall in the indifferent and the reverse categories.
Below is an evaluation table which may be used to evaluate and categorize the different ideas.
The evaluation process is sort of like handing out questionnaires, we ask a negative "dysfunctional" question and a "functional" question concerning a feature. For example if our feature is video support in a blog, we would ask "How do you feel if we added a video support in our blogs?" and "How do you feel if we never added video support to our blogs?" a functional and dysfunctional question respectively. If an average of answers collected showed that most people "expect it" and also would not mind if it was left out ("live with it"), we could then conclude that this would fall in the indifferent category of features.
We would need to carry out an evaluation of all features and this may be represented as tables, graphs and maybe even presentations. This step is crucial to ensure the whole team is on the same page, in this phase of the product development cycle it will become more apparent if there is a misunderstanding as more questions are asked. It is important to remember that these features were categorized in a subjective manner and one could argue that it is not really factual. If a feature you like was left out, the team members may pitch their ideas again next time there is a brain storming session as product development is a repetitive process.
Once an evaluation is done the product managers would need to explain to the stakeholders/customers why they have chosen a specific direction or influence the stakeholders decision on the way forward with the product. But you may wonder, why should anyone listen o the product manager? Data is the answer. For example, If a product manager has to explain to an executive for why they won't implement an idea, it will only be compelling if this is backed up by some relevant data.
This means product managers need to listen to what the people interacting with the product are saying, which may not be as straight forward as you might think. But market research is not the focus of this blog.
So what does a product manager do? We could say that the product manager is a key player in the development of the product i.e product development. They will build a roadmap that sees a product go from concept to reality and onto the iterations that will evolve your product and see it improve and maybe take a completely different direction all while testing and adjusting to the market.
As we approach the end, I will leave you with a list of items would say are crucial to proper product management skills. Working on any on these categories will surely up your worth and maybe even double it as a product manager.
- Communications - written and oral, emails, documentation, meetings, presentations. Needs to know how to drive meetings and discussions that are effective and productive.
- Prioritization - milestones/objectives, KPI metrics, project/product health, time management, team leading and delegation.
- Product - understand the product and its market, discover problems and solutions, create product road maps.
- Leadership - influence stakeholders stakeholder management, have people aligned with the strategy team leading and delegation.
- Listening - to the customers and get meaning, and insight that is actionable, understand their needs and wants