Knowledge Base

Knowledge Base

  • New to Product Management function: here are your ‘quick’ tips

    First of all, let’s draw our understanding to fact that Product Management is ‘the most critical function’ for any product organization. Decisions you make here can make your product a success or failure, and in result the organization.

    Fair enough, now with ‘sense of responsibility and the commitment’; let’s start carefully and step by step. I will propose here my view of the 5 most important aspects for the starters to be successful Product Managers.

    1. First of all, you need to get trained thoroughly on the all aspect of your Product. What market problem it solves and how? Get a complete understanding of all the features and provisions. Your focus should be to become a ‘Product Champion’, both internally and externally, in the shortest possible time. Also, get trained about wider product aspects such as its environment and limitations (and so on).
    2. Product managers role differ from company to company. You can have core responsibility of ‘Product Backlogs’ or you can also be responsible for Product Marketing function, or Product line management too with the responsibility of profitability. Please communicate clearly what this role is about in your company (and what it is not). Here this article primarily discusses the ‘Technical Product Management’.
    3. A Product Manager should understand the customer pain area in the ‘right context’; as you will be the ‘voice of the customer’. For instance, if you are coming from a programming background, you would need to mold your thought from ‘how to solve’ to first think ‘what to solve’ and have complete clarity about the problem in customer context. If you are coming from a Business Analyst background, you may like to focus on extending your thought to solve ‘many customers’ problem simultaneously. Your focus should be to ensure the skills to understand correctly and appreciate customer’s pain point and take it forward internally. Please take self-grown exercises to groom this skill.
    4. Prioritization- the Previous point being very important and it is a basic ingredient for prioritization. As ‘champion of product internally and externally’, you are assumed to take no time to understand the overall degree of severity of customer pain point and define appropriate priority. To develop any priority matrix, you may like to use weighing analysis in tandem with management strategic directives and market gaps.
    5. You have to realize that as a product manager you are an ‘Individual Contributor’ with no formal authority. And while illustrating requirements to engineering team or QA team, you are a successful team player. Product Manager needs to deal with internal stakeholders of Engineering, Marketing, and Sales; often good Product Managers see a practical difficulty here and you should groom your skills to deal with each stakeholder effectively. (This may result in further optimizing your sprint and roadmap.)

    There are indeed many more, I will share them in the coming post; hope these stands as a good starting point for you.

    Good Luck!

  • Agile or Waterfall: which is good for a new product and which is for the existing one?

    First of all, this article is not about the old debate which methodology is good to use. It’s quite written about the pros and cons of each methodology; the article is indented to evaluate different needs through various stages of the product lifecycle and deciding which methodology is to be used (when). It emphasizes for a situation-based decision instead of rather stereotyping on either Agile or Waterfall; the decision should extend beyond from mere ‘what-to-use’ to ‘when-to-use-what’.

    If you are having a bright idea and already thought to roll out a new IT product, next answer you face in most probability is ‘how to optimally organizing the development?’. Towards next step, you are ideally looking at rolling ‘Minimal Viable Product’ (MVP) at the ‘earliest’. MVP would be not only expected to open fortune doors; also provide a solid testing ground of your idea with first customer’s feedback. And if you need MVP ‘earliest’, thought of employing the ‘Agile Methodology’ is obvious as it is almost synonymous with the delivery speed.

    I agree, however, let’s weigh the need against the primary objectives and try to arrive at a rational decision, analyzing each attribute.

    Our primary objectives for a product are-

    • To solve a market problem
    • And solve it in most ‘effective’ manner

    You would be first testing them with MVP with your first customers. Upon positive feedback from them, you would like to reach to maximum numbers of potential customers quickly and moves towards attaining your financial objectives.

    Towards the first objective, i.e. to solve a market problem, you must have done an exhaustive market research and ascertain the potential. In the process, you have also identified the features that must go in the MVP and listed their all the associated requirements. You want to impress your first customers with your MVP and leave no stone unturned; you will be needed to work with the ‘total clarity’ in the development.

    Well, you will interestingly find you are already working with ‘waterfall methodology’ and need no confusion what methodology to use at ‘this stage’

    In my experience and opinion, it is always beneficial to use ‘waterfall methodology’ until you successfully rolled the MVP. Not only it logically maps with the need, but it also gives you better satisfaction on ‘completeness attribute’ with MVP; which is very critical for your product success. at MVP level and thereafter.

    Actually, the decision which methodology to use starts after MVP is rolled out and first customers have populated your ‘product backlog’ with their feedbacks and suggestions. At this stage, you would ‘start’ (not shift completely) working with Agile. My suggestion for this stage would be to shift the existing feature enhancements and bugs to ‘Agile Product Backlog’ and keep new/ big/ important features development continue on ‘Waterfall’.

    At a later stage, when product attains maturity, you would hardly have new feature scope and your development methodology would automatically become ‘Agile’

    In Conclusion: Agile or Waterfall?

    It is never going to be a complete Agile or Waterfall; even one may be significantly more used. You start carefully with waterfall and during the life cycle, existing feature enhancements and pain areas moves to Agile while important new (market differentiator) features are to be dealt with waterfall. As product moves to maturity, new features requirements are considerably less and product therefore would be more governed by Agile.