Kenechukwu Ohiaeri is a seasoned professional with over seven years of experience in product design and management, grounded in a background in Computer Engineering. He has led product teams and delivered user-focused solutions across a range of sectors, including digital identity, financial technology, healthcare, and big data. Known for creating usable and impactful designs, Ohiaeri combines technical expertise with strategic thinking to drive innovation and build technology that serves real human needs.
In this interview, he reflects on the lessons that shaped his leadership journey, unpacks the complexities of building secure and scalable systems in emerging markets like Nigeria, and shares practical strategies for empowering teams, aligning cross-functional goals, and bridging the gap between design and strategy.

What early experiences or challenges in your career most influenced how you think about building and leading technology products today?
Early in my career, I was part of a small but mission-critical team tasked with rebuilding and migrating users from a legacy codebase for a fintech app within a very short period. The whole team was flown into one apartment, where we slept, ate, designed, wrote code, and shipped for three weeks nonstop. With so much to do and so little time to do it, our team lead at the time understood the product feature our users relied on the most and unified our vision to deliver that and that only.

This crystal-clear vision kept us focused, and we managed to migrate every user from the legacy codebase right on time. That intense, hands-on push taught me two lessons I still lean on today: begin every project with a concise, clear, unambiguous problem statement, and build feedback loops in every sprint so you can course-correct early, before you’ve gone too far down the wrong path. Those principles have become the north star for how I build and lead teams, sharp focus up front, and constant learning as you go.

When leading your team from a consultancy-led to a product-led model, what trade-offs or hard decisions did you face? How did you manage them?
Moving from a consultancy-led model to a product-led model felt more like an evolution than a pivot. We initially started with providing solutions that helped boost the digital infrastructure of MDAs, and over time, we built a reputation as identity management experts. With this came the need to productise our offerings across the board. The opportunity to do this at a large scale came when we were presented with the task of building a mobile identity management solution for Nigerian citizens.

To answer your question, in this context, the hard product trade-offs we faced were choosing standardisation over customisation and dealing with the pressure of building a public-facing product. To solve the first challenge, we decided to create a modular structure, where we built a lightweight digital identity management core with configurable extensions and modules to cater to various nuances, from ID issuance to card services, access management to identity verification. This allowed us to say yes to feature requests without fracturing the codebase or bloating the user experience.

As for the second challenge, design played a huge role in managing this. We spent a lot of time learning from our target users in their environment, understanding the use case of the mobile ID in certain situations, and designing a product that felt natural and simple to use by default. We tore out entire screens, boiled the processes down to very basic button taps, and tested iteratively. We also kept the UI simple enough so it would render crisply on low-end devices.

As someone who has worked across digital identity, fintech, healthcare, and big data, how do you approach designing products that must balance usability with complex technical requirements?
Balancing usability with complex technical requirements and security needs can be a very dicey situation if not managed properly. In my case, usability wasn’t limited to just the end users of the product; I also needed to factor in integration and frontend partners.

A typical example was when we were designing a consent-based ID verification service and had to make sure we developed a very tight ship that involved layers of technology like hardware keys, biometric SDKs, AES encryption-decryption at rest and in transit, time-based verification, and device-to-device communication locks.

These were non-negotiables, so the approach I took was first learning about all these technical requirements, understanding their interaction points, and designing a shared interaction map with the technical team. This map became our single source of truth for where security could live under the hood without leaking into the UI.

We then distilled them into a reusable component library every new feature is plugged into those components, so designers never broke security protocols and engineers never had to guess UI rules. For the third-party integrators, we created a detailed step-by-step guide, full of sample code snippets and API references, which helped them quickly test these services and cut their integration time by 70 percent.

By first mapping every technical constraint, then hiding complexity behind reusable patterns and giving partners a clear integration guide, we achieved two goals: rock-solid security that never leaks into the UX and a simple, confident experience for every user.

In your experience, what is the most overlooked part of building scalable systems in emerging markets like Nigeria?
Too often, we associate scale with deploying new servers or opening new branches. But for emerging markets like Nigeria, true scalability means evolving your product to meet the various needs of your users and adapting to varying contexts and constraints.

In Nigeria, we are faced with a lot of digital adoption constraints like language barriers, low IT literacy levels, connectivity issues, and low-end devices, amongst others. Building a culture of continuously listening, learning, and iterating is what makes a product stay relevant across a diverse set of users. And that is the true definition of scale, as it separates the products that survive from those that wither away in this market.

How do you align product teams around technical and business goals when working across diverse sectors and with distributed teams?
First, we host a virtual design sprint workshop where we gather team members across product, engineering, design, sales, customer success, and sometimes management. This helps us to understand and align ourselves with the north star of what we want to achieve. Some of the core activities of this workshop include knowledge-sharing sessions, where experts in the field we are solving for come to share vital training and educational resources, and also peer-to-peer learning models, which involve team members discussing and sharing domain-specific resources amongst themselves.

By the end of that session, every engineer could understand the impact of some regulatory terms, and every salesperson could summarize our biggest technical constraints in two sentences.

Next is problem definition and solution exploration this aligns the team’s clarity of purpose, and here everyone gets to contribute their ideas on how best to solve this problem. While the final direction of the product lies with the Product Lead, this activity helps prevent tunnel vision on just one technical or commercial angle and allows the Product Lead to view the problem definition from diverse perspectives.

Prototype and testing an iterative activities carried on even after the workshop to ensure that we stay on track with the product vision.

I have found that organising these workshops across teams has had a profound impact throughout the development cycle: it bakes in a deep sense of ownership for each team member, as they were carried along from day zero and contributed actively during the sprint; the documents and resources shared during these workshops act as a single source of truth that everyone can refer to, our sprint board and all resources lived in Confluence, and if anyone needed clarity on an issue, they just looked it up.

A crystal-clear vision is set for the user goals, the technical requirements, and the business strategy; while these are not set in stone, they provide a solid precedence to iterate upon following feedback from users and partners.

When designing identity systems for public institutions, what risks do you consider most critical, and how do you incorporate safeguards in your design or deployment process?
Throughout my career, the two biggest risks associated with designing identity systems are data breaches and identity theft. These incidents, when they happen, often cause tremendous economic disasters and may even pose a risk to national security.

Data breaches occur when personally identifiable information (PII) of individuals is accessed without their consent, either through social engineering or system hacks. Some of the safeguards we usually incorporate include encrypting data at rest and in transit, frequent rotation of keys and secrets, and keeping an immutable audit log of all actions performed by admins/users.

Identity theft occurs when a malicious person onboards a platform using fake or stolen identities and uses those identities to perform various criminal activities. To reduce instances of identity theft, we built a multi-factor and multi-modal authentication infrastructure where we verify a user using three layers of: who you are (biometrics, face, liveness) + what you know (ID number, password) + what you have (device IP, OTP).
These safeguards do not guarantee a 100 per cent risk-free system, but with continuous improvements allow us to quickly trace and catch malicious actors and improve along the way.

What role does documentation and process standardisation play in shaping company culture and team performance in tech teams?
Everyone defaults to assumptions when there is no clear documentation, and to be able to build a business that truly scales without dropping in quality, the role documentation plays cannot be overemphasized.

As a designer, I deeply understood this, so in organisations where I worked, I didn’t just design interfaces, I designed meeting notes, deployment notes, release notes, system architecture documents, technical diagrams, API documentations, employee onboarding documents, proposals and even external email templates. Design in this context wasn’t necessarily to make things look pretty; these documents were designed to make them readable, scannable, and reusable across departments and teams.

With these designed documents in place, you can help reduce the number of questions asked per employee and the time it takes for tasks to get done. By building a culture of good documentation within your team, you invariably build a team with clarity, speed and knowledge.

Given your experience in both government-facing and consumer products, how do you navigate the tension between scale, speed, and public accountability?
Building public-sector products is like an extreme sport because it comes with the magnifying glass of the public eye. How I usually navigate this is by deploying to a smaller subset first, running rigorous tests, checks and balances before rolling out to the general public.

Even after roll out, the first few weeks are usually tense, with us monitoring metrics closely, keeping stakeholders informed, and keeping an eye on the Twitter engineers waiting to roast us at a moment’s notice.

What advice would you give to designers who want to move into product or tech leadership, but are unsure how to bridge the gap between creative and strategic decision-making?
Learn how code works. You cannot argue your way out of it or design your way out of it. If you are interested in bridging the gap between creativity and strategy, you must understand how the system you are designing for works. You do not need to learn code syntax, but at the very least, you should be able to follow through on any technical conversation within the team.

Own your numbers. Do not stop at making things look good or seamless. Track how your designs move business KPIs and clearly articulate them. The clearer you can explain why something matters, the more influence and respect you will earn.

Find mentors. Moving from pixel to strategy can be complex. I am still in the thick of it, but it helps when you find mentors who can guide you through the process, answer the questions you have, refine your ideas, and help build your character.