Fintech R&R ☕️ - The Product Tooling Stack and the Importance of Luck
Challenges faced by product people, tools that help, the PDLC, and the 4 different types of luck
What challenges do product people face in their day-to-day?
What do product folks and top chefs have in common?
What tools are commonly used by product teams?
Why is a tooling stack beneficial to all product builds, particularly fintechs?
What are the four types of luck, and why are they relevant to a product build?
These questions and more will be answered in this week's edition of Fintech R&R
Hey Fintechers and Fintech newbies 👋🏽
The flurry of Open Banking activity I spoke about in the last edition, Open Banking Phase 3.0, continued with a few interesting announcements.
UPI, India’s open rails, launched in Paris, allowing Indian tourists to pay for tickets to the Eiffel Tower using existing UPI apps, saving on FX fees and removing friction for tourists. I touched on this in my UPI deep dive when discussions about this initiative were still in their infancy.
Payment processor CLOWD9 announced a strategic partnership with Open Banking technology provider Ozone API to “empower banks and financial institutions to adapt and thrive in the new world of open finance”.
Real-time payments provider Volt announced its partnership with Bumper, powering its ‘Pay Now’ function and enabling over 5,000 car dealerships to accept real-time account-to-account payments. More crossover and partnerships were among the ‘drivers’ (get it 😉) of Pay by Bank growth I outlined as part of this third phase of UK Open Banking.
It wasn’t all positive news, though.
UK Open Banking Payments Kikapay announced it was shutting its doors, presumably due to business and market economics. An element of consolidation is expected over the next few years, but it’s never nice to see a business go under. We’ll likely see a few more absorbed into other organisations or shut their doors completely.
While the Open Banking train mostly charges on home and abroad, and news is rife, I’m not covering it in two consecutive editions, so I apologise upfront if this intro feels like a bait and switch.
Instead, I’m looking at the theme of some questions flying around a few of the WhatsApp groups, Slack channels and other communities I’m part of.
Some of these were directed at me, some were asked in very niche groups, and some were general requests for advice, but as many of these groups follow the Chatham House rule–allowing content to be shared outside the group, as long as identities are not revealed – I’ll anonymise and slightly paraphrase them to see if you can guess the theme:
“I’m trying to incorporate product analytics into the platform but I don’t know whether to use something off the shelf or build it from scratch?”
“How do you structure customer development and the feedback collection process during the initial market discovery stage?”
“What’s the best way to map out the initial customer journey?”
“How do I structure a roadmap for a board vs for the internal team?”
There’s a bit of process understanding required to give coherent responses to these questions, some domain expertise, as well as broader experience of having done these things before.
But a generic question that I get time and time again, and the key to giving a complete answer to each of the above is, “Jas, what tool is best for <XYZ>?”.
Tooling is such an underrated topic and not one to be taken lightly, which is why this edition is all about the Product Tooling Stack and the valuable tools that solve key problems for product people.
A few of my recent editions have been heavy on the Fintech and a bit lighter on the Product function, so this, along with a couple more dedicated Product editions, will hopefully redress that balance.
As well as interesting news, puns + movie references, this edition includes the following:
Broader problems for Product People
Phases of the Product Development Lifecycle
Discovery
Design
Build
Launch
Growth
JTBD for Product in each and tools that help solve those problems for Product
Different types of Luck including the familiar Blind Luck
In a small tribute to the late great Carl Weathers who passed away last week, I’m kicking this week’s edition off with a “Ding, Ding”.
NOTE: This is another slightly longer edition so to ensure you don’t see the clipped version that, hit this link to read the web version or hit the ‘View entire message’ at the bottom of the mail.
The Broader Challenges for Product people
Let's get something out of the way first.
Building a product isn’t easy.
The people who, in broad strokes, say, “It would be so easy for someone to build an Apple-style app that does XYZ”, or “Why can't Monzo just add this simple feature that would benefit XYZ?”, have not had the experience of building a product from the ground up OR haven’t been part of the ecosystem for long enough to absorb those learnings from others.
Successfully building any product, especially a fintech product, is challenging because there are a multitude of factors that contribute to its success, including:
👉🏽 People - Bringing in the right people at the right time and retaining the great ones.
👉🏽 Regulation - The build constraints that have to be factored in and ensure ongoing adherence to reduce fines/closure/reputational damage.
👉🏽 Technology - Building using a technology that is on a positive trajectory and hoping the trend remains to reduce constant technology upgrades and refactoring.
👉🏽 Funding - Getting enough initial funding to get the product off the ground, then further funding rounds to grow and scale.
👉🏽 Exposure - Pitching the product to the right audience and getting the right exposure through marketing and PR.
👉🏽 Timing - Launching something that isn’t too early in terms of customer trends. I use the Vine vs Instagram example and, more recently, the Google Glass vs AppleVisionPro trend we see now. Or too late and launches just after the peak of the hype cycle.
👉🏽 Luck - An immeasurable factor but one that often means some of the previous points land at the same time, like finding a co-founder because they’ve just been made redundant or getting a feature in Forbes because someone else dropped out at the last minute. More on the different types of luck later…
👉🏽 Product-Customer/Product Market Fit - Building a product that solves problems for customers and resonates with a large enough proportion of a defined demographic.
Good product folks contribute to each of these areas to varying degrees (yes, even luck, and you’ll see why later).
Understanding the tech, creating a roadmap that feeds into a fundraising deck, distilling the baseline regulatory constraints, talking the product plans through with marketing so they can develop synergetic campaigns and much more.
Much of this valued product work is underpinned by foundational discovery that attempts to gather as much insight into the following questions when digging into a product idea or initial hypothesis:
What is the depth and breadth of the market we’re looking to operate in?
What are the big problems in this space?
Why do they exist?
Who are the closest competitors in the space, and how do they solve the problem (if at all)?
Who is the ideal customer for the product, and how will the proposed idea solve problems for them?
When it comes to understanding and distilling the discovered customer problems into actionable ‘Jobs’ that can be serviced by specific products and features rather than just listing problems, I often use the Jobs-to-be-Done framework.
There’s a description of the framework in the SME Jobs-to-be-done edition, but the TL;DR is that observing customers, doing research, understanding their motivations and identifying the ‘jobs’ they need help getting done rather than listing problems leads to products that better serve those needs. It’s also a more customer-centric approach that reduces the likelihood of creating a feature factory that churns out features that don’t resonate with customers.
A common JTBD example I use is one that Personal Finance Management apps try to solve, which is the problem statement, ‘Men and Women between the age of 25-40 don’t know how or where to invest spare cash’. The job statement is then ‘Educate millennials in the ways to make the most of surplus funds’.
Why this mini-rant on the challenge of building a product and JTBD?
As I said, product folks have a broad range of responsibilities. And when I say ‘product folks’, I’m also including the early-stage founders, entrepreneurs, solopreneurs, and CEOs with product ownership, not just people with ‘Product’ in their title.
They have a crucial role in performing discovery, designing a product, working with engineers to build it, taking it to market, growing it and eventually scaling it.
During all these phases, there are challenges.
Product does a great job of looking into customers' problems, understanding the reasons for challenges, creating Jobs statements to define these problems better and then working to create an appropriate solution, but rarely is this same level of depth and process used introspectively.
This means the problems product people face are often overlooked and unclear, sometimes to themselves and often to others.
So I’m diving into SOME of these problems and, rather than just listing them out, reframing them as ‘jobs’ that product people are trying to get done, as well as listing out some of the tools that solve them. You have to practice what you preach, right?
But before diving into those challenges, jobs and tools, a quick note on why it’s sometimes difficult to practice what you preach and look introspectively using…you guessed it…a fun analogy.
Another shoutout for JTBD and why product people and top chefs have similar challenges
I’m a huge film buff and have a passion for travel (I’ve scaled Mt Fuji, backpacked through India, trekked in Nepal, and solo travelled around the states). I’m also a foodie. I like exploring new restaurants, trying new and interesting cuisines, and sometimes a bit of fine dining.
Sometimes, this enthusiasm involves watching restaurant exploration videos and interviews on YouTube where chefs talk about their favourite restaurants, their hobbies and what they eat when they finish their shift.
I was in one of these YouTube dealthloops recently and noticed a very strange trend.
Many chefs and sous chefs making elegant, amazing meals for their customers were eating far from elegant food after their shifts.
The same people constructing and often deconstructing classic recipes and giving unbelievable experiences to customers were going home to sausage sandwiches, McDonalds, packet ramen, and fish fingers (fish sticks for the Americans here).
Why?
This article in the FT about why top chefs eat so badly summarises the reasons really well and uses research and insights from academic Robin Burrow.
Burrow talks about the brigade system, which “brought military-inspired thinking into the kitchen” and led to a hyper-masculine culture “in which chefs, like soldiers, must willingly suffer whatever is required to get the job done”. This means eating good food themselves is not a priority.
He also outlines the economic challenges, stating, “the low profit margins in elite restaurants suppress wages and force workers to make a virtue out of the ceaseless, long hours. A status of heroic martyrdom can stand in for an adequate hourly pay.”
But the overarching reason that chefs eat so badly, the article concludes, is time, specifically the lack of time. The previous two points just highlight why chefs' time is being squeezed, making it difficult for them to eat the same high-quality food they make for their customers.
This is where the Product -> Chef comparison becomes clear.
Time is an excuse that many people building a product can use. It’s why technical debt exists because there wasn’t enough time to make everything perfect the first time.😉
When it comes to product folks applying the same level of thoroughness, structure and strategic thinking to analyse their own day-to-day challenges as they apply to their target customer, market or the product they are managing, the time just isn’t there, so their own problems are neglected.
So, I’m going to help analyse some of these challenges, highlight tools that can help, and cover a bit about the value of product at each stage of the Product Development Lifecycle.
JTBD for Product People
Most organisations building a product go through a similar product development lifecycle, starting with ideation and discovery, designing and building, and moving on to growth and scale.
Bigger organisations like banks tend to use a more rigid waterfall, iterative waterfall or some other hybrid of the framework because of the importance of having nailed down requirements, the impact change can have on a large customer base, and most importantly, the interconnectedness and downstream impact of many of their systems.
It is why many choose to build new products adjacent to, rather than on top of, their existing bank tech stack.
More greenfield products tend to follow a form of iterative, agile, or lean process (these are all different types of development methodologies, not just buzzwords I’m throwing out).
Regardless of the methodology used or even the stage in product development that you’re at, the core product responsibilities in these different phases–whether it’s baseline discovery for a completely new product or feature discovery that will enhance an already live one–remain largely the same so it’s these distinct phases through which I’ll map out problems faced by Product.
Discovery 🔎
Many, including myself, separate Ideation from the Discovery phase, but for simplicity, I’ve merged them here. I often say that ideation is dipping your toe in the water of an idea or hypothesis, and discovery is diving head first into the water and getting a full view of what’s below the surface regarding the problem space and potential customers.
Whether it’s the very early stage of a product involving the founder(s) diving head first into the market, customer, and competitors to understand better what to build, or an existing product where discovery means looking at a new market, expanding their target customer demographic, understanding the stickiness of a potential feature or any other evolution of the existing offering, the responsibilities and objectives at either end are largely the same.
Here, Product will:
Understand the depth and breadth of the problem space. How far and deep the problem/problem space goes
Map out the big problems in this space and who is the most affected by these problems
Figure out why solutions currently looking to solve these problems (if they exist) are inadequate. Or, why such innovations don’t exist yet
Establish who will benefit the most from an impactful solution in this space, or conversely, who is currently most negatively affected by this problem space
Create a vision and strategy for the product that addresses problems, gives value to customers and is part of a sustainable business plan
Which involves:
Performing deep research on customers, the market, and competitors
Mapping out the ideal customer properties
Analysing and distilling research to find key problems that either resonate with the existing hypothesis or give a new perspective on a solution
Mapping out problems
Creating a vision and strategy for the product
JTBD + Tools
There are many challenges here, largely because this is a vital phase of product development or feature/market/customer discovery. It’s the foundation of much of the subsequent work, and there is, therefore, pressure to ‘get it right’.
Designs are based on the customer research and feedback received. The roadmap is built off the back of the problems and opportunities identified. Many pitch and investment decks are driven by the insights gained from research. Discovery informs how the MVP will be structured.
Speaking to many product folks and using my own historical learnings, executing discovery here are the key jobs for product folks and tools that help with these jobs.
JOB STATEMENT: Use tried and tested methods when finding participants for and performing research to remove any inherent bias from the process so that the research sprint is run efficiently
Bias during interviews is one big challenge, but it’s not the only one. Sourcing people to interview, segmenting interviewees, using methods that customers are familiar with, and capturing information that adheres to data capture regulations are some of the others.
Typeform - Popular customer-centric method of executing a survey. Used by many organisations and, therefore, a UI that’s familiar to customers
Maze - 360 Feedback capture, analytics and participant sourcing tool with 100s of templates and standardised questions that make it easier to create unbiased surveys and send them to relevant participants
User Interviews - A great platform that helps source relevant and willing candidates for research, saving precious time and effort
JOB STATEMENT: Capture and store research in an efficient manner upfront so that the research can be analysed effectively and easily referenced & accessed during later phases
It's a challenging and underrated job that many product people look for help with. Surveys, face-to-face interviews, email exchanges, and qualitative feedback get captured in a multitude of ways, including on spreadsheets, docs, paper, databases, video files and more. Disparate research is a challenge to access and sort through, making it difficult to glean insights.
PlaybookUX - An all-in-one feedback platform that allows you to recruit, conduct, analyse and centrally store all user feedback to stay on top insights
Grain - Record customer interviews and immediately store converted transcripts and source videos
EnjoyHQ - A tool to centralise and share insights from customer research with the ability to tag, label, and filter research data with external integrations with tools like Notion and Slack
JOB STATEMENT: Unbiasedly analyse research and customer data so that the most pressing problems and affected parties are identified
Sifting through 1000s of survey responses, reading transcripts from 100s of hours of video interviews and trying to make sense of the problem and most impacted demographic whilst removing any preconceived assumptions is one of the hardest parts of the discovery process. The assumptions part especially.
Gong - Uses custom AI to understand your customers better. Identify business risks early on, replicate best practices, and get ahead of emerging market needs.
JOB STATEMENT: Use standardised templates to map out problems and target demographics to better visualise the problem space and potential solutions
A classic way to outline the problem is to start by putting it into a pitch deck or listing some of the problems in a Word doc. In my experience, this is time-consuming, unstructured (as you’re usually starting from a blank doc), and isn’t a scalable way to visualise the core problems the product will solve
Miro - This is my go-to tool for frameworks and many other visualisation exercises. It has a ton of relevant product strategy and research organisation templates, including a great JTBD one.
Mural - Another great collaborative tool with a heap of relevant templates to help structure and visualise the problem space customer demographic, and perform strategy exercises
Design 📐
Discovery starts with a period of analysis and divergent open-minded thinking of the market, potential customers and problem space. Then, there is a convergence and refinement of those problems into clear ‘jobs’ statements and concrete foundations for a solution through problem analysis and strategy work. Design goes through a similar divergence and convergence. Once there’s clarity over the problems to be solved for customers within a clearly defined market, there's an analysis and divergent exploration of different ways to solve these problems and serve customers and convergence towards a clearly defined and designed solution.
Here, Product will:
Define how to solve the problems identified during discovery
Clarify how to sequence a solution and structure it to make the most impact
Explain how to deliver value and help the affected people in the most effective way
Communicate the phasing of product development over time
Help visualise the early product
Which involves:
Creating User Personas to define the initial and future users of the product
Building a set features that will make up the MVP of the digital product
Building a Roadmap for future phases of development of the product
Creating User Journeys/Wireframes designed based on the users of the product
Assisting with mocking up a Design Prototype that shows the core user journeys for the product and brings the idea to life
JTBD + Tools
The challenges here are a lot narrower than during the discovery phase as there’s a clearer problem area, and this is less about the ‘what’ or ‘why’ and more concerned with the ‘how’.
JOB STATEMENT: Create a standard visualisation of the product roadmap & granular features so that the broader team has clarity of what we’re building
This is a common issue for product folks, especially those doing more strategic work like roadmapping. Some use a PowerPoint deck. Some use Miro. Some just publish it on a confluence page. Each has its own drawbacks, but fortunately, there are tools that help.
Roadmunk - A flexible roadmapping tool with multiple templates, groupings, tagging and, crucially, a Jira integration
ProductBoard - A strategic roadmap tool with customizable, audience-tailored templates
Aha! - A template-based roadmapping tool with an array of templates, formatting options and feature scoring options
JOB STATEMENT: Build a set of customer journeys so the design and engineering team can more easily visualise and build the MVP/feature
This is a more niche job for product people served by many generic whiteboard tools but not all tools are created equal.
UXPressia - Comprehensive journey mapping software with a range of curated templates to help provide a complete map of core journeys
Gliffy - Simple but effective tool with standard shapes and templates that help speed up the customer journey mapping process
Miro - A flexible whiteboard tool with journey mapping and templating shapes to build bespoke customer journey templates
Figma - A common tool for design but with the ability for product to create basic journeys, making it a great option for folks wanting to simplify their tool stack, work seamlessly with design and quickly go from journey to design prototype
Build 🏗
In an end-to-end build, this is the stage where there's lots of solid research, feature ideas, a roadmap, some designs, user personas, user journeys, wireframes and, ideally, a design prototype. So, it's time to get engineers to build the thing now, right? Well, not just yet. Although the assumption is engineers can now build the product or the new feature, there's still a bit of product involvement.
Here, Product will:
Specify what to build and how (from a non-technical perspective)
Outline a plan with some dates using the roadmap (this is often done by a delivery/project manager as well)
Clarify any external dependencies
Which involves:
Creating feature specifications and structure
Building out or helping build out a delivery plan with a timeline
Perform some vendor selection where relevant
JTBD + Tools
Although Build doesn't seem as product intensive as Discovery or Design it's arguably where product, especially product specialists who have domain, technical and product experience, are most impactful. Navigating around specific challenges, structuring and defining features with precision to reduce back and forth, and using their experience to respond to any challenges to reduce build disruption.
JOB STATEMENT: Create manageable & well-defined features, user stories and tasks that engineers can pick up based on priority so that progress can be tracked and active work is transparent
This job basically describes Jira. That wasn't the intention but a place to create and store specs that can be picked up by engineering and tracked across the team is what's needed here and describes the core of what Jira does. It's not the only tool in town though…
Jira - The OG of planning, tracking, and release software. Used by companies far and wide, large and small to create and track user stories, track releases, show progress and understand team productivity
Trello - A tool that allows for feature definition and a centralised view of progress with some integrations, but not that commonly used by engineering teams
Notion - A flexible document repository with great task visualisation features, tracking and key integrations with Jira and GitHub
Launch 🚀
Most assume that a new product launch or feature launch is a pure marketing activity. Putting the word out there, using the right tone of voice, figuring out the right blend of out-of-home, digital marketing and the other important items on marketing's launch checklist. There is, however, quite a bit of product involvement.
Here, Product will:
Help build (ideally a while before launch) a community of early-adopters
Check the product for robustness, relevance and minimum viability for early-customer testing
Ensure the right people are targeted as part of launch
Establish the best way of communicating with early adopters
Which involves:
Refining user personas and identifying the high-value early adopters
Performing internal testing
Building in customer feedback mechanisms
JOB STATEMENT: Create a process through which potential customers can learn about the product and be contacted further so that I can build a community of early adopters to utilise for early feedback and customer growth
This is overwhelmingly a website with a sign-up link but it often leads to great community building and is not necessarily limited to WordPress or Webflow (although those are the two I've listed)
Webflow/Wordpress/Squarespace - Very popular and long standard website builders with a number of key integrations to things like Zapier for workflow automation and Typeform for richer data gathering. They also have many templates and a domain-purchasing facility
Carrd - Cheap and simple to use landing page builder
Swipepages - Drag and drop high-quality landing page builder with multiple integrations, A/B testing and built-in analytics
JOB STATEMENT: Build feedback mechanisms into the product for customers to use so that we can learn more about the value of different parts of the product and see where we can refine, improve, and potentially reprioritise
Baking feedback loops into the product from day one is ideal, but finding the right tools to use, establishing the right blend of feedback mechanisms
Medallia - A full-stack feedback management system from obtaining feedback via surveys to managing and understanding the data. A popular choice for many SaaS products.
Intercom + TypeForm/SurveyMonkey + Calendly - A combination I've used before is an in-app support module with an embedded survey, which eventually leads to an option to book a meeting to discuss feedback in more detail. Mainly because these early stages of post-launch feedback are valuable and also go some way to building advocacy with customers.
Canny - An embeddable tool that allows you to display a public roadmap, collect feedback from customers, analyse feedback and allow for new feature suggestions.
Sleekplan - Similar to Canny, with the additional ability to measure CSAT and NPS scores
Grow 📈
Let's first make the distinction clear. Growth and scale are different. Growth is growing customers and usually revenue as well as the business, which is a direct result of the time, resources and money put into those efforts. Growth is fairly linear.
Scale is more exponential and usually involves making processes within the product and the organisation scalable so they can get more customers and generate more revenue without inputting significantly more capital, resources or technology. That's my simplistic separation.
When it comes to scale, yes, there are some specifics around partnerships and product efficiencies, but the important jobs are efficiently growing the customer base, exploring new cost-effective geographies, and using feedback and research to scale cost-effectively. It's almost an interactive process of discovery, customer feedback and execution, which has been covered.
Here, Product will:
Get a better understanding of what parts of the product are working and which are less sticky
Further cement their understanding of customer problems through app usage and feedback
Continue to deliver on the product roadmap
Which involves:
Analysing customer personas and beginning to loosen the initial customer filters/eligibility to a broader audience
Using in-app feedback, in-built metrics and qualitative feedback to inform rather than direct product priorities
Tracking and reporting metrics to the broader team on a regular basis (marketing, Ops and customer success specifically)
JOB STATEMENT: Establish a framework to capture and analyse in-app feedback so that it can be used to inform the future development of the product
Feedback via surveys and face-to-face interviews is great, but it should be coupled with direct usage, click, onboarding, conversion and other product analytics to give a full picture of customers' experience. This should ideally be set up before launch.
Mixpanel - Used by many big brands to track customer journeys, analyse conversion, store and track key products, segment customers and more. This is my go-to product analytics visualisation tool.
Amplitude - Similar in feature richness and big brand usage to Mixpanel
Pendo - Another large product analytics platform with several integrations, similar analytics and a couple more product-related features
Segment - A customer data platform that can centralise all product events (clicks, data entry, field submission, etc.), clean the data, organise and cohort customers, and then push to a visualisation platform. Often used in conjunction with Mixpanel/Amplitude or similar
JOB STATEMENT: Identify mechanisms for semi-organic customer growth so that the product and brand reach a wider audience
It's a bit of a niche one but something that, again, I get asked quite often, e.g. "Do you know of any tools that manage a referral program, or would you recommend building it yourself?". Referrals can be a great, although sometimes expensive, way of sparking some growth momentum for your product, and yes, there are tools out there that help.
MentionMe - Popular tool used by big brands to outsource the segmentation of brand advocates, management of referrals and referral analytics
Viral Loops - Another popular tool that also has a campaign wizard and product analytic integrations
The reasoning behind writing this fairly lengthy edition is three-fold.
👉🏽 To make it clear, building a product isn't easy. The overview I've given, and the jobs I've called out are just a snippet of the process. Yes, it's usually not one product person doing all this work (although in the early stages, it is usually just a founder), but there is a ton of work to get a product built and to market.
👉🏽 List out some useful tools and map out the key problems product people face during the PDLC.
👉🏽 Highlight why many product people don't get time to look for the right tools as they are busy doing initial discovery work, speaking to customers, writing up decks, filling out Jira tickets, in meetings or the other 100 things that need to be done.
There are many tools that help product people reclaim some of that time, and the advent of AI means that many will be able to do creative and strategic work rather than spend hours refining tickets or writing user stories.
This means giving product folks time and space to explore tools, analyse their day-to-day and come up with effective ways to remove some of the manual product overhead so they do more creative work like finding innovative ways to solve customer problems, leverage new technology to build a more scalable platform, identify new markets for the product, and get creative with networking which could uncover more impactful partnerships.
This takes me full circle and to my final point about luck.
What's Luck got to do with it? 🎲
Luck was one of the factors outlined earlier when talking about successful startups.
As I said, there are a few examples where luck has played a part in successful startups.
Often, it’s founders meeting serendipitously, like the Wise founders in 2011.
Or it could be getting your product a feature spot in a TechCrunch article after one of your investors excitedly tweeted about it. That was Monzo's first big piece in the press.
But one thing that may be news to you is that there are four types of luck, as neurologist and philosopher Dr. James Austin outlines in his book The Four Kinds of Luck: How To Make A Habit Of Getting Lucky.
Blind Luck 👓 - Things that are out of your control
This is the one everyone will be familiar with. Also called randomness, dumb luck or fate for the more spiritual among us. Startups are rarely successful due to pure Blind Luck.
Luck from Motion 🏃🏼- Hustling, creating connections and collisions
In the corporate world, this explains the folks who get great jobs because they know the right people (and because they are competent, of course). And they know they know the right people because they've put in the effort consistently for a long period of time.
Luck from Awareness 🧠 - Get good at spotting opportunities because of domain knowledge
The 'luck' of recognising opportunities from the experience built over time and putting yourself in a position to capitalise on them.
In a startup, this could be a founder who was a product expert for ten years, hiring a junior product person who turns out to be a superstar.
This type of luck comes through experience but also willingness to learn by seeking out different opinions and staying on top of your domain.
Luck from Uniqueness 👨🏻🎤- Hobbies, interest and knowledge that others seek out
"[This type] favours those with distinctive, if not eccentric hobbies, personal lifestyles, and motor behaviours," Austin says in his book.
It's that offering the world an unusual combination of skills, experiences, and interests makes you more likely to stand out and attract opportunities.
A fintech newsletter delicately balances fintech & product insights with movie references and puns might, for example, be something that benefits from 'Luck from Uniqueness'. 👀
The point with this spectrum of luck is that you can, in fact, make your own luck. Maybe not Blind Luck, but certainly Luck from Motion and Awareness.
So here's my advice:
👉🏽 If you're an early-stage founder, carefully select your tools based on function and fit, not just convenience. (Remember to pay attention to your tooling stack).
👉🏽 If you're a later-stage founder, look at your stack, the total cost, the time churn and where efficiencies can be gained. Or ask your product person to do it if you have one.
👉🏽 If you're a product person, try to review your day-to-day and figure out if there are tools that can help with some of the regular challenges.
👉🏽 If you manage a product team, do the same. Give your product folks the time and space to improve their way of working so they can ultimately spend the same time and attention on their problems as they do with the product's target customers.
If all goes well, you should have some more time on your hands, which I'd spend keeping up to date with domain trends and fintech news, making new connections, proposing new ideas to management, and doing more partnerships work.
In the short term, it might lead to some luck, which can benefit your product.
In the long term, it could lead to some opportunities you might never have had…🤞🏽
Either way, this makes some of the key challenges for product people clear and also shines a light on some great tools that help with those challenges
Remember, if you enjoyed this edition, drop a like below, fire over your questions and share with a friend! Back again in two weeks!
And if you want a bit of help to find the most appropriate tools for your product stack then drop me a message. 👋🏽
Interesting News
RBI vs Paytm continues - After numerous warnings from the Royal Bank of India, shares of one of India's most popular digital payment apps Paytm continue to slump after their banking unit was forced to halt business. A source told Reuters this was due to an investigation where India's central bank found hundreds of thousands of accounts at Paytm Payments Bank, one of India's most popular digital payment apps, that were created without proper identification. This would definitely be bigger news in the UK or US if, for example, an investigation into Revolut wiped $2.5 billion off their valuation.
CLOWD9 & Ozone API: A partnership made near heaven - A quick word on the payment processor x Open Banking API provider not just because I think it’s a great grammatically synergetic partnership. Cloud + Ozone! I think this is one of many more processor x Open API partnerships as more organisations get requests from fintech startups to provide ‘full-stack’ banking technology that includes an Open Banking API provider. Like I said a couple of weeks ago, an interesting and exciting age for Open Banking.
a tough compass & a powerful arsenal for product folks:)