Engineering
backWe recently hosted Dr. Ishaya Gambo, a leading researcher from Obafemi Awolowo University, for a crucial in-person talk titled, “From Requirements to Relationships: Redefining Stakeholder Engagement in Software Engineering”. His insights forged through years of research, including during his master's and PhD focused on resolving conflicts among software development stakeholders, challenge our conventional views on development and requirements gathering.
At the heart of Dr. Gambo’s message is a fundamental truth: Every successful system runs on two APIs: the machine API and the human API. While technical APIs define how systems communicate, Human APIs define how people understand each other. When the Human API breaks, even if the code is perfectly clean, the project is destined to fail.
This is why, at Moniepoint, we are moving past passive requirement collection towards a model of continuous relationship building, treating requirements as living conversations.
The Challenge We Face in Fintech
Moniepoint operates within a highly intricate ecosystem. Every product decision impacts a diverse array of influential stakeholders. This complexity often leads to conflicting demands when launching a new feature, such as a payment service:
The Business Team: Often wants speed and revenue generation, expressing the need for the product "yesterday".
The Customers (Individuals & SMEs): Demand simplicity, ease of use, reliability, and unwavering trust.
The Compliance Team: Is primarily interested in security and ensuring regulatory rules (like those set by the CBN) are not compromised.
The Developers/Engineers: Need a clear set of requirements to deliver the system successfully.
In this competitive fintech landscape, where trust is the primary currency, poor stakeholder engagement directly leads to project delays, costly rework, and lower user satisfaction.
Moving Beyond the Traditional Approach
The traditional software development model often follows a rigid, linear path: Gather Requirements -> Build -> Deploy. Dr. Gambo highlighted that this waterfall-like rigidity inevitably leads to crises:
The Gaps of Traditional Software Development
The critical element missing from the conventional approach is continuous relationship building. This absence creates three major problems:
Conflicting Requirements: Requirements gathered from different stakeholders frequently conflict, leading to reactive compromises late in the process.
Late-Stage Changes: Development is often disrupted when stakeholders realise midway through the project that the solution doesn't align with their true vision, leading to scope creep and delays.
Stakeholder Dissatisfaction: Even when the final product technically meets the documented requirements, stakeholders remain unhappy because we addressed their stated wants instead of their underlying needs.
A New Perspective: Requirements as Conversations
To overcome these gaps, Dr. Gambo proposes a new perspective rooted in research, viewing requirements as ongoing conversations built on deeper inquiry and trust:
1. From Collecting to Engaging
We must shift from passively collecting requirements as static artifacts to actively engaging with stakeholders to discover needs through collaborative exploration. This involves proactive interaction, such as engineers sourcing feedback directly from Moniepoint customers or holding cross-functional brainstorming sessions.
2. From Static Documents to Ongoing Dialogue
A requirement must not be treated as a document to be signed off or frozen. Instead, we must treat it as a living conversation that evolves as our collective understanding of the problem deepens and new insights arrive.
3. From ‘What’ to ‘Why’
The focus of our inquiry must move beyond what the stakeholder wants (e.g., "faster payment process") to why they want it. Unveiling the 'why' reveals the true underlying business or user problem, which is crucial because a requirement defined by one stakeholder might mean something entirely different to another.
4. From Transaction to Trust
The ultimate goal of stakeholder engagement should be the cultivation of trust, rather than a simple transactional exchange of information. This trust makes all subsequent collaboration, innovation, and relationship management more efficient and effective.
The Three-Pillar Framework for Better Engagement
Dr. Gambo presented an evidence-based framework for managing the natural conflicts that arise around competing objectives like Security, Speed, and User Experience (UX). The solution lies not in avoiding conflict, but in how we handle it. The framework consists of three pillars:
Pillar 1: Identify
We must accurately determine who all the stakeholders are and what they truly need. This means going beyond job titles to understand their roles and motivations.
Action: Employ Structured Interviews, Goal Mapping, and Persona Development.
Key Distinction: Identify both functional requirements (what the system should do, e.g., logging in) and the more challenging non-functional requirements (what the system should be, e.g., fast, secure, usable).
Pillar 2: Prioritise
Not all requirements are equal. We must use a structured approach to choose which requirements deliver the most value.
Criteria: Prioritise based on Business Value, User Impact, Technical Feasibility, and Compliance.
Research Strategy: An effective prioritisation strategy, such as the MEO model (Mandatory, Essential, Optional), helps determine which features must be implemented immediately, which are secondary, and which can wait for subsequent releases.
Methods: Practical prioritisation methods include Weighted Scoring (assigning weights to strategic factors) and Collaborative Ranking (facilitated sessions in which stakeholders discuss trade-offs). Hybrid models combine quantitative data with qualitative discussion.
Pillar 3: Resolve
When stakeholders disagree, the focus must be on structured dialogue, not debate.
Techniques: Approaches include Facilitated Workshops (using a neutral facilitator), Transparent Decision Criteria (agreeing on criteria before debate starts), and Trade-off Analysis.
The Goal: The aim is informed compromise, or Goal Consensus, where all stakeholders understand the decision, feel their input was valued, and commit to the path forward, not simply creating "winners and losers".
Practical Takeaways for Moniepoint
To embed this research-driven mindset across our engineering teams, Dr. Gambo provided specific, actionable advice:
Invest Time in Stakeholder Mapping: Know the ecosystem intimately, including regulators, customers, merchants, and internal teams, to understand their diverse needs and perspectives.
Create Regular Touchpoints: Establish frequent points of engagement (e.g., monthly or bi-annual field work) with key stakeholder groups, such as Moniepoint customers or POS individuals, to gather deep insights and information that were previously unconsidered.
Use Structured Methods for Prioritisation: Avoid relying solely on intuition; use structured, research-backed methods to prioritise requirements and manage resources effectively.
Address Conflicts Early: Utilise facilitated conversations to resolve conflicts proactively.
Document Decisions and Rationales Transparently: Ensure all decisions and their justifications are clear and accessible to build trust.
Building a Culture of Engagement
Ultimately, Moniepoint's engineering future is human-centred. This shift is not merely about implementing new processes; it is about building a mindset.
A culture of engagement means recognising that the product, process, and people are the three key pillars of software engineering. We must foster an environment that:
Encourages cross-functional collaboration.
Creates safe spaces for voicing concerns, where every perspective is valued.
Celebrates stakeholder partnerships and learns from every project.
By investing in relationships, we see measurable business impacts, including Faster Time-to-Market, Reduced Project Risks (since conflicts are addressed early), and Higher User Satisfaction (because true needs are met).
At Moniepoint, every feature we build connects a network of stakeholders, and these relationships are our true architecture. When we embed empathy and evidence-based engagement in engineering, we don't just build systems, we build significance.
