Product Management
The craft is everywhere. Doing it inside a regulated financial environment is not.
Most of my work has been with startups and scaling teams — founders who had an idea and no product function yet, and teams with a product already live who had outgrown having no-one whose job it is to specifically decide what comes next.
Most engagements start with something already on the table: a partner to choose, a market to enter, a roadmap nobody can rank. The constraints are real and the resources are finite, so they hire someone who has made that call before.
01.
User Research
- User Interviews
- Focus Groups
- Personas
- User Journey Mapping
- Usability Testing
- Surveying (In-Product & Campaigns)
- Design Optimization & Requirements Gathering
Research has a recruitment problem before it has a methodology problem. People are guarded and the users you most need to hear from are the ones you can no longer reach (i.e., the application that was declined, the onboarding abandoned at document upload, the account closed after a limit nobody explained).
So I weight behaviour over stated preference wherever possible. What someone does while they wait, the workaround they’ve built, what they’re already paying somebody else to solve. A customer paying a fee to a competitor tells you more than any survey response will.
My method also follows the decision (or lack of) rather than the other way round. When a team hasn’t yet agreed on what the problem actually is, I start with interviews and journey mapping as both tend to surface the disagreement. When the flow already exists and people are abandoning it, usability testing will show you where and why. Surveys handle the questions that need volume behind them, run in-product where the question is narrow and as a campaign where the people worth hearing from have already gone, with the collection and analysis automated wherever the sample is large enough to justify it. Focus groups earn their place when the language matters as much as the finding, since hearing people respond to each other tells you how they’d describe a product to somebody else. Personas do their best work once a team is making a lot of small decisions quickly and needs a shared reference to make them against.
You get research that separate what users said from what they did, findings ranked by how often they appear and what they’d cost to fix, and requirements traceable back to the evidence that produced them.
02.
Product Development
- Feature Ideation
- User Stories
- Scope Management
- Acceptance Criteria & Success Metrics
- Product Roadmapping/Sprint Planning
- API Integration & Vendor Management (Add-On)
In a regulated product, scope is mostly negotiated with people who don’t sit on the product team. Risk has a view on who’s eligible, compliance has a view on what you can collect and what you have to keep, and a sponsor bank, core provider or data vendor has a roadmap of its own that yours now depends on. A feature can be fully specified, agreed and estimated, and still not ship this quarter because somebody else’s environment isn’t ready.
So I plan against those constraints rather than around them. I run feature ideation wide and early, before anyone has become attached to a particular build. I write user stories and acceptance criteria before delivery starts, because in financial products “works correctly” has to account for the reversal, the declined application, the transfer that fails halfway through, the account placed on hold and the duplicates. I provide success metrics while there is still room to disagree about them. Scope management then runs against that definition rather than against a wish list.
You get a roadmap sequenced against the dependencies that actually govern it, scope that has already survived the compliance conversation, acceptance criteria written down before they become an argument, and success metrics everyone agreed to while the product was still an idea.
03.
Wireframing & Prototyping
- Low to High Fidelity Wireframes
- No-code/Low-code Prototype Development
Prototyping is faster than it has ever been and a team with the current tools can put a clickable flow in front of someone inside a week. The harder question is which flow to build, and in financial products the screens that decide whether something works are usually the ones that never make it into a prototype: verification still pending on day four, an application under review with no indication of how long it will take, a transfer held for a reason the customer can’t act on, or a balance showing money that isn’t spendable yet.
So I prototype the waiting and the failure states alongside the success case. Those are the states where people abandon, and they are the ones support absorbs afterwards, which makes them worth testing before anybody builds them.
I start at low fidelity when the open question is about sequence (i.e., what comes first, what can be deferred, how much someone is being asked to do in one sitting) because that keeps the discussion on the flow rather than on the visual design. I move to high fidelity when the question is about comprehension, which carries more weight in financial products than in most, since a screen telling someone their money is on hold has to be understood correctly the first time. I build no-code and low-code prototypes when something needs to be clickable in front of a real person, particularly when the people worth testing with sit outside the building and engineering time is the scarcest thing you have.
You get something testable early enough that changing it is still cheap, covering the states that actually decide whether people finish.
04.
Product Positioning
- Competitive Analysis
- Value Proposition Refinement
Most competitive analysis produces a feature grid, and a feature grid mostly tells you what to copy. The more useful reading sits in what competitors will not do: the customers they decline, the limits they place on new accounts, the markets they have stayed out of, the fee they charge for something a rival gives away.
A lower limit for new customers tells you how that company prices uncertainty. A charge for instant access tells you they have worked out their funding cost and decided to pass it on. A market they have avoided usually means the licensing or the fraud picture did not justify the entry. Each of those is a decision somebody had to defend internally, and most of them get read as marketing rather than as the risk positions they are.
That work feeds straight into the value proposition, since the sharpest version of what you offer is often the thing a competitor has ruled out on risk or on economics. I then test that proposition against your own constraints, because a position you cannot fund, staff or get past compliance is not a position you hold. Where the evidence runs out I say so, and name what we would need to learn before being confident in it.
You get a competitive picture built on what competitors charge, restrict and decline, a value proposition that survives your constraints as well as theirs, and a clear line between the parts of the case resting on evidence and the parts still resting on assumption.