The Product Management Hierarchy of Needs
Maslow’s Hierarchy of Needs is usually portrayed as a pyramid with the largest, most fundamental needs at the bottom. The lower level needs must be satisfied before the higher level needs can be met.
I think a similar theory can be applied to Product Management and I’ve captured it in this diagram:
So, starting from the bottom…
The most basic need for a Product Manager is to have a problem to solve. The best products and companies stem from a real, well defined problem. Google made finding web pages easier, Amazon provided a greater choice of books and Paypal simplified online payments.
Impatient ‘entrepreneurs’ will often focus on a problem that doesn’t exist and try to convince others to go along for the ride while they fulfil a dream of being ‘CEO & Founder’. Likewise, Product Managers can often get into a rut of delivering features that aren’t really needed and offer no value.
Your idea must be viable — understand and validate the problem to make sure it exists and is painful enough to justify any work that goes into solving it. (It’s ok to go after smaller problems if your outlay is minimal).
Successful products can come from seemingly nonexistent problems e.g. over 75 million Tamagotchis have been sold ‘just for fun’, but remember, it’s harder to sell a vitamin than a painkiller.
Tip: Use the 5 Why’s approach to get the underlying problem and understand the real pain points.
If you’ve validated that there is a problem and the risks/unknowns have been reduced enough to justify moving forward, then you can address the next basic need — users.
For an idea to be viable, there must be people who are willing to use your product (and pay if you’re selling it). This links very closely to the the why because if there is no market for your idea then it’s usually because you are not solving a real problem.
There can be times when a seemingly good idea is not viable because of user perception or circumstances e.g.
- People don’t want to be seen using your product
- People can’t access your product
- The people who need it, can’t pay for it
To satisfy this need; know your users; talk to them, put things in front of them, watch them. Make sure you can answer questions about who they are, how many they are, where they are, what they do, their motivations/pains.
Tip: Identify the persona(s) that will use/buy your product. Before building anything meet with at least 3 of each persona and buy them coffee/cake until you’re confident you can answer all the above questions and more.
You’ve now satisfied two needs: there is a problem to solve and there are users who want it. To be valuable, your product must benefit your users by delivering a solution that solves their problem.
Any solution you identify must also be feasible, i.e. can you create it within any constraints e.g. resource, expertise, the laws of physics….
Example — Building a human teleportation device definitely solves a transport problem, and definitely would have users, but is it an appropriate solution when compared to e.g. better public transport.
Make sure any solution you create is linked back to the problem you’re solving and the users you are solving it for. Favouring Lean Methodologies and putting your solution in front of users early and often offers guardrails that stop your product going too far astray.
Tip: Sketch out the current user journey and mark everywhere your solution impacts this flow. Check that your product will have the desired effect or change at each point you have identified.
If you have identified a problem, and your target market can use your solution to solve this problem then you probably have something close to the fabled Minimum Viable Product or MVP. (In this article I have emphasised offering value to your users so I think Minimum Valuable Product is a better term to use here.)
Once you have satisfied the most basic three needs and have an MVP Product Managers will naturally look to improve, refine and optimise their product. Maslow’s description of ‘Self-actualisation’ transfers well to this stage;
“the desire to accomplish everything that one can, to become the most that one can be”
Translation — you want your product to be the best that it can be.
This is ‘the how’, and can generally be held under the umbrella of User Experience (UX). User Experience is more than just the order that screens are shown in, or the location of tooltips and buttons. It includes the whole user journey from the moment the user finds your product, downloads/opens it, registers on it, shares it, reports issues with it, upgrades it, pays for it etc. If your app is great but nobody can find it or download it, then is it offering any value and is it really a great app?
UX is the final need in the Product Management Hierarchy and therefore offers the greatest level of freedom to be creative and individual. Learn what your users like and don’t like, experiment with A/B tests, put thought into design and optimise at every stage. Remember, simple is not easy and it’s often better to improve a product by taking things away rather than defaulting to adding things in.
Tip: Use the Kano Model to categorise work items and implement delighters alongside your core product. Delighters are great ways to influence the UX and make your product sticky and loveable.
If you think in terms of needs, and the order in which they are satisfied, then the process for solving problems becomes clearer:
- Start with why and understand the problem
- Know your users inside out
- Your solution must offer value
- Optimise the whole User Experience to make your product loveable
I believe there is a lot more to add around this theory but I like to eat my own dogfood so I’m publishing my thoughts early to get feedback. Let me know if you thought this was an interesting read, do you have an alternative view or something to add?
If you’re interested in learning more about all things Product Development then make sure to hold down on the clap button and follow me and the publication.
You can also find out more about ucreate and the products we provide at ucreate.it