1. SNAPSHOT
Client: Ziada (formerly Kazi App)
Industry: Technology / Jobtech / Marketplace
Geography: Kenya
Business age at engagement: Under 2 years (concept stage to early growth)
Team size at engagement: Small — under 10
Engagement date: 2022 — 2024 (approximate)
Growth stage: 01 — Strategic Direction through 04 — Momentum
Entry point: Execute — then Diagnose and Architect as engagement deepened
What they came asking for: Social media support
Pattern: The build encoded the wrong assumptions, and the data being collected was not informing anything
2. EXECUTIVE SUMMARY
Kazi App was a two-sided marketplace connecting service providers in the informal sector (fundis, e.g., electricians, plumbers, mechanics, etc.) with customers who needed them. The idea had been validated by the founder’s own experience and her network’s enthusiasm. Two years of building had followed, and the app had users. But the business was moving faster than its own foundation could hold.
The engagement began as social media support. It became something different when the questions started surfacing structural problems the execution work could not fix: a product name encoding the wrong promise, a user journey that was not converting the side of the marketplace that mattered most, data being collected daily that was informing no decisions, and new partnerships being added before the core commercial problem was solved.
The work that followed – slowing the business down enough to examine what it was actually building, confirming the user journey before amplifying noise, building the data infrastructure that made the HubSpot contact classification possible, rebranding from Kazi to Ziada – produced about 130,000 users on a confirmed foundation.
Without this work, Kazi App would have continued growing downloads on the back of a competitor’s advertising budget, attracting the wrong audience at scale, with data being collected that was informing nothing and a user journey that was converting the easier side of the marketplace while the commercially critical side went unsolved.
3. THE SITUATION THEY RECOGNISED
The founder had spent two years building before the engagement began. The idea was real – born from a specific, lived moment of needing a skilled fundi in a remote area and having no reliable way to find one. Her network had confirmed the idea was strong. Building had started.
What had not happened was formal market validation. The product existed because the problem was real, the founder was credible, and momentum was moving. Funding was needed to prove the concept and grow, which meant growth metrics mattered – and downloads were coming.
What the downloads were not revealing was that the name was doing work the business had not intended. Kazi means work/job in Swahili. A significant proportion of the people downloading were looking for jobs. Another significant proportion were writing in for loans. Neither group was the buyer the marketplace needed.
On the other side of the marketplace – customers booking service providers – the problem was different. Trust. A customer looking for an electrician was being asked to trust a fundi they had never met, through a platform they had just discovered, for work that would happen in their home. That trust problem had not yet been systematically addressed. Ratings existed. Galleries did not. Customer service from service providers was inconsistent. The infrastructure for trust had not been built.
The business knew something was not working. The response had been to keep moving.
4. THE MOMENT OF RISK
Several decisions were already in motion or recently made when the engagement deepened beyond social media support.
Downloads were growing – partly because the competitor app with the same name and a larger paid ads budget was driving discovery for both. ASO work was being done to filter out the wrong users, but the filtering was fighting a current rather than changing the channel. The downloads that came through were not the right users at the rate needed, and the resources being spent on acquisition were amplifying a journey that had not been confirmed to convert.
A loans partnership had been added in response to user behaviour data – a high volume of loan enquiries – without a full examination of what that signal meant for the product direction. The partnership was real and was being communicated to users, but it risked pulling the product’s identity in a direction that had not been deliberately chosen.
More broadly, data was being collected. Daily reports existed. But the reporting was manual, on Excel, without a dedicated person to build dashboards or draw commercial conclusions. The data existed and was informing nothing.
The business was adding to a system that had not been confirmed to work. Each addition – the loans partnership, the continued ASO spend, the social media execution – was building on top of a user journey that had not been examined from the side of the marketplace that mattered most.
The risk was not any single decision. It was the cumulative cost of building faster than the foundation could hold.
5. WHAT WE FOUND
Finding 01 — The name was encoding the wrong promise at scale
“Kazi” was producing a specific and consistent misread. New users arrived expecting employment opportunities or job listings. The platform was a service provider marketplace – an entirely different product promise. The misread was not occasional. It was structural: the name, the competitor’s advertising, and the category association were all pointing in the same direction.
Every user acquired under “Kazi” arrived with a prior expectation the product could not meet. Reorienting them required effort the team was spending instead of converting the right audience. The name was doing active commercial harm at scale.
Finding 02 — The customer side of the marketplace was the commercial constraint and was receiving the least attention
Service providers were joining the platform – partly because “Kazi” drew them in, partly because the app offered genuine value for finding work. But customers booking service providers was where the commercial model depended, and this side was harder.
Trust was the specific barrier. A customer needed to believe that a fundi found through an app would show up, do good work, and be safe to let into their home. The infrastructure for that trust – ratings visible on profiles, galleries showing past work, verification of service providers, customer service standards, a resolution process when things went wrong – had not been fully built.
The team was small. Attention was split across acquisition, partnerships, and product development. The customer side of the marketplace was being managed rather than solved.
Finding 03 — The data was being collected but was not informing anything
Daily reports existed. Numbers were tracked. But the reporting was manual, produced on Excel, without a dedicated person to analyse it or a dashboard that translated raw numbers into decisions. The volume of loan enquiries, for example – which had triggered a partnership with a loan service provider – was visible in the data. But what that volume meant, what proportion of the user base it represented, how it compared to other enquiry types, and what it implied for the product direction had not been examined.
Data was present and inert. The cost of that inertia was not the absence of information. It was decisions being made from a partial view of what the information was actually showing.
Finding 04 — The business was moving at a speed its infrastructure could not yet support
Each new addition – partnerships, ASO spend, social media, new product features – was being added to a system whose core conversion problem had not been solved. The additions were real responses to real signals. But they were applied before the signal had been properly read.
The business was not failing. It was building on assumptions that had not been examined because the pace of building had not left room for examination.
6. WHAT CHANGED
The fundamental shift was a deliberate slowing down – not to stop the momentum, but to examine what was being built before more was built on top of it.
Specific decisions that became possible:
The decision to rebrand was made from an examined position. Ziada – meaning “extra, more than what is expected, over and above” – was chosen by the founder as a name that described what the platform actually delivered, to the right audience, with a commercial promise the product could keep. The rebrand was not cosmetic. It was a repositioning. Downloads fell after launch. The quality of users who came through was stronger.
The ASO strategy changed. Under Kazi App, the work had been exclusion – trying to filter out loans seekers and job hunters from keyword targeting. Under Ziada, the strategy paused significant ASO spend deliberately. The user journey needed to be confirmed before more users were sent into it. That decision required naming the problem clearly enough that a founder who had been moving fast agreed to slow down.
HubSpot was implemented from scratch. The Excel-based daily reporting was replaced with a contact classification system that made the data useful – not just visible. The volume and type of enquiries, previously noted but unactionable, became the basis for commercial decisions. The loans partnership, for example, could now be evaluated against actual data on loan enquiry volume and its proportion of total user interactions, rather than from the impression that the volume was significant.
The customer side of the marketplace received dedicated attention. Galleries were built into the app so service providers could show their work. Ratings infrastructure was developed. Service providers who were vetted received the verification mark. Customer service training materials were produced for service providers, because the trust problem on the customer side was partly a service standards problem that training could address. The infrastructure for trust was built rather than assumed.
What was not possible before the engagement:
Making product decisions from data rather than impression. Examining the user journey on the customer side before adding more to the service provider side. Rebranding from a commercial position rather than a reactive one. Slowing the ASO and paid media spend with a clear rationale rather than continuing to filter out the wrong audience at cost.
7. THE RESULT
Commercial: 130,000 users on a confirmed foundation – with a user base that had been reoriented through a deliberate rebrand, a classified contact system, and a customer journey that had been examined rather than assumed. The commercial model demonstrated enough proof of concept that the founder could evaluate the next phase of the business from an informed position rather than from accumulated momentum.
Operational: The business had data infrastructure for the first time. HubSpot replaced manual Excel reporting. Contact classification meant the loan enquiry volume, the booking patterns, the service provider activation rates – all of it was visible and actionable rather than collected and inert. Decisions that had previously been made from impression could now be made from evidence.
Confidence: The engagement gave the founder the evidence base to make a significant commercial decision – the rebrand – from an examined position. The name change was not reactive to the competitor. It was the result of understanding what the product actually was, who it was for, and what the name needed to communicate to the right audience. That is a different kind of decision from one made under pressure.
8. WHAT THIS PREVENTED
Growing downloads at scale on a user journey that was not confirmed to convert. The ASO and paid media spend under Kazi App was driving volume. Pausing it deliberately – naming the risk of amplifying noise rather than solving the conversion problem – prevented a significant investment in acquisition that would have produced more users at the same conversion rate on an unexamined journey.
Data remaining inert while decisions were made from impression. The loan enquiry volume that triggered the PesaKit partnership was real. Whether it was the signal it appeared to be – whether it represented a strategic direction worth pursuing – required the kind of analysis that was only possible once the data infrastructure existed. The HubSpot implementation made that examination possible. Without it, the partnership would have continued to be evaluated from impression rather than evidence.
A rebrand made under competitive pressure rather than from commercial examination. The competitor with the same name and a larger paid ads budget was a real commercial problem. The reactive response would have been to rebrand quickly to escape the confusion. The examined response was to understand what the product actually was, confirm the audience it needed to reach, and choose a name that described the promise the product could keep. Ziada was that name. A reactive rebrand would likely have produced a different name with the same unexamined foundation underneath it.
The trust problem on the customer side remaining unsolved while the service provider side continued to grow. A two-sided marketplace where one side is growing faster than the other is a structural imbalance that compounds over time. More service providers on a platform with insufficient customer trust produces a worse experience for the service providers – fewer bookings, more waiting, less retention. Building the customer trust infrastructure – galleries, ratings, service standards, training materials – addressed the imbalance before it became the reason service providers stopped engaging.
QALLANN NOTE
The engagement began as social media support. It became something different because the questions that came from doing the execution work surfaced structural problems that execution alone could not fix. That is how most of the work at this level actually starts – not from a fractional CMO brief, but from someone close enough to the work to see what the work is building on.
The 130,000 users the engagement produced were predominantly service providers – electricians, plumbers, mechanics etc — who had been verified, classified, and trained. At the time, the consumer trust barrier on the other side of the marketplace was the unsolved problem. It turned out to be solvable in a different direction: rather than building individual customer trust one booking at a time, the model moved to B2B clients – construction companies, project managers, businesses with ongoing trades needs – who needed access to a reliable, vetted network of service providers at scale.
The trust problem that was hard to solve retail became an asset wholesale. The 130,000 service providers are not a consequence of a pivot. They are the foundation the pivot was built on. The contact classification system, the service standards training, the HubSpot infrastructure, the gallery and ratings work – all of it is now the product rather than the support layer for a product that has since changed.
This is what an engagement that produces a real foundation looks like when the founder uses it well. The commercial model evolved. The asset the engagement built did not.
What the engagement did not resolve: the consumer side of the marketplace – individual customers booking individual fundis – remained the harder problem at close. Whether a retail trust model at scale was achievable within the resource constraints of the business is a question the engagement surfaced but could not answer. The founder’s decision to reorient toward B2B is the answer she found. It was a decision made from an informed position rather than from accumulated momentum and hope.
The pattern this engagement exemplifies is one of the most common in early-stage product companies: a founder with a real idea, genuine momentum, and a pace of building that outstrips the examination of what is being built. The data is collected but not read. The user journey is growing but not confirmed. The additions are applied to a system whose core conversion problem has not been solved. Slowing down enough to look is not a failure of confidence. It is the condition that makes the next phase of building worth doing, whatever form that next phase takes.