Role: Product Manager
Duration: 2024
Product: Phoenix (Form Builder & Data Collection), Flowmono Automate (Business Process Automation)
Team Scope: Engineering, QA, Product Design, Sales, DevOps/Infrastructure, Finance/CFO
Flowmono is a Nigerian product-led startup helping individuals and organisations digitise workflows, automate approvals, collect structured data, and sign documents electronically. I joined to drive feature expansion and strengthen product-market fit across two core products: Phoenix, a drag-and-drop form builder and data collection platform, and Flowmono Automate, a no-code business process automation tool.
When I joined, the products existed in early form. My job was to take them from early-stage tools to enterprise-ready platforms — and to find, validate, and serve the customers who would actually use them.
Organisations were stuck with paper-based and manual workflows — approvals that required physical sign-off, vendor onboarding that lived in spreadsheets, account opening forms that required physical visits, and data collection processes that had no structure, no audit trail, and no way to connect to downstream workflows. They needed tools that could handle the complexity of their processes without requiring engineering resources to configure or maintain.
At the same time, many organisations hesitated to adopt new tools because they could not easily replicate their existing processes in generic software. The product needed to be flexible enough for a bank's account opening flow, a hospital's intake form, and an HR team's job application process — without being so configurable that it became unusable.
Discovery began before a single line of code was committed. I ran customer interviews and demoed design prototypes to potential users to validate assumptions before locking any development timeline. This was deliberate — it was cheaper to change a Figma prototype than to rebuild a shipped feature.
Sterling Bank became our earliest enterprise adopter, and the discovery process with them shaped the entire product. I worked closely and constantly with their key teams — the people who would actually use the tool — and with their CTO. Those conversations were not just requirements-gathering. They were ongoing, iterative, and sometimes uncomfortable.
In one critical meeting, we presented progress on a feature we had designed and partially built. The Sterling Bank team told us directly: this is not what we asked for. What we had built reflected my assumption of their need, not their actual need. The team went back to the drawing board. That rework cost us time — but it saved us from shipping something that would have failed in the field. It also permanently changed how I ran discovery. After that, I never assumed I understood a requirement until I had shown the user something tangible and heard them describe it back to me in their own words.
I also joined sales demo calls regularly alongside the sales team — pitching the current product and the roadmap to prospective clients, watching how they responded, what they asked for, and where their eyes lit up or went flat. This was where the template library idea came from. Multiple organisations said the same thing in different ways: we do not want to start from scratch every time. A template library was not on the original roadmap. It went to the top of it.