Replacing a 20-year-old insurance system with East Africa’s first purpose-built bancassurance platform.

Instead of guessing what NMB needed, we put 40+ people from every department in one room and let them tell us. Before any design work started, I participated a discovery meeting with NMB where more than 40 people from different departments joined to explain their pain points first hand. Sales agents, operations, claims, finance, compliance, IT, and senior management were all present. That mix mattered. A system like this touches every one of those teams, and each one only sees its own piece of the problem. To keep 40+ voices organised, we used the Value Proposition Canvas. It’s a simple method with two sides. On one side, you map the customer: what they are trying to get done, what frustrates them, and what would make their work better. On the other side, you map what you will build: what the product does, how it removes each frustration, and how it creates each gain. Here, the “customer” was every NMB team, and the “product” was the new system. How the session worked: Step 1, jobs: each department explained what they actually do all day. Step 2, pains: each team explained what slows them down or goes wrong, in their own words. Step 3, gains: each team described what a good day would look like. Step 4, matching: with the pains and gains on the wall, we matched each one to a feature idea. Every pain needed a pain reliever, and every gain needed a gain creator. Anything that didn’t connect to a real pain or gain didn’t make it to our list. What this gave us: 1. One shared picture. For the first time, every department saw the same wall of pains, and realised their frustrations were connected. Re-entering data in sales was causing reconciliation work in finance. 2. Priorities we could defend. Because the pains came from NMB’s own people, deciding what to build first was a conversation about evidence, not opinion. 3. Early buy-in. People who helped write the canvas wanted to see their pain solved. That made later reviews and testing easier, because the teams already felt ownership of the system. 4. A clear design brief. Pains like duplicate customers, hidden claim status, and vendor dependent products became the headline features of the final platform The canvas became the thread running through the whole project. Whenever a design decision was unclear, we went back to the wall and asked one question: which pain does this solve, and which gain does it create?