The CARDS Product Management Framework
A structured approach to identify opportunities and create solutions to improve products
Abstract
A common interview question that an aspiring Product Manager will come across asks, “How would you improve {product || feature}?” A strong candidate’s response will display an understanding of the current situation of an existing product, propose potential solutions to any problems that the product may currently have, and describe how they plan to execute on those solutions. I know this because I have been asked this question in interviews, and initially I was not well prepared with a clear, holistic response.
I have since learned from that mistake, done some research, and been gifted with some great insight from Product Management sages in order to craft a framework for my response. This framework takes a variation on the CIRCLES framework made popular in the book Decode and Conquer: Answers to Product Management Interviews. The CIRCLES framework is a great way to structure an answer to product design questions such as, “How would you design {product || feature} for {persona}?” However, I have found that when using this framework for product improvement questions I spend a lot of time on the design aspects in my response, I have little time for other key topics such as ensuring the alignment of product strategy with company goals or proposing a plan for execution, and ultimately my response is not well-rounded or complete. This becomes particularly problematic since most Product Manager interviews are timeboxed to an hour or less and the product improvement question is just one of a series of three to five questions. Therefore, to ensure that my response answers the question in its entirety while adhering to time limitations, I follow what I will hereby refer to as the “CARDS framework.”
Using the framework below, I have had much more success developing a clear, holistic response to product improvement questions. If you have recommended edits for this framework, have a different framework that has been successful for you, or just want to talk product then post a response to this blog or connect with me on LinkedIn (please include a note about this blog in your request).
List 1. CARDS framework for answering product improvement questions
- Comprehend the situation
- Analyze users & users’ needs
- Recommend a solution
- Develop an execution plan
- Summarize
In this blog, I will use the CARDS framework defined above to structure my response. I have created a fictitious company called Awesome Bank. Awesome Bank is a digital banking company with a product that’s been on the market for four years. The product consists of several modules one of which is the Spending & Cash Flow module. The remainder of this blog will answer, “How would you improve Awesome Bank’s Spending & Cash Flow module?”
Phase 1. Comprehend the situation
In this situation, I am going to imagine that I am the Product Manager for the Spending & Cash Flow module of Awesome Bank’s mobile application. My objective is to identify weak points of the current module and to create an improved solution. Following the CARDS framework, I must first comprehend the situation. I will state the mission of the company and identify the company’s business model and value driving capabilities to ensure that my improved solution aligns with the company’s current situation.
Awesome Bank is on a mission to “revolutionize the world of money” with Awesome Bank serving as the “digital bank for anyone, anywhere.” The company has shown success so far announcing on their website that they have signed up 4 million customers. Account growth is clearly a key objective for Awesome Bank as the Founder & CEO has publicly stated a goal of 100 million customers within the next five years. Therefore, the improvements to the Spending & Cash Flow module must align with this greater company goal.
On their website, Awesome Bank highlights “built-in budgeting” as a key value proposition of their mobile application. To satisfy this value, Awesome Bank has a Spending & Cash Flow module that will “show you exactly where your money is going each month and allow you to create monthly budgets that track your daily expenses.”
Along with built-in budgeting, Awesome Bank also provides :
- Instant payment and spending notifications
- Free international money transfers
- Fee-free spending around the world
- Fast account creation
- Achieve your financial goals
- Spare change savings program
- Access to cryptocurrency exchanges
In addition, I will want to know how Awesome Bank makes its money so that it can continue to pursue its mission. Additional research illuminates that Awesome Bank generates revenue from the following :
- Top up fee for transferring cash from a third-party bank to the user’s Awesome Bank account
- Markup to the exchange rate during certain periods e.g. weekends and holidays
- Delivery fee for a spare Awesome Bank card
- Fee to expedite a transfer from two business days to one
- Fee for transactions over a certain threshold per month
- Tiered fees when spending certain currencies e.g. Thai Baht, Russian Ruble, or Ukrainian Hryvnia
- Overdraw fee when users withdraw more than their monthly limit from an ATM
- Tiered monthly fees for Awesome Bank’s premium services e.g. “Select” cardholders and “Preferred” cardholders
To summarize, Awesome Bank’s business model includes revenue generation from fees, time-based markups, and premium services.
The current situation is that Awesome Bank has built an interface for the Spending & Cash Flow module that contains weak points in providing the previously stated value proposition. In my response to how this module can be improved, I will identify these weak points, prioritize the most impactful ones to address, and propose a solution alongside an execution plan for that solution.
Phase 2. Analyze users & users’ needs
The weak points in Awesome Bank’s current Spending & Cash Flow module can be found in the module’s ability to satisfy its core value proposition for its users. In the previous phase of the CARDS framework, I identified the module’s core value proposition as to display monetary transactions and to allow for setting up monthly budgets. I must next identify the users that Awesome Bank seeks to serve and the actual needs of those users. I will then assess if the module’s current core value proposition aligns with that of Awesome Bank’s users and, if not, determine a solution that is aligned.
User Research
User research starts with identifying users. Sources of information about users include the company’s mission statement, market research, and product data. Listed below are common characteristics of Awesome Bank users extracted from these sources :
- 18 years or older
- Male or female
- Have one or more existing accounts with third-party banks
- Own a mobile device i.e. a smartphone and/or a tablet computer
I can also *assume* that the users of the Spending & Cash Flow module will be money conscious. I can also *assume* that the users of the Spending & Cash Flow module will be familiar with budgeting or “money management” applications as these are standard with many banks.
User interviews
Compiling the characteristics above into a template for the types of people who would use Awesome Bank, I would interview individuals who fit this template to identify and understand their needs.
In the interviews, I would ask them questions such as :
Do you budget your money?
What do you currently use to create and manage a budget?
What is your process for creating and managing your budget?
What are the metrics that you care about when you are looking at your budget?
Would you be willing to pay for a mobile budgeting app?
Do you have any investments in cryptocurrency?
For the sake of this blog, I have gone ahead and conducted some user interviews to seed the rest of my response to this product improvement question.
Current user journey
In addition to the questions, I also presented the interview participants the current Spending & Cash Flow interface and asked them to walk through how they would use it. Every participant followed a fairly similar flow which I documented and will refer to henceforth as the “user journey.”
Understanding the user journey provides insight into how users think about the process that the product asks them to complete. If the user is unsuccessful or experiences severe difficulty with completing the process, the Product Manager has identified early on a low-hanging, high priority recommendation for an improvement. Watching someone use our product also forces us to see the journey through another’s eyes which can help to recognize moments where a new capability or flow can be added.
The current Spending & Cash Flow follows this journey :
- Set a total monthly budget goal
- Set a categorical monthly budget goal
- Monitor the total and categorical goals
Additional research of other money management solutions revealed this user journey to be standard across them all.
Personas
Conducting several user interviews will draw out patterns in users’ characteristics, behaviors, and needs which the Product Manager can aggregate into a persona: an agile technique made popular by Alan Cooper in his book The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy. Cooper advocates for personas during what he calls the “requirements investigation process” in which the components of a release are determined. As the purpose of this phase of the CARDS framework is to determine what should get built, I will use personas as well.
Described below are the primary personas derived from the user interviews that I conducted.
To summarize, in this phase of the CARDS framework I analyze users and their needs. I do this by conducting user research which includes identifying user characteristics to create templates of individuals to engage for user interviews and then using the results of these interviews to determine the optimal user journey and to create personas. These personas will ultimately be included in the assets delivered to the product team to guide execution. In the interim, the personas will serve as the foundation for the next phase of the CARDS framework where I discover and define a solution.
Phase 3. Recommend a solution
Interviewing users and thinking critically about the current user journey brought to light that the core value proposition of the Spending & Cash Flow module is not strategically aligned with users’ actual needs. Recall from the previous phase that we defined the core value proposition as to display monetary transactions and to allow for setting up monthly budgets. The user research revealed that most users consider these functions table stakes for any banking application and therefore already have an existing solution that satisfies these needs. Rather than competing on features of a holistic money management application, the strategic direction for Awesome Bank to take in improving the Spending & Cash Flow module would be to satisfy additional user needs based on the capabilities unique to Awesome Bank that I identified in the Comprehend the situation phase.
In this phase of the CARDS framework, I will aggregate these additional needs and recommend some improvements to the Spending & Cash Flow module to solve these needs.
Improvements
Based on the user interviews, I first create an exhaustive list of user needs that could be satisfied by the Spending & Cash Flow module. For brevity, I have condensed these needs into a shortlist of the top five based on how valuable they were to users and how dissatisfied users were with existing solutions. I then brainstorm improvements that would satisfy each of the top five user needs.
In addition to the top improvements, I also identify “could have” improvements: a term used in the MoSCoW prioritization method. These improvements include “Allow users to turn on push notifications within the Awesome Bank application since the experience works best with push notifications” and “Notify users who try to set a categorical budget that is the same as their monthly budget.” These improvements would be added to the feature backlog as fodder for development resources that become available during sprints to optimize the user experience.
Prioritization
I then prioritize the improvements using a variation of the ICE framework, made popular at GrowthHackers by CEO Sean Ellis, by assigning each improvement three variables and calculating a score. The first variable represents an estimated level of impact that the improvement would have on new and existing users. The second variable represents an estimated confidence level that the improve will achieve the desired outcome. And the third variable represents an estimate of the amount of effort that would be required to develop the improvement. These variables are then averaged to produce an ICE score.
Develop an execution plan
This phase of the CARDS framework is arguably the most important especially for a Product Manager. In fact, a primary reason that I derived this framework was the lack of representation of this phase in the CIRCLES framework. Until now, the majority of the work that the Product Manager has done has been in tandem with other teams such as Design, User Research, Customer Success, etc. However, the Product Manager is ultimately responsible for execution i.e. ensuring that all the feature ideas actually get developed and determining a cadence so that the features are released in a timely manner. Therefore, a complete response to a product improvement question should also include a plan for executing those improvements.
Product Roadmap
I start with a favorite tool of the Product Manager: a product roadmap. The roadmap below ensures the timely release of all the priority improvements from the user research and is aligned with Awesome Bank’s long-term strategy. In the first sprint, the product team will focus on releasing high impact improvements that will appeal to new customers so that we can quickly understand whether these will drive new growth. During this sprint, we can also create the Machine Learning algorithm that we will train and utilize in later sprints. In the second sprint, the product team will focus on releasing medium to high impact improvements that require less effort so that we can optimize development capacity across a larger set of features. During this sprint, we will continue to train our Machine Learning model as well as analyze the results of the improvements released in the first sprint. In the third sprint, the product team will develop the remaining priority improvements including the budget recommendation engine based on the Machine Learning model that we built and trained over the past 2 sprints. During this sprint, we will continue our analysis of the the improvements released in the first sprint as well as those released in the second sprint. At the end of the third sprint, the product team will have released all of our prioritized improvements and have quantitative and qualitative data regarding the success of the improvements that we released which we will use to guide the planning for future sprints.
Prototypes
While the product roadmap establishes the cadence for release, the execution plan should also include a detailed representation of what Engineering needs to build. Historically, this has taken the form of a product requirements document or “PRD.” However, I prefer the more modern approach of using prototypes for the basis of a product specification, an approach made popular by Product Management sage Marty Cagan. This approach starts with low-fidelity prototypes which get tested and iterated on to produce a high-fidelity prototype.
For the improved Spending & Cash Flow module, I create low-fidelity prototypes like the ones above for usability and interaction testing to ensure that users would be able to complete all tasks. Based on the results of these tests, the product team would iterate on the prototypes until a majority of users can complete the tasks successfully and enjoy the experience. Once this has been achieved, I turn the final low-fidelity prototypes into a high-fidelity prototype.
Pictured below is the high-fidelity prototype that I have built for this response using Moqups, a web-based mockup, wireframe, and UI prototyping tool.
After producing the high-fidelity prototype, the product team could perform another round of usability and interaction testing to reveal potential errors in logic and to fine-tune the navigation. Once finalized, this high-fidelity prototype would be included with the personas in the assets handed over to the Engineering team for development. In the handover, the Product Manager should work with the Engineering team to breakdown the components into front-end and back-end tasks. The high-fidelity prototype can also be used to align with other internal stakeholders e.g. the C-suite, Marketing, and Support.
The high-fidelity prototype pictured above provides an interactive representation of what the improved Spending & Cash Flow module should look like and how the user should navigate the module based on the research performed in the previous phases.
Metrics
There are a number of metrics frameworks that Product Managers can use to determine the right quantitative and qualitative data for evaluating the success of a product or feature. For my recommended solution, I will utilize a combination of the AARRR framework and the OKR goal system.
Awesome Bank is primarily interested in Activation i.e. the moment when a customer opens an account with Awesome Bank. The secondary focus is Retention which is the moment when an activated customer gets the value promised and returns to the product. It is outside the scope of this paper to address metrics for retaining users. However, I have seen success in using the HEART framework, made popular at Google by UX Researcher Kerry Rodden, to identify metrics that will create a “happy” user experience which will incentivize users to return to the product and progress from the Retention phase to the Referral phase.
With an understanding of Awesome Bank’s goal, I then use the OKR system to break this high-level goal down further into measurable goals. For those unfamiliar with the OKR system, the “O” stands for Objectives and the “KR” stands for “Key Results.” Objectives are what is to be achieved. They are significant, concrete, action oriented, and inspirational. Key Results benchmark and monitor how to get to the objective. They are specific and time-bound, aggressive yet realistic, measurable, and verifiable.
The product team will know if we have achieved success with the improvements if we achieve the Key Results for the Spending & Cash Flow module by the end of the quarter in which they are released. The Product Manager should be closely monitoring these metrics and consistently reporting the results back to the team.
Monetization
As a final step in this phase, I will also propose some ways that Awesome Bank could monetize on my recommended solution. This is not necessarily a requirement in a response to a product improvement question. However, a Product Manager is ultimately responsible for the end-to-end success of a product or feature which includes influencing how it will contribute to the company’s bottom line.
The competitive analysis that I performed in the Comprehend the situation phase shows that most budgeting applications on the market today are free. In addition, all of the people whom I interviewed in the Analyze users and users’ needs phase said that they would not be willing to pay extra for the Spending & Cash Flow module of Awesome Bank. Therefore, I propose that the Spending & Cash Flow module be made available for free for all pricing plans. Rather than allocating a specific price for the Spending & Cash Flow module, Awesome Bank could monetize its value through other channels.
Awesome Bank could incorporate the module into the value propositions and pricing strategy of other modules and programs. For example, if the Spending & Cash Flow module implemented my solution to recommend purchases based on vendors registered with Awesome Bank then that would increase the value proposition of a registered vendors program. This program could then give its members the option to pay an additional fee to be included in the Spending & Cash Flow recommendation engine, or the program could increase its base price to reflect the increased value proposition.
Awesome Bank could also charge a fee for users to integrate their Awesome Bank account with third-party applications. For example, all of the people whom I interviewed indicated that at some point they have used the Mint application by Intuit for budgeting. If the Spending & Cash Flow module implemented my solution to build an API for integration scenarios, Awesome Bank could charge a small fee for users to integrate with Mint. The fee could be charged to Intuit based on calls to the API, or it could be charged as a flat rate to the user. The research needed to determine a specific pricing strategy is out of the scope of this paper. In addition, this feature could be added as a free service to the Select and Preferred pricing plans to increase the value proposition of those premium services and create an upsell to the default pricing plan.
Phase 5. Summarize
The final phase in both the CARDS framework and the CIRCLES framework is to summarize all of the work that has been done in the previous phases. A Product Manager is constantly aligning with stakeholders across the company and therefore needs to have the communication and decision-making skills to present the most relevant points to colleagues who range from being intimately involved to completely removed from the process. A good summary will help to influence stakeholders and to endear them to the problem that we are trying to solve.
Awesome Bank has an ambitious growth target of 96 million customers in four years. The Spending & Cash Flow module must be aligned with this goal if Awesome Bank hopes to achieve it. The improvements that I propose in this blog would create a better solution because they leverage Awesome Bank’s unique strengths to produce a money management application that is differentiated from competing applications and therefore would attract new customers.
My proposed solution is based on a proven framework. My first step was to comprehend the situation by determining the goal to be achieved and understanding how that goal aligns with the company’s mission and value proposition. I then identified the target users to achieve this goal and interviewed individuals that matched the characteristics of these target users to comprehend the users’ needs. I then brainstormed some improvements by creating user stories based on the information from my interviews and then devising ways to address those user stories. I prioritized these improvements based on the ultimate goal and produced a roadmap to dictate a timeline for their release. Finally, I defined success metrics so that the product team could evaluate whether the improvements are achieving the desired objective. In addition, I proposed ways to monetize on these improvements. Performing this exercise resulted in 10+ prioritized solutions and an execution plan that Awesome Bank could implement to improve the current Spending & Cash Flow module.
New data could change my recommended improvements. For example, if Awesome Bank was to shift its primary objective from customer acquisition to customer activation then I would need to: reprioritize the current improvements, conduct additional user research, and define new metrics e.g. daily active usage, key user actions per session, and/or NPS growth.
My next step would be to monitor the metrics to assess if we are achieving success.
Conclusion
In interviews, Product Managers are often asked a product improvement question that typically takes the form of, “How would you improve {product || feature}?” In this blog, I provide a clear, holistic response to an example product improvement question based on the CARDS framework: a framework derived from the CIRCLES framework. My response displays an understanding of the current situation of the product, recommends a solution to address improvements that the product could implement to address key user needs, and describes a plan to execute on that solution.
I have had much more success developing a clear, holistic response to product improvement questions by following the CARDS framework. If you have recommended edits for this framework, have a different framework that has been successful for you, or just want to talk product then post a response to this blog or connect with me on LinkedIn (please include a note about this blog in your request).
About the author
Colin Kraczkowsky is a Product Manager who loves to build products that sell themselves. Colin’s professional history includes working in both enterprise and start up environments to launch new products, build mockups and prototypes, develop applications, analyze metrics and continuously innovate.
In his spare time, Colin can be found checking out the latest Alite camp kit for a weekend away in Big Sur, planning his next line down a mountain at Kirkwood, or surfing the Horror section on Netflix. Colin is currently located in San Francisco, California.
Connect with Colin — https://www.linkedin.com/in/colinkraczkowsky
