What should I built for the next release of the product? Which features yield more revenue? Is this product roadmap in line with company goals? These are some questions that Product Manager keeps thinking about every day. Most companies that have agile engineering and product management teams are challenged with this continuous and conflicting priorities. traditionally, you planned the roadmap/feature bucket once in a year and then development executed it. In the last 5 years or so more companies started to adopt the Agile methodologies and 2 weeks to 3 months releases cycles became the norm. This article provides an overview of the requirement sources that every product manager should be thinking about when working with the development leadership for the roadmap execution. Remember that the more you focus on one source and ignore the other, the more is the gap between what market needs and what product provides.
To make it simple, I believe that Product Managers should get business requirements from internal and external resources, document and prioritize them appropriately on the cost vs. value scale. It does not have to be a science project but a simple spreadsheet with major requirement themes and simple tagging would do. Below is some quick overview on what and why of each source of requirement.
External Sources
- Customer Visits : If Product Managers are not doing this then there is a serious problem. Once the market-fit stage is done, there is no substitute to visiting customers (buyers, influencers, users) on-site. If possible, spend time with them on how they do the work and try to document the pain points in the most generic way. Many companies become sloppy on the customer visits and highly prescribe the telephone conversations and web conference. But they are less useful and will not yield optimal results. Just get out of the building and meet your customers. Don’t look for a short cut. If you are working for a startup, you may not have real customers but talking to the early adopters, focus groups or at least some similar users (B2B or B2C) would help a lot. It is just the matter of meeting more users and getting more data points to make sure that your assumptions and direction are correct.
- Customer Advisory Boards : Whether it is a startup or enterprise, it is super important to create and nurture the customer advisory boards. They are the continuous source of the truth from beta or existing customers. Due to the nature of the group, the group could provide feedback once in a year and need to be clearly crafted. It is better to provide some feedback templates to customers instead of everyone filling their own way.
- User Meetups : Irrespective of the B2B to B2C, the end users always have good input on the tools that they use and how the UX is working for them. This could be developer or partner meetups to get in depth analysis on what’s relevant.
- Industry Meetups : Your startup or company sponsors the industry veterans so folks can talk and share their future direction. This results in insights from domain and technical challenges.
- Analysts : Should Analysts view be part of the requirements ? In my view, they work with huge numbers of the customers (current and future) and their view is a good validation point. Remember that working with analysts helps you to get the word out there in their reports and conferences. Make sure it’s a two-way communication.
Internal Sources
- Your Expertise : Product Manager is bestowed with the good decision capability on the product. Trust your instinct and validate them thoroughly. Sometime the product or service is one of its kind. No one has ever did something similar. So, in that case you set the baseline with your own technical and domain expertise.
- Development : Development teams are the product partners and don’t ignore the innovation coming from the development. Empower the development teams to innovate on the technology, process and execution. They know it the best and listen to what strengths and constraints they have in product development. In hi-tech industry, technology and architecture pretty much dictates the agility and flexibility of product development. Make sure that development can factor in all the infrastructure and operations requirements.
- Sales (Win/Loss) : Every sale that happens in the organization should yield the feedback on what went well and what can we improve. Companies may not exactly say they conduct win/loss analysis as prescribed by Product Management literature but rather have an informal way to document the deal highlights. Even worse, the sales feedback may not even come to PMs unless it’s a “Loss”. This makes it extremely difficult to understand what we are doing well and what can be improved. Win/Loss provides a great insight into the unfulfilled business requirements and their criticality.
- Operations Team : This could be the feedback from consulting or service teams. Consulting provides a great feedback on scalability (solution) pain points and service teams provide the ultimate usage pain points. Both teams provide very valuable feedback on the product strategy and product design. Never ever ignore to include and prioritize the requirements from these teams. Remember these teams bring recurring “happy and referenceable customers”.
Make sure that you don’t keep thinking that “I know everything about users”. This attitude shuts all requirements coming from multiple sources even if requirements are obvious. Involve all the parties and make them feel they are part of the process.
Do you have any other source that you collect requirements from ?