TAD Finance

Product Management

I joined Tokden Labs as the first and only PM on a product that had no defined direction, no PRD, no user research, and two founders who disagreed about what to build. Four months later, TAD Finance had a fully designed app, a beta-tested product, a structured go-to-market plan, and a website live in production.

I joined Tokden Labs as the first and only PM on a product that had no defined direction, no PRD, no user research, and two founders who disagreed about what to build. Four months later, TAD Finance had a fully designed app, a beta-tested product, a structured go-to-market plan, and a website live in production.

Client:

Tokden Labs

Role:

Product Management

Year:

2026

  • Explore the full story –

Challenge

Before I could manage the product, I had to define it. The first question I brought to the team — "What does a small business owner do differently six months after using TAD Finance?" — broke a weeks-long deadlock. It forced a conversation about outcomes rather than features, and surfaced an underlying need: Nigerian small business owners didn't know if their businesses were actually profitable. They were selling without knowing their numbers. TAD Finance would be a financial management app for Nigerian small business resellers — helping them price their products correctly, track their sales, and always know how their business was performing.

Before I could manage the product, I had to define it. The first question I brought to the team — "What does a small business owner do differently six months after using TAD Finance?" — broke a weeks-long deadlock. It forced a conversation about outcomes rather than features, and surfaced an underlying need: Nigerian small business owners didn't know if their businesses were actually profitable. They were selling without knowing their numbers. TAD Finance would be a financial management app for Nigerian small business resellers — helping them price their products correctly, track their sales, and always know how their business was performing.

My Approach

Step 1 — User Research Before Anything Else Before writing a single requirement, I wanted to hear from real users. I had a network of small business owners from my time running a fragrance brand, vendors selling on Instagram and WhatsApp - exactly the people we were building for. I conducted three interviews with four small-business owners across the perfume, skincare, baking, and gifting sectors. My goal wasn't to validate a feature, but to try to understand the actual texture of the problem. What I heard from all four confirmed that none of them lacked awareness that tracking mattered. The barrier was friction — tools that required manual input without giving anything useful in return. This finding shaped two critical product decisions: positioning TAD Finance as a tool that thinks after you enter the number (not a ledger), and leading with the Pricing Calculator rather than a general bookkeeping tool. One interview produced what became the product's clearest proof of value: Blessing, a perfume vendor, restocked double her usual quantity of a product after it sold out fast — only to discover the initial demand had been driven by an influencer trend that had already passed. She had no visibility into the slowdown until it was too late. If she had been using the Sales Book, she would have seen her sell-through rate dropping before she placed the order. That story became the Sales Book's positioning on the website. Step 2 — Defining The Product With user research in hand, I wrote the first PRD. The product had two core features that connected into one user journey: 1. The Pricing Calculator — enter your costs, expenses, and profit target. Get a recommended selling price and projected profit, per product, instantly. Price up to 15 products in one session. Factor in shared batch expenses proportionally. 2. The Sales Book — every saved pricing estimate becomes a batch. Record sales against it. Track your real profit performance in real time. Get guided suggestions when you're falling behind your target. The connection between them was the product's core idea: Plan → Execute → Adjust. Price right. Track everything. Know your numbers. The PRD went through three major versions over eight weeks, each one resolving something that had been left ambiguous. Step 3 — Designing The Process TAD Finance had a designer, a frontend engineer, and a backend engineer. With three people building and one person designing, the biggest risk was the classic startup failure mode: things agreed verbally in a meeting that get quietly forgotten between the meeting and the build. I introduced two systems to prevent this: • 24-hour design review windows. Before any design was handed to engineering, the team had 24 hours to review and flag changes. After that window, the design was locked. This prevented the pattern of "just one more change" that delays builds indefinitely. • A QA and UAT testing template. I built a 60+ test case document covering seven feature areas across mobile and desktop, with a bug severity framework and a structured feedback guide for external testers. Before this, testing was informal and verbal. After, it was a checklist. Step 4 — Catching What Others Missed The work I'm most proud of in this engagement is the gaps I caught before they became expensive problems. Some examples: • The dashboard that didn't exist. Three weeks into the engagement, during a design review meeting, I realized nobody had discussed what the dashboard should show. There were no designs for it, no brief, and no one had flagged the omission. I wrote the dashboard brief from scratch, defining the primary metric (cumulative profit performance), the secondary metrics, the time filter options, and the empty state for new users. • The expenses field UX problem. During beta testing, two independent users tried to type the name of an expense — "packaging" — into a field that expected a number. The placeholder text said "e.g. packaging, labels", which implied text input. I diagnosed the confusion, proposed a fix (relabelling the field as "Additional Expenses (Total Cost)" with helper text clarifying "enter the total amount, not per unit"), and confirmed with the dev team that it required no backend change. • The email verification delay. A beta tester reported that it took 24 hours to verify her email after signup. I flagged this as a critical bug immediately — a 24-hour verification delay kills onboarding momentum. It was fixed before formal external testing began. • The Resources checkout bug. A beta tester reported that the checkout cart cleared when she tried to pay for a resource. I surfaced this to the team; it was investigated, and it was resolved before the product went to external users. Step 5 — Pre-Launch Strategy By the end of June, the product was approaching launch-ready. I shifted from building to preparing. • Beta testing. I designed a 30-user beta testing framework — selecting testers from the company's waitlist (segmented by business type) and my own network of small business vendors. I discovered that the waitlist, compiled nine months earlier, was largely misaligned with the product's current positioning — many contacts were manufacturers rather than resellers. I pivoted to my personal network, which yielded higher quality feedback from the right user type. • KPI framework. I defined the metrics we'd track at 30, 60, and 90 days post-launch: Number of users who complete signup Number of users who create at least one pricing estimate in their first session Number of users who record at least one sale within their first week Weekly active users at each interval Resources section conversion rate Week-1 to week-4 retention rate • Go-to-market sequencing. I drafted a launch strategy built around three phases: community seeding (WhatsApp groups, Facebook communities, Toke's existing networks), a coordinated launch day with simultaneous posts across all channels, and a content-led growth phase (Instagram-first, education-before-conversion). I also prepared the interview questions for the social media manager hire and attended the interview with Toke. • Website. I authored a full ten-page website content redraft using the StoryBrand framework — homepage, Pricing Calculator, Sales Book, Dashboard, Resources, About, Blog, Glossary, FAQs, and Support. I established brand tone guidelines and SEO structure across the multi-product Tadfinance brand. The website went through design and into production.

Step 1 — User Research Before Anything Else Before writing a single requirement, I wanted to hear from real users. I had a network of small business owners from my time running a fragrance brand, vendors selling on Instagram and WhatsApp - exactly the people we were building for. I conducted three interviews with four small-business owners across the perfume, skincare, baking, and gifting sectors. My goal wasn't to validate a feature, but to try to understand the actual texture of the problem. What I heard from all four confirmed that none of them lacked awareness that tracking mattered. The barrier was friction — tools that required manual input without giving anything useful in return. This finding shaped two critical product decisions: positioning TAD Finance as a tool that thinks after you enter the number (not a ledger), and leading with the Pricing Calculator rather than a general bookkeeping tool. One interview produced what became the product's clearest proof of value: Blessing, a perfume vendor, restocked double her usual quantity of a product after it sold out fast — only to discover the initial demand had been driven by an influencer trend that had already passed. She had no visibility into the slowdown until it was too late. If she had been using the Sales Book, she would have seen her sell-through rate dropping before she placed the order. That story became the Sales Book's positioning on the website. Step 2 — Defining The Product With user research in hand, I wrote the first PRD. The product had two core features that connected into one user journey: 1. The Pricing Calculator — enter your costs, expenses, and profit target. Get a recommended selling price and projected profit, per product, instantly. Price up to 15 products in one session. Factor in shared batch expenses proportionally. 2. The Sales Book — every saved pricing estimate becomes a batch. Record sales against it. Track your real profit performance in real time. Get guided suggestions when you're falling behind your target. The connection between them was the product's core idea: Plan → Execute → Adjust. Price right. Track everything. Know your numbers. The PRD went through three major versions over eight weeks, each one resolving something that had been left ambiguous. Step 3 — Designing The Process TAD Finance had a designer, a frontend engineer, and a backend engineer. With three people building and one person designing, the biggest risk was the classic startup failure mode: things agreed verbally in a meeting that get quietly forgotten between the meeting and the build. I introduced two systems to prevent this: • 24-hour design review windows. Before any design was handed to engineering, the team had 24 hours to review and flag changes. After that window, the design was locked. This prevented the pattern of "just one more change" that delays builds indefinitely. • A QA and UAT testing template. I built a 60+ test case document covering seven feature areas across mobile and desktop, with a bug severity framework and a structured feedback guide for external testers. Before this, testing was informal and verbal. After, it was a checklist. Step 4 — Catching What Others Missed The work I'm most proud of in this engagement is the gaps I caught before they became expensive problems. Some examples: • The dashboard that didn't exist. Three weeks into the engagement, during a design review meeting, I realized nobody had discussed what the dashboard should show. There were no designs for it, no brief, and no one had flagged the omission. I wrote the dashboard brief from scratch, defining the primary metric (cumulative profit performance), the secondary metrics, the time filter options, and the empty state for new users. • The expenses field UX problem. During beta testing, two independent users tried to type the name of an expense — "packaging" — into a field that expected a number. The placeholder text said "e.g. packaging, labels", which implied text input. I diagnosed the confusion, proposed a fix (relabelling the field as "Additional Expenses (Total Cost)" with helper text clarifying "enter the total amount, not per unit"), and confirmed with the dev team that it required no backend change. • The email verification delay. A beta tester reported that it took 24 hours to verify her email after signup. I flagged this as a critical bug immediately — a 24-hour verification delay kills onboarding momentum. It was fixed before formal external testing began. • The Resources checkout bug. A beta tester reported that the checkout cart cleared when she tried to pay for a resource. I surfaced this to the team; it was investigated, and it was resolved before the product went to external users. Step 5 — Pre-Launch Strategy By the end of June, the product was approaching launch-ready. I shifted from building to preparing. • Beta testing. I designed a 30-user beta testing framework — selecting testers from the company's waitlist (segmented by business type) and my own network of small business vendors. I discovered that the waitlist, compiled nine months earlier, was largely misaligned with the product's current positioning — many contacts were manufacturers rather than resellers. I pivoted to my personal network, which yielded higher quality feedback from the right user type. • KPI framework. I defined the metrics we'd track at 30, 60, and 90 days post-launch: Number of users who complete signup Number of users who create at least one pricing estimate in their first session Number of users who record at least one sale within their first week Weekly active users at each interval Resources section conversion rate Week-1 to week-4 retention rate • Go-to-market sequencing. I drafted a launch strategy built around three phases: community seeding (WhatsApp groups, Facebook communities, Toke's existing networks), a coordinated launch day with simultaneous posts across all channels, and a content-led growth phase (Instagram-first, education-before-conversion). I also prepared the interview questions for the social media manager hire and attended the interview with Toke. • Website. I authored a full ten-page website content redraft using the StoryBrand framework — homepage, Pricing Calculator, Sales Book, Dashboard, Resources, About, Blog, Glossary, FAQs, and Support. I established brand tone guidelines and SEO structure across the multi-product Tadfinance brand. The website went through design and into production.

Results

By the end of the engagement: • TAD Finance had a fully designed, development-complete app — Pricing Calculator, Sales Book and Resources — with real beta feedback incorporated. • The website was designed and live in production • A 60+ test case QA template was in use across the team • A structured beta testing process was underway with real small business owners • A go-to-market plan and KPI framework were defined and ready The contract concluded at the end of July 2026. TAD Finance was launch-ready.

By the end of the engagement: • TAD Finance had a fully designed, development-complete app — Pricing Calculator, Sales Book and Resources — with real beta feedback incorporated. • The website was designed and live in production • A 60+ test case QA template was in use across the team • A structured beta testing process was underway with real small business owners • A go-to-market plan and KPI framework were defined and ready The contract concluded at the end of July 2026. TAD Finance was launch-ready.

Create a free website with Framer, the website builder loved by startups, designers and agencies.