“The future depends on what you do today.” ― Mahatma Gandhi
Presented below is the model I’ve landed upon after a decade of Product Management. When I reflect, I realize why Product Management is such a challenging and rewarding role – our job is to mitigate any risks that hamper future growth and demand for our products and, of course, predicting the future is impossible – great career choice, Ravi! 😊 The question that has constantly nagged me for ten years is, “Will someone care enough about what we’re building to pay us for it?”.
So here goes, hopefully some of this structure improves our (yours and mine) odds at anticipating the future (since we can’t predict it). A lot of this is nothing new in concept, so please excuse the verbosity below, but it can be hard to implement given all the crises and distractions that rock a Product Manager’s day-to-day life.
At the highest level, I believe there are some practices that need to be followed consistently for the product plans to be meaningful – the actual roadmap can and should change quite a lot over time as one tests their hypotheses with real customers through an Agile process.
First, it is key to define the customer (the paying entity) segment in terms of industry, geography, company size etc. etc. and think about the current size and future opportunity – this is not easy if we look at it from the “who uses our product today?” perspective – everyone ends up with customers they didn’t think they would get. For example, I inherited a team that ran Product Management for a widely used, highly scaled product used in every conceivable industry by companies of all sizes. Given the mind-boggling range of target markets, we deliberately started focusing on a specific industry not because of our past success but because we saw the potential room for growth in that industry according to market research. Other industries were important but did not offer as much opportunity for growth so the roadmap started heavily biasing towards solving the problems in this target industry. So, the moral of the story is that you have to make choices on who your customer is and focus your research and your development efforts… very rarely can you avoid making this choice so, get on it!
We need to then explicitly document and discuss the current tools, workflows and processes in our target industry and identify the users (people who touch the technology) in that workflow who we want to serve – in my experience this is best done as a collaboration between user researchers, experience designers and PMs visiting or talking to customers to document their workflows (if you’re in a small company, the PM does it alone). Know that there could be multiple user types that benefit from our tools and they need to be explicitly called out. Of the user types, we need to explicitly define which users would be key to driving adoption and prioritize their problems first… for example, capturing user type A might create an ally inside the customer’s organization to drive adoption with user types B and C. Also, it is important to map out the dependencies between these users… sometimes the only way to deliver value is to solve a problem in a way that serves multiple users at the same time.
We need to then be explicit about the problems faced by our target user type in the target customer type (industry, geo, etc. etc.) – every need and feature request must be reworded in terms of the underlying problem. We should not jump to solutions (as tempting as it is) because everyone (from executives to PMs to development to Sales) needs to be clear on the user type, customer type and the problems we’re trying to solve. If there is a debate (which there will be) it should be about the importance of the problems we want to solve not a particular solution we want to implement – this is because every problem can have multiple solutions (some of which are not development tasks – better training, better customer support, better documentation, the PM’s personal cellphone number for every customer 😊 etc. etc.).
We also need to be explicit about prioritizing the problems, think in terms of two variables to score the problems for prioritization – pervasiveness and severity (higher the better). It is key to think about the pervasiveness and severity in the context of the target user and target customer/industry.
Once there is some common understanding of the prioritized industry, prioritized user type and the prioritized problems then the fun part of imagining the solutions, the new workflows begins. This is a cross-functional job and should include PMs, Technical Architects, Development, Experience Design. The solutions can be scored for priority based on the following variables…
- Differentiation – How different/better is it compared to the competition or the status quo? The PMs need to know the competitive landscape or current alternatives for this one (higher the better)
- Cost – What is the R&D effort in terms of time and people? The Development Managers need to provide rough estimates (lower the better)
- Risk – How certain are we that we know how to solve the problem? Sometimes there is need for pure invention so the risk is high. The development and software architects need to weigh in (lower the better)
- Barriers to adoption (the silent killer of best laid plans) – How easy will it be for the target users, in the target industry, to adopt this solution? This is where experience design and user research can really provide some insights. (lower the better)
One can create a cumulative formula from the scoring described above to create a prioritized über list of solution proposals.
The final roadmap or backlog then is a list of prioritized solutions derived from the list of prioritized problems derived from a list of prioritized users derived from a list of prioritized customer types. Ideally, the prioritized customer types list changes least frequently and the prioritized solutions list changes most frequently as hypotheses are continuously tested through an Agile process.
This kind of list also makes it easy to evaluate the value and adjacency of potential acquisitions because, ideally, you’re looking to solve a broader range of problems for the same/similar customer type (since you may have already expended the energy and the cost of acquiring said customer and/or your go-to-market partners like marketing and sales are experienced at targeting and acquiring these customers).
One last thing is to maintain a list of mandates – these could be things like infrastructure updates, critical customer reported bugs, other unavoidable initiatives etc. that are non-negotiables. We all know they happen and its best to keep bandwidth free and have an open mind when they come and translate the mandates into their underlying problem statements.
I hope all of this helps… I have learned that having a structured way of thinking reduces stress, improves decision-making and brings sanity to a role that can feel like constant fire-fighting. The scoring/prioritization described above is still dependent on the PM’s judgement but breaking the process down to focus on customers, users, problems and then solutions clarifies the PM’s thought process and provides justification to get stakeholders and peers on board for execution.
If there are things here that don’t make sense to you then please write me a comment. I am a student of the art and craft of Product Management and I would love to learn from all your experience.