Fintech R&R☕️🔢- Getting Your Priorities in Order
Prioritisation frameworks, their pros and cons, factors to consider when selecting a framework or matrix, and some cheat codes
Hey Fintechers and Fintech newbies 👋🏽
Welcome to another edition of Fintech R&R.
Last week, I took a short trip over to the Emerald Isle to get a bit of downtime between more extensive trips and fintech product work.
During my trip, I visited the Irish Whiskey Museum, a great homage to the history and origins of Irish Whiskey. The tour guide dropped some great gems, giving context to phrases we use often.
‘Blind Drunk’, for example, comes from the fact that during the prohibition age, when folks tried to make moonshine, they drank it before the methanol evaporated, leading to partial and sometimes full blindness.
Or ‘Dead Ringer’, stemming from the same issue of alcohol poisoning causing people to fall into temporary comas and lead to them being presumed dead and therefore being buried alive. To ‘remedy’ this, people would attach a piece of string to the body and the other end to a bell so comatose patients who woke up in a coffin could ring the bell and be rescued.
Using this as inspiration, I WAS going to clarify some common myths in fintech product development, but I want to look at another slightly more pressing area of fintech product instead.
Prioritisation.
This is partially inspired by my time standing in the Ryanair ‘Priority’ queue and looking at the non-priority customers who seemed to be boarding faster than me. But it’s also an area touched on in the last edition covering Tokenization and ApplePay. In it, I mentioned that as there is a bit of effort required to implement tokenized cards, it’s a matter of understanding the benefits, alignment with strategy and balancing that with the effort and costs.
Prioritising features on a roadmap or in a backlog might seem like a relatively straightforward task, but there are many frameworks, different factors that need to be taken into account and, of course, the need to factor in some space for volatility (timelines going over, business objectives changing, resources becoming limited).
So, as well as interesting news, puns + movie references, this edition includes the following:
An intro into the world of feature prioritisation
Different prioritisation frameworks
Pros and cons as well as the best uses for each
Factors to consider when picking a framework
Some Prioritisation Cheat Codes
NB. This isn’t the most glamorous subject, but I'll cover it in a fair amount of detail as it’ll serve as a reference edition for future write-ups about roadmaps, strategy, feature types and more. It will, of course, still have an upbeat and fun tone. 😊
Prioritisation Prerequisites
Mission Critical
Three phrases come to mind when broaching the subject of feature prioritisation and prioritisation in general:
Getting your priorities in order
Getting your priorities straight
Re-assessing your priorities
I’ll tackle the two similar ones and their relevance here and touch on the third one later.
Getting priorities straight/in order is a phrase more commonly used in personal rather than work life, but there is a link there. It’s often used when trying to achieve a specific objective or goal in life, for example, trying to be a little healthier, making a big purchase like a house, getting married or going on holiday.
In all these cases, there is a specific high-level objective, followed by a list of tasks in a to-do or checklist, which are then ordered in a sequence relevant to the objective and specific to the individual’s needs.
Using the wedding example, there’s often a standard set of priorities linked to a venue, food, flowers, etc, which will be weighted and ordered in terms of the overall objective and the specific needs of the people getting married. Some might prefer a better venue rather than fancier food, and some might see the wedding as a boozy party, so they will focus on great music and a good-sized dance floor.
The point is, just as with prioritising things in normal life, prioritising features on a roadmap, progressive versions of a product, or items in backlog starts with having a clear picture of what the overall mission is, understanding the subsequent objectives and ensuring that prioritisation is driven by both.
Going back to those two prioritisation phrases, there are verbs in each that hint at prioritisation using a mission/objective:
-> Getting them straight - i.e. In line with the mission or objectives
-> Getting them in order - i.e. In order to achieve a specific mission or objectives
Having a clear mission and set of objectives is the primary prioritisation prerequisite (apologies for the tongue-twisting alliteration).
A cinematic example of someone who, when given a mission, will figure out what needs to be done to achieve the mission and prioritises those tasks accordingly is, of course...Ethan Hunt. So think about him when you’re prioritising features and aligning them with the mission (but maybe lay off the extreme stunts).
The right tool for the Job
There are different ways to outline the objectives and communicate this for use in the prioritisation process.
One that I’ve referenced in previous editions and used in my career, more recently with client projects, is the Jobs-to-be-done framework. I covered this in more detail in the SME Jobs-to-be-Done edition, but in short, it’s a framework for understanding customer needs by identifying the key problems through in-depth research and reframing those problems into job statements that form the basis of critical areas of the product.
The JTBD framework has several benefits that I’ve outlined previously. In the context of prioritisation, it has the added benefit of providing clear job statements that can be used as objectives that features can be aligned against, feeding into the high-level mission and tying it back to actual customer research.
A byproduct of using job statements as the guiding light is that solving problems for customers is, by default, the main focus of prioritisation rather than prioritising features for feature’s sake.
Second Prerequisite
Another essential prioritisation prerequisite is clarity over the situational priority. The priority changes depending on the phase of the product, company and micro objectives. For example, products in beta phases are more concerned with customer feedback and looking for product-customer fit. Therefore, prioritising features that will engage and delight customers is essential. For products a bit later in their journey, features that will lead to low-cost customer growth, such as those that encourage P2P payments and some referral mechanisms, might be the priority.
These evolving priority themes are important to clarify as they feed into the thinking during prioritisation and drive the ‘impact’ part of many frameworks.
Diving into Prioritisation Frameworks
Talking about feature prioritisation in fintech products can seem a bit…well…pointless, as different fintech product categories have features that look obvious to implement on day one.
SME banking products usually have a digital onboarding journey, invoicing features, transaction tagging, tax pots, a transaction feed and ways to send funds.
Retail banking products also commonly have a digital onboarding flow, a card, a transaction feed, an account to send and receive funds through, and an overdraft facility.
Personal Finance Management products typically have an account connection process, a consolidated and bank-specific transaction feed, spending analysis, account administration features and goal-setting functionality.
The above set of functionality is common across many products in the industry. However, the best products tend to evolve, be unique and differentiate themselves from what has come before.
This is why prioritisation is important because innovators often come up with a range of features that far exceed what they can implement given the usual constraints of time, resources and funding, which is where prioritisation frameworks come in.
There are a surprising number of different prioritisation frameworks, including:
RICE Framework
Eisenhower Matrix
Impact vs. Effort Matrix
Risk vs. Reward
MoSCow Method
Kano Model
Weighted Scoring
Value vs Complexity Matrix
I won’t outline all of these as some are similar, and I’d rather go through the frameworks I’ve used practically (which you’ll be glad to hear is less than half).
MoSCow Method ☭
This is what I’d call one of the OG prioritisation methods. Anyone who did IT at school will vaguely remember this and how it works.
In short, it categorises features into four priority levels: Must-haves, Should-haves, Could-haves, and Won’t-haves, helping to clarify the most critical requirements.
It’s often visualised as a set of features grouped into four boxes corresponding to each priority level, with each level described as follows:
Must-haves: Non-negotiable features required for MVP or Launch, with which the product will be complete, compliant and generally viable. E.g. The ability to deposit funds and transfer money for a banking product
Should-haves: Important but not essential. Without them, the product is still usable, and these features will sometimes have a workaround until the feature is developed. E.g. In-app chat that can be fulfilled by an FAQ page and a few team members in the interim
Could-haves: Great to have but less critical than Should-haves, less impact if it’s not done, and try and do if there is enough time and budget. E.g. Personalised cards for a card proposition
Won’t-haves: Not a priority and won't be done as part of this phase of work, a nice to have but not enough impact to justify inclusion
The MoSCow method is a great entry point into prioritisation, but as it’s quite simplistic, it has elements of subjectivity and lacks numerical objectivity.
Pros: Simple to set up, visualise, prioritise and identify MVP priorities
Cons: Considered simplistic and can be subjective at times
Best Use: Initial prioritisation of a feature set to gauge priorities quickly and use it as a jumping-off point.
RICE Framework 🍚
The tastiest of all the methods, RICE is a scoring system used to prioritise features based on their potential Reach, Impact, Confidence in the estimates, and the Effort required to implement them.
It still contains an element of subjectivity when it comes to assessing the potential impact of a feature, but as the other factors are much more objective and measured, it’s seen as a more robust method.
The key part of this method is, of course, understanding those four main scores and how to generate them:
Reach: How many customers will this feature reach? It’s more effective to use absolute customer numbers or monthly average customers here, so if you have 10,000 customers and the feature will reach more than half, then use 6000 as the number here, but where the reach is constantly changing, it can be more efficient to use percentage numbers as long as it’s used consistently. So, using 100 where all customers will be reached or 25 when much less than half will be impacted.
Impact: This is how positively the customer will be impacted and how much this solves a problem for customers, converts them into a paying customer, generates a positive review or any of the other objectives the organisation might have. Unlike the reach figure, it is a bit trickier to put an absolute number on this, so many use a 1-4 scale, the impact numbers representing the following: 1- Quite Low, 2-Low, 3-Moderate, 4-High
Confidence: This percentage figure relates to confidence in the desired impact. For example, suppose the feature is a tokenised card, and comparable programs show high uptake and usage by customers. In that case, the figure of 100% can be used, indicating confidence in the impact of the feature. If you’re less confident, then 75%, if you have little confidence, then 50% or below
Effort: The total amount of effort required to deliver the feature, which will include development time as well as any complex analysis and marketing. It’s often expressed as person-days/weeks/months depending on team velocity, but some also use t-shirt sizes to estimate effort, i.e. Small (3 days), Medium (10 days), Large (30 days).
These factors all come together in the following calculation to generate a RICE score, which is then sorted from high to low, high being the lower effort higher impact features and low being higher effort lower impact: Reach x Impact x Confidence / Effort
Pros: Clearly prioritised list of features using objective measures and a deep understanding of impact & effort
Cons: It can get a bit sticky (sticky RICE, get it) and takes some effort to organise and structure with many stakeholders from multiple disciplines needed to provide accurate input. Not worth the effort on a small set of features.
Best Use: Post MVP fintechs with a clear understanding of development velocity and a reasonably large set of features to prioritise
Effort vs Impact Matrix 💪🏽
This method assesses features based on their potential value to the user or the business versus the effort required to develop them. It helps identify high-value, low-effort tasks.
Similar in simplicity to the MoSCoW method, this method requires stakeholders to get together and identify the Impact and Effort of each feature, which is then plotted onto a quadrant, making it clear which ones to do first. This is again where the JTBD framework helps as some jobs may instantly have a higher impact than others, but regardless, all prioritisation is done in line with solving customer problems.
There are nuances to how it’s used, but how I’ve used it before, and how it’s visualised below, is by grouping features into jobs statements and in a spreadsheet, giving an indication of Impact and Effort using high medium, low and then mapping these onto a grid in the appropriate position. It can be simplified further by removing the ‘medium’ and putting features into those distinct boxes.
Pros: Simple and easy to implement. Easy to score features.
Cons: Can become noisy with a large feature set and difficult to distinguish priorities.
Best Used For: Ideation of products, early-stage fintechs and mainly for roadmap prioritisation rather than larger backlogs.
Weighted Scoring 🏋🏽♀️
This method is used to assess and rank items based on a set of predefined criteria and their associated weights. It goes back to the ‘situational priorities’ explained earlier and is where features are first scored in terms of their fit with specific criteria such as price, UX, customer acquisition, etc., on a scale of 1-5, and then the scores multiplied by a weighting given to each criterion. In the case of the situational priority, that will be given a greater weighting.
Pros: Great at considering evolving value themes such as price, retention, etc. Simple to execute & visualise.
Cons: Limited in tracking against jobs and customer value.
Best Use: In conjunction with a framework such as RICE or Impact x Effort as a way of tracking the situational priority as well as alignment with the overarching mission.
Picking the best Matrix
When it comes to the movies, there is an obvious answer here. It’s The Matrix Revolutions, of course…
I’m kidding. It’s the first one. No argument can convince me otherwise.
However, the decision is more complicated when selecting an appropriate prioritisation matrix or framework. As you’ve seen from the ‘Best Use’ points, there are a few factors to consider when deciding on a single framework or blend of different ones.
Size of feature set - Some of the frameworks are geared more towards larger items at lower volumes rather than the other way around, so feature sets that have been broken down and span 100+ items can be challenging to prioritise on things like the Impact x Effort matrix as well as being messy when visualised.
Stage of company - In all of the fintech product concepts I cover, I mention the stage and size of the company because it’s one of the most significant swing factors in picking frameworks, tools and processes. Larger companies later in the product development lifecycle have more extensive feature sets, a better idea of velocity, deeper resources and tend to have clear product streams. Ideally anyway. Although early-stage companies may have a clear mission and objectives, they tend to have smaller feature sets, limited resources and less clarity on development velocity, which impacts matrix or framework selection.
Size, experience & technical ability of the product team/person - This might p*ss of product influencers because I’ve mentioned technical ability and product person in the same line. But the size, experience and technical ability of the product person (more common with early-stage fintechs) and product teams (the norm for later-stage fintechs) impact the framework selection. The complexity of the RICE framework is more challenging to manage as a non-technical, less experienced product individual, and less technical product folks will need more involvement from other stakeholders, sometimes making the process more resource-intensive.
These factors are crucial to selecting a suitable matrix or prioritisation framework to get a backlog in order or to set up a customer-centric roadmap.
Prioritisation Cheat Codes 🎮
As I’m talking about prioritisation with the perspective of experience at the coalface of fintech builds, I can’t ignore some of the untold reality of prioritisation.
As Mike Tyson says:
“Everybody has a plan until they get punched in the mouth.”
These are the metaphorical punches in the mouth you have to watch out for when prioritising a backlog or roadmap, which I sometimes call cheat codes, as they are a bit of a cheat for getting things prioritised outside of the typical framework.
G+I+O+T+F+R (Get It On The F***ing Roadmap) - This is often activated by founders or C-suite folks. It usually involves one of the people mentioned above requesting that something be added to a roadmap, which is initially met with resistance because it doesn’t fit into a JTBD or fulfil the impact, reach or any other prioritisation criteria, and then you might be told to ‘just add it’. This is not uncommon and is often just a matter of picking your battles.
I+A+C+R (It’s A Client Request) - This also comes from founders and C-suite but sometimes partnership teams and is a cheat code that gets used often and needs a bit of filtering. The size of the pushback on these types of requests can be a matter of how big and important the client is and the stage of the fintech itself. For early-stage companies reliant on client revenue, often the case for B2B fintechs, and especially the case where it’s their first client, all requests seem to jump the queue. Where the client is a big bank or another large client in terms of revenue and PR, the use of the cheat code is exacerbated.
T+R+S+S (The Regulator Says So) - This one is a bit rarer, but when a request comes from the regulator, it usually jumps the queue. Sometimes, it’ll jump the queue a long time before the necessary deadline, so it may not go through the normal process. It may come directly from the regulator or the regulator via the internal compliance team.
I said at the top that prioritisation isn’t glamorous, so ending the edition with a reference to being punched in the mouth seems appropriate.
There’s a reason I covered it in this level of detail, though.
It’s an absolutely necessary part of fintech product development and a vital component of a longer-term growth strategy.
There is an abundance of frameworks, though, some of which I’ve detailed but many, many more besides.
Picking the right one depends on the stage your fintech is at, expertise across the team, and clarity over the mission and objectives.
No matter which one you pick, get ready for some cheat codes to be activated and maintain an iron chin. 🥊
Favourite bits of news
GoHenry launches a petition to make financial education mandatory- The petition itself is here, and this is very much in the mould of Wise’s ‘Scrap hidden bank fees’ campaign tied into their own product. It’s just a PR move, it’s genuinely a move to tilt the needle in grassroots financial education to “equip younger generations with financial knowledge and a financial skillset in order to make better-informed decisions as adults”. Sign the petition, as it’s a no-brainer.
Uncapped, Iwoca and Sonovate all secure huge debt facilities - Uncapped secured a £200m debt facility from Fortress Investment Group LL to support businesses. Iwoca secured a £200m debt facility from a new debt facility provided by Barclays and Värde Partners to do the same. And Lloyds committed £100m of funding capacity to the cashflow provider to the UK’s contingent workers, Sonovate. What does this all mean? This trifecta of SME and gig worker funding looks like a big signal to me that banks predict financial issues on the horizon and are backing these digital finance providers to perform the risk decision-making and disbursement. The backing is great but what it signals is not so great.