As Product Manager, I often get asked if I use any framework in my work. So in this post I share more about the framework I use: the Product Pyramid. This is a way to holistically manage your product and make decisions about its future.
Whenever discussing the work of a Product Manager, people often ask whether or not there is some framework we use. To be honest, there are many of them and all of them have advantages and disadvantages. The most important is that you as a Product Manager, CEO or someone who has to make decisions about the future of a product looks at it holistically. It’s also very important to try and stay consistent throughout the whole product management lifestyle. If you design a product for kids for example, it doesn’t make sense to make the product too complex.
So this post describes a framework that can help you think holistically about your product, consider each aspect of a product throughout its full lifecycle. I call it: The Product Pyramid.
The Case
Because I like to make things really practical, we will define an example case that we can use throughout this post: Imagine you are approached by a bank to help them launch a new artificial intelligence (AI) based personal finance banking app. How do you approach that problem? Here are levels in the pyramid to ensure you think holistically.
Precedent
Before you decide to build or change a product, it is wise to consider what was the reason to consider this opportunity to begin with? That’s why the first layer and the foundation is called the Precedent. Were there other systems in place before? Is the problem already solved in some other way? Is there a strategy behind considering the product?
The banking app case: Does the bank have some kind of strategy around this problem? Does the bank seek to also contribute to the use of AI? Is there an existing app you could edit or extend? How is the personal finance problem solved currently? Are there existing products that need to be considered alongside this case?
The Person
Any product is used by someone, or at least is created to be used by someone. This is normally a person, but it can also be another system, which behind it again has a person. You can always examine any case for a potential product and eventually, somewhere down the line find a person whose life will be impacted by using your product. Stopping to consider the persona first before anything else is important since this has consequences for how you view the problem and eventually the product. It might present opportunities, limitations or constraints. A persona comes with habits, social context, certain levels of tech savviness, average device types, problems they find important, values, income, etc etc etc. Finally, don’t forget other personas as well that your main persona needs / wants to interact with: advertisers, sellers, other people
The banking app case: Is this app targeted at families or high networth individuals? Young people? Seniors? Will the persona or app connect to other banks? Other service providers? Is this a marketplace to connect people around something? Will the person actually be other banks only (not end-customers)?
The Problem
Once you have the persona defined, the next step is to look at the problem that they are facing. Also ask yourself when do they encounter the problem? Is it a stand-alone problem or mixed with other stuff?. It’s important to think about the underlying problem or emotion your persona might have. Often a user completing what seems like a surface level task, is actually trying to solve a much deeper problem of emotion, belonging, happiness or reducing fear.
The banking app case: Is the person trying to optimize their personal finance? Are they trying to just transact with less effort? Or are they trying to mitigate a fear for their personal finances? Is this about trust? Etc. All these would require a different app entirely.
The Product
Notice that so far we haven’t even talked about a product yet. Only once you have the problem and persona clearly stated, only then do you go to the product. Many people jump to this part first and start with: “let’s develop an app that… “. The product doesn’t have to be an app, it can also be a service, or a physical object. Within the app category you also have a lot of choices to make: web, mobile, backend etc. In tech we obviously look to technology but we need to keep the persona and problem front and center here.Here you have to keep in mind that your minimum viable product (MVP) can be different from your final product. You can test with a service and then turn it into a piece of software later.
The banking app case: Do we build an app? In case of less tech savvy personas, perhaps a finance assistance service is better (and cheaper when you consider support). If it’s an app, then do we focus on mobile or web? If the persona is another bank in our example, then perhaps we should build a library they can embed or an API they can call.
The Parts
Now that you have decided the product that you would like to launch, you can start thinking about the features, or the parts that make up the product. Here it becomes crucial to check back at the original person and problem. The product becomes the context within which your persona solves their problem. Here you also start thinking about Critical User Journeys (CUJs). There is a lot of material out there about CUJs, but at a high level you can think of these as tasks a user would want to complete with your product. They are sometimes described like this: “As a user, I would like to….”. This is the part of the process when you star thinking about actual features like: search, ranking, voting, algorithms, scores, actions etc etc come in. Often you can accomplish a lot with a little so I would encourage you to keep your product as simple as possible even if you have very sophisticated users. Try to validate things first before adding more.
The banking app case: So if your persona was a young person that doesn’t know how to manage their finances, then perhaps a personal finance score could be interesting for them. If the product is an API for enterprise apps, then perhaps your product could be an algorithm that calculates the likelihood of upsell later. Remember that if your persona was less tech savvy, then more complex features aren’t a good fit.
The Performance
Once the product is completely designed with its parts (the features) you need to think about how you will measure its success. Here it becomes vital to revisit the original problem that your persona is trying to solve. Your metrics need to be as closely related as possible to that problem, but also be in line with the goals of your overall business (ideally these are related). There are many metrics frameworks out there. I would encourage you to try and stay consistent in The Product Pyramid (aligned with precedent, persona, problem) and try to take different angles (input metrics, output metrics).
The banking app case: If we decided to create an app to match experts to people wanting advice then we can look at usage of the app and how many connections we make. We can also look at metrics that hint at the quality of connections. If we decided to develop an API to offer to other banks then we can measure the amount of requests but also look at quality metrics to measure how correct our API responses are compared to what customers expect. Obviously if the precedent taught us the bank wants to increase revenue, we should try to measure that as well.
Publishing
Finally, once the product has been designed and the metrics determined, you are now ready to consider launching. This is a part that I personally sometimes have neglected since you get so taken up with the design of the product. if you have an awesome product but you don’t launch it well, you don’t get the adoption your amazing product deserves. In this stage of The Product Pyramid you can use metrics to ensure you don’t push the product at all costs, since if your personas don’t solve their problems, they won’t come back to the product, you get that initial boost of usage and then it drops off.
Launching well should consider the entire Product Pyramid so far. You could do marketing over a period of time or do a one-off launch event. You need to think about the channels your persona uses where you might advertise, your budget and constraints. At minimum your launch should allow you to validate core hypotheses you had so far and at best move the metrics you define in the desired direction.
The banking app case: Launching an app for young people would require a different approach, perhaps with advertising on social media vs an inter-bank-api which you could for example launch at an enterprise conference.
Piloting
Once the product is live, you need to adjust it and pilot it through its life. Keep in mind the persona and problem. This might make you iterate, from a service to an app for example. Also keep the product well maintained, keep abuse out of your product and keep an eye out for additional parts to build that will better help your personas solve their problem. Sometimes you discover a problem that the product didn’t intend to solve but your product still does that. The piloting stage is also where the strategy around the product comes in. You can expand into new personas or new geographical areas. You can expand the product vertically: more features, more similar products; or horizontally: more different products in the space.
The banking app case: Imagine you created a personal finance app for young people and saw lots of traction but also started to see other banks use the app to generate scores for their users. This might give you a hint that developing the inter-bank-api we mentioned before is a valid use case. You could also think about developing personal advice products in other areas like insurance.
Conclusion
So there you have it. Use the Product Pyramid as a way to ensure you’ve covered all aspects of your product throughout each part of its life cycle. Check in regularly to see if you’ve missed something and ensure you stay consistent throughout. Happy product launching!
