Product Map for Product Managers
Idea generation and validation — the skills, techniques and stakeholders and how they are connected
There is a huge amount of literature out there for the skills you need to have as a product manager at a technology company. There are countless frameworks, techniques and tools to use. You are told to be user-centric when building new features, you must be technical enough to work closely with a tech team and you need to report to stakeholders in the management team.
It can be confusing to get your head round all of it, it certainly was for me when I started working on products. So, I wanted to create a map for product managers that connects different components of the product ecosystem and discuss some suggested frameworks and techniques that have worked for me.
The article is split into two parts. First, we look at the initial stages of the product life cycle; idea generation and validation. The second part covers the execution of a product idea. The main components of the map are; life cycle phases, stakeholders, requisite skills, and tools.
Stakeholders
The main stakeholders/groups of people that you need to care about are (in a small company these may be the same person):
The Users — they use and hopefully pay for the product
The Business — they provide targets and resources including your pay, tech, marketing budget etc.
The Tech Team — they build the the product
It is vital that the product you are building interests and excites each of these groups in order for it to be a success.
In this part, we will talk about who the main stakeholders that a product manager needs to care about during these phases; The Users. We will then discuss the first and second phases of the product life cycle; idea generation and validation, the skills required and some helpful techniques to structure your work.
The Users
Here I define The Users to be any group of people, teams, companies, institutions etc. that use your product. There can often be multiple different groups involved e.g. in a marketplace app such as Uber, two user groups are the drivers and the passengers.
Product-focused companies have become increasingly aware how important it is to design and build their products in a user-centric manner. Techniques have been developed to generate, validate and execute new ideas, many of which have been used to build products that most of us use almost everyday.
The primary skill required at this stage is product design. This is broader than visual design. This is the ability to go from a roughly-defined problem space, collect and synthesise data through customer insights and analytics and then produce a relevant product solution
Idea generation
The first task in a product/feature life cycle is to generate product or feature ideas. These are often not hard to come by; user feedback, management suggestions, team discussions are all common sources. The difficulty comes when trying to understand how these could fit into the product roadmap and whether a critical mass of users would get excited about it.
Design Thinking
This is a common technique for ensuring that we are designing for the user. It consists of five stages:
Empathise
Understand who are the users, what are their issues, pain points. This can be done by conducting interviews for your target user segment.
Define
What is the problem we are trying to solve with our product or feature? What is the goal? What is our metric for success? Here you will make assumptions which need to be validated.
Ideate
What are some potential solutions? Are we going to build something totally new or optimise an existing solution? Prioritise based on company mission, product mission, scope, cost, time, value to users.
Prototype
Find a way to represent your potential solution as simply and effectively as possible. Build a MVP.
Test
Show internal teams and small groups of alpha users. so that you can validate your assumptions and get feedback. Now measure and learn and repeat.
This framework takes you past the idea generation phase into validation. It is a great way to guarantee building from the user’s perspective and an important and popular tool in modern product design.
Customer Jobs
This is an extension of the Jobs To Be Done (JTBD) framework. As well as aiding idea generation, this is can be used to better understand the forces affecting a customer’s decision making and the competitor landscape that your product sits in.
Job To Be Done
The underlying notion is customers use products and services to get jobs done; and while products come and go, the underlying JTBD does not go away. Harvard Professor Theodore Levitt once said:
“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
Customers don’t care about the specific product, instead they want the specific “job” to be done. Concentrating efforts on innovations solving for this “customer job” is more fruitful than incremental innovations on the current product.
Push and Pull Forces
Customer Jobs breaks up demand generation into two “forces” — Push and Pull. Push are the forces that cause customers to want to change their current behaviours and are motivating them towards finding a solution, they are the reason they look for a product to solve for the job in first place.
For example, a Push for buying an electric car could be; everyone in the neighbourhood is going eco-friendly so I don’t want to look like I don’t care about the environment.
Pull are the forces dragging customers towards a particular solution because they feel like it solves their “job” specifically. In our electric car scenario, this could be a pull to buy a Tesla because there are a lot of charging points near my work so it makes it really easy to charge during the weekdays.
These forces allow us to empathise with mechanics of the decision-making process of our customer. New product features should leverage these to acquire, up-sell and retain customers.
Further details found here.
Competition and Innovation
We can use this to better understand what the competition is for your product and where the opportunities for innovation lie. In general, customers only use one solution for each of their “Jobs” and when they start using another solution they stop using the original.
Be aware that solutions for the same job can come in unexpected forms; for some people, kale juice has replaced coffee as a way to keep awake in the morning. The JTBD here is staying alert in the morning, kale juice pitches itself as a healthier alternative to a traditional coffee.
This is how game-changing innovation happens, it’s not just thinking how can I brew tastier coffee beans, but instead how can I tap into a specific target market and create a totally new solution for the same job.
Revenue Potential
As a new product to the market, you need to have a clear understanding of whose budget you are taking away from. What is the revenue potential of your innovation?
Some problems persist because they are simply not worth solving.
Understand who is your competition for the Job you are solving. Know how profitable. Ask yourself questions like how big is the opportunity and how frequent is the problem you are solving?
At this point, we have a list of potential ideas with good reasons to believe that they may be good ideas and an understanding of the dynamics of the environment in which our customer is making decisions.
Now we need to prioritise.
Eisenhower Matrix
Dwight D. Eisenhower was the 34th President of the United States and as you can imagine had more tasks to do than time in the day. He had to make tough decisions daily on which tasks he should do. Eventually he came up with the Eisenhower Matrix as a tool to help him qualify tasks based on two dimensions; urgency and importance.
The top-left quadrant are the most important and urgent and should be done now. Top-right are less urgent but important so time should be allocated to complete these tasks. Bottom-left are less important so can be done by someone more junior but should be done now. And finally, bottom-right tasks are neither urgent or important and so should not be done at all.
In any company, resources are limited — time, budget, people are all scarce. We can use a modified version of the Eisenhower matrix for product development in order to prioritise which feature ideas take precedence on the roadmap.
We can qualify feature ideas based on two dimensions; business value and complexity. In the same way as for the original Eisenhower matrix, we want to prioritise the high-value, low effort features and allocate time in the future for those that require more effort.
We can quantify this concept by scoring dimensions for each feature and prioritise those features with the highest score.
An extension of this is to add new dimensions; for example, opportunity cost (e.g. can’t build other features elsewhere), cost of implementation (e.g. need to hire more experienced developers). The end goal is to have a quantifiable way of deciding which features will give the most value to the business in the most efficient way.
Idea Validation
Now that we have generated and prioritised our best ideas we need to validate them. You, your boss and the rest of the company might think you have come up with the greatest ideas of all time but the only people that matter are your users. We need to check with them before we spend 6 months developing a feature only you and your boss will use.
Customer Interviews
This is as simple as it sounds. Each interview will be different and depends on the type of product and who you are speaking to. Having said this, the overall structure should remain fairly consistent. Below is a useful structure I have synopsised from Sachin Rekhi’s article and included some example questions.
Overview — start with a very high-level sentence describing product. Idea is not to give an in-depth introduction but to give the customer a rough idea of the problem space that our solution is trying to tackle. For example, this could be mentioning an existing category of products they are familiar with or a process/workflow they engage in.
“We are building a product to help employees at companies communicate and share ideas more easily. It’s similar what Facebook did for friends and family but targeted at internal communications for companies”
Problem — the goal here is to discover the pain points the customer currently faces in this problem space. Start by asking broadly “What are the pain points you face today in this problem space?”. Then follow up with with a list of potential pain points you have heard from other customers including the one that our product is trying to solve, to see if any of them are relevant for them personally. It is important that customers speak specifically about their own experiences and not in general. Also, we want to understand the severity of the pain points identified. Rank them. Ask if they have any ongoing projects to try to address them. Depending on how proactive they are one is able to judge how high a priority this is for the customer.
“What are the pain points you face today in this problem space?”
“We have heard from a few people we have spoken to that it is often difficult to find particular communications, for example if you were to share a document via email it’s hard to remember who it was shared with and difficult to find. Is this something that you have found?”
Value proposition — next we want to give the customer an idea of the value our solution will give without any context or details. We want to test the initial reaction to the value proposition in order to gauge whether it is clear enough and get a sense of whether the high level solution resonates with the customer.
“We want to give all employees a single destination for sharing documents that is very clear and easy to use.”
Solution — walk the customer through the high-level description of how the solution works. What features does it provide? How is it different to the alternatives? If you have user flows or a prototype run them through. Get their initial excitement. Note down what words they are using. Ask them what features or scenarios most excite them and ask them to rank these. Then ask what is missing? What would they add if they could? What issues do they have with the solution?
“I would love to run you through our prototype to give you a better idea of how it could work.”
“Other solutions such as Dropbox are slightly clunky. From our research, we have found that many users get turned off by this resulting in low retention amongst employees.”
Competition — discuss alternative solutions. What other tools are customers using now to address this problem? How do they handle this problem now? How do they think our solution compares with others?
“We have tried to make our product as intuitive and clear as possible by hiding much of the complexity that comes with other solutions in the market.”
“How do you think our prototype compares to Dropbox?”
Target audience — verify the target audience criteria that we have come up with. Is the customer in the interview the end-user? For B2B solutions, identify carefully who the decision maker for the purchase is and who the key stakeholders are.
“Would you be the one making the decision to purchase our product?”
Acquisition strategy — figure out how the customer finds out about solutions in our problem space. How did they hear about our current solution? How do they evaluate solutions? Who is involved? How do they prefer to engage with similar products i.e. website or sales rep?
“How have you discovered tools in the past e.g. direct sales, LinkedIn? What do you prefer?”
“What is the process for buying software at your company?”
Monetisation strategy — probe the customer’s willingness to pay. How much do they pay to solve this pain point today? It’s important to assess both in terms of competition pricing and value our product is generating. Get them to walk you through how they would calculate this value as this could help you calculate value-based pricing options.
“What do you currently pay annually for Dropbox? Do you feel that is reasonable?”
“How would you value our product? Would you be more willing to pay for extra users or extra storage?”
Vitamin or painkiller — arguably the most important part of the interview. A vitamin product is just “nice to have” whereas as a painkiller solution is one where the user is desperate to solve a problem and is willing to take action now. We need to determine if our solution is a vitamin or a painkiller. There are several ways to glean this depending on stage of product. You want your product to be in the top 5 in the current or next quarter’s priorities to implement. If several of the customer’s excuses are that they have too many other things going on that’s a bad sign and an indicator of lack of product/market fit.
“If this product were available today where would it sit on your priorities to implement and deploy?”
“Would you be willing to sign up for a pilot and commit to a call per week so that we can get feedback and continue to improve the product?”
After each customer interview you should have a slightly better idea of which assumptions you made are good ones are which are not.
It will be obvious when you have done enough interviews as you will have a crystal clear idea of the who your customer is, what their problems are and how you can help them.
Only now do you have enough information to decide whether to proceed with the execution of an idea.
This process is powerful not only for this feature but yields returns for future product development. It will allow you to better prioritise your product roadmap and generate more relevant ideas in the future.
We will see in part 2 how to execute on a product idea or feature.
If you liked this article please give it a clap!
If you really liked it, you can hold down for multiple claps!! :)
