GateShark
Product Management
GateShark is an access control and visitor management platform for Nigerian estates and office buildings with centralised entry points. It connects four user types — Estate Admin, Gate Person, Resident, and Super Admin — into one system that manages visitor access, tracks gate activity in real time, and creates a permanent, auditable record of every entry and exit. The product was built around a security promise: every visitor access code is generated exclusively by the resident who invited them, no history can be deleted, and every denial requires a logged reason. When something goes wrong inside an estate, the answer to "who let this person in?" is always traceable. I joined Tokden Labs as the first and only PM managing GateShark alongside two other products simultaneously.
GateShark is an access control and visitor management platform for Nigerian estates and office buildings with centralised entry points. It connects four user types — Estate Admin, Gate Person, Resident, and Super Admin — into one system that manages visitor access, tracks gate activity in real time, and creates a permanent, auditable record of every entry and exit. The product was built around a security promise: every visitor access code is generated exclusively by the resident who invited them, no history can be deleted, and every denial requires a logged reason. When something goes wrong inside an estate, the answer to "who let this person in?" is always traceable. I joined Tokden Labs as the first and only PM managing GateShark alongside two other products simultaneously.
Client:
Tokden Labs
Role:
Product Manager
Year:
2026
Explore the full story –
Challenge
GateShark had an MVP that had never shipped. There was no PRD, no documented user flows, no documented rationale for any product decision made to date, and the existing designs were from a previous iteration under a different product name that no longer reflected current thinking. The founding team knew the product needed to exist. They did not have a shared, documented understanding of what it needed to do, who it was primarily for, how it would make money, or why the previous version never launched. Before anything could be built or relaunched, the product needed to be defined from the ground up.
GateShark had an MVP that had never shipped. There was no PRD, no documented user flows, no documented rationale for any product decision made to date, and the existing designs were from a previous iteration under a different product name that no longer reflected current thinking. The founding team knew the product needed to exist. They did not have a shared, documented understanding of what it needed to do, who it was primarily for, how it would make money, or why the previous version never launched. Before anything could be built or relaunched, the product needed to be defined from the ground up.
My Approach
1. Defining the product and its users: My first task was understanding what GateShark actually needed to be; not what the old designs showed, but what the product required to work in the real world. Through conversations with the founding team, I established that GateShark was built for estates and office buildings with a centralised entry point. This was not an app for dispersed residential units. The physical infrastructure — a gate, a barrier, a security post — was a prerequisite. I mapped four distinct user roles and their relationships: the Estate Admin who manages and pays, the Gate Person who operates the entry point, the Resident who generates visitor access, and the Super Admin who oversees the platform —understanding how these four roles interacted was the foundation everything else was built on. The most important insight I reached was this: the product's value to a resident is not knowing who is coming — they already know that; they invited their visitor. The value is knowing the moment their visitor arrives at the gate, and knowing immediately if something goes wrong. This reframe changed the product's positioning from a security screening tool to a real-time visibility and accountability system. 2. Writing the first PRD: I wrote GateShark's first structured product specification from scratch, covering four complete user flows, the visitor invite system, dual-verification (QR code and verbal code as a fallback for no network or dead battery), billing architecture, messaging, notifications, and the security audit rules. The security rules were not in any existing document. I defined them from first principles: • Visitor codes can only be generated by residents, no exceptions • No user can delete visitor history or access logs, including Estate Admins • Gate Persons must log a reason for every denied entry • Suspended resident codes pause automatically; the Gate Person's app flags the code and blocks entry • Removed resident codes are permanently invalidated These rules were the product's accountability promise made concrete. Without them, the core value proposition of GateShark would not hold. 3. Catching critical product gaps: Reviewing the PRD against the existing designs revealed several gaps that would have caused significant problems in engineering or post-launch. The most serious was the suspended resident visitor flow. No one had thought through what happens when a visitor arrives with a valid code, but the resident who generated it has since been suspended. Under the original design, the code would have appeared valid and the visitor would have been admitted, directly undermining the security model. I defined the correct behaviour, wrote the notification logic, and added it to the specification before any screens were designed. I also defined the Gate Person onboarding flow, OTP-based phone verification designed specifically for a user who may not be highly literate but can reliably receive and enter an SMS code. This flow did not exist anywhere in the previous designs. I resolved the resident onboarding ambiguity by recommending invite-only account creation: Estate Admin sends an invite link, resident creates their own account. This simplified the admin's form, produced more accurate data, and created a smoother first experience. 4. Resolving the billing model: The billing model changed three times before landing correctly, from three pricing tiers with identical feature sets, to a per-resident individual payment model, to a final per-house tiered subscription paid exclusively by the Estate Admin. I caught the identical tier problem before any billing screens were designed. I pushed back on the per-resident model with a specific concern: residents did not choose this product and charging them for something imposed on them creates adoption resistance. Nigerian estates already collect shared charges from residents for services like waste disposal and security. GateShark could work the same way. The final model resolved this cleanly: Estate Admin pays per house, residents and gate staff have no interaction with billing at any stage. Pricing scales with estate size so larger estates receive a better rate. 5. Building visibility into design progress: Before I set up a tracking system, the only way to know what the designer was working on was to ask him directly in chat. There was no visibility into progress and no systematic way to know when something was ready for review. I built a 35-card GitHub Projects design tracker across four milestones with five status columns. The rule was simple: the designer moves cards when he starts and finishes work. When something lands in review, I check it against the PRD. Approved work moves to done, and its status is visible to everyone at any time.
1. Defining the product and its users: My first task was understanding what GateShark actually needed to be; not what the old designs showed, but what the product required to work in the real world. Through conversations with the founding team, I established that GateShark was built for estates and office buildings with a centralised entry point. This was not an app for dispersed residential units. The physical infrastructure — a gate, a barrier, a security post — was a prerequisite. I mapped four distinct user roles and their relationships: the Estate Admin who manages and pays, the Gate Person who operates the entry point, the Resident who generates visitor access, and the Super Admin who oversees the platform —understanding how these four roles interacted was the foundation everything else was built on. The most important insight I reached was this: the product's value to a resident is not knowing who is coming — they already know that; they invited their visitor. The value is knowing the moment their visitor arrives at the gate, and knowing immediately if something goes wrong. This reframe changed the product's positioning from a security screening tool to a real-time visibility and accountability system. 2. Writing the first PRD: I wrote GateShark's first structured product specification from scratch, covering four complete user flows, the visitor invite system, dual-verification (QR code and verbal code as a fallback for no network or dead battery), billing architecture, messaging, notifications, and the security audit rules. The security rules were not in any existing document. I defined them from first principles: • Visitor codes can only be generated by residents, no exceptions • No user can delete visitor history or access logs, including Estate Admins • Gate Persons must log a reason for every denied entry • Suspended resident codes pause automatically; the Gate Person's app flags the code and blocks entry • Removed resident codes are permanently invalidated These rules were the product's accountability promise made concrete. Without them, the core value proposition of GateShark would not hold. 3. Catching critical product gaps: Reviewing the PRD against the existing designs revealed several gaps that would have caused significant problems in engineering or post-launch. The most serious was the suspended resident visitor flow. No one had thought through what happens when a visitor arrives with a valid code, but the resident who generated it has since been suspended. Under the original design, the code would have appeared valid and the visitor would have been admitted, directly undermining the security model. I defined the correct behaviour, wrote the notification logic, and added it to the specification before any screens were designed. I also defined the Gate Person onboarding flow, OTP-based phone verification designed specifically for a user who may not be highly literate but can reliably receive and enter an SMS code. This flow did not exist anywhere in the previous designs. I resolved the resident onboarding ambiguity by recommending invite-only account creation: Estate Admin sends an invite link, resident creates their own account. This simplified the admin's form, produced more accurate data, and created a smoother first experience. 4. Resolving the billing model: The billing model changed three times before landing correctly, from three pricing tiers with identical feature sets, to a per-resident individual payment model, to a final per-house tiered subscription paid exclusively by the Estate Admin. I caught the identical tier problem before any billing screens were designed. I pushed back on the per-resident model with a specific concern: residents did not choose this product and charging them for something imposed on them creates adoption resistance. Nigerian estates already collect shared charges from residents for services like waste disposal and security. GateShark could work the same way. The final model resolved this cleanly: Estate Admin pays per house, residents and gate staff have no interaction with billing at any stage. Pricing scales with estate size so larger estates receive a better rate. 5. Building visibility into design progress: Before I set up a tracking system, the only way to know what the designer was working on was to ask him directly in chat. There was no visibility into progress and no systematic way to know when something was ready for review. I built a 35-card GitHub Projects design tracker across four milestones with five status columns. The rule was simple: the designer moves cards when he starts and finishes work. When something lands in review, I check it against the PRD. Approved work moves to done, and its status is visible to everyone at any time.
Results
• GateShark had a complete, locked PRD for the first time in the product's existence, covering four user flows, billing, messaging, notifications, and security audit rules • The billing model was resolved after three iterations, fully documented, and aligned across the founding team • The designer was actively building from a clear brief with a GitHub Projects tracker providing full team visibility across 35 screens and four milestones • Development had begun on the Estate Admin flow • The landing page was designed, copy-approved, and ready for development • Critical product gaps were caught and resolved before reaching engineering • GateShark had a clear, defined path to launch for the first time
• GateShark had a complete, locked PRD for the first time in the product's existence, covering four user flows, billing, messaging, notifications, and security audit rules • The billing model was resolved after three iterations, fully documented, and aligned across the founding team • The designer was actively building from a clear brief with a GitHub Projects tracker providing full team visibility across 35 screens and four milestones • Development had begun on the Estate Admin flow • The landing page was designed, copy-approved, and ready for development • Critical product gaps were caught and resolved before reaching engineering • GateShark had a clear, defined path to launch for the first time
