DEV Community: Celestina Dike

Turning Messy Data into User Insights: Using Thematic Analysis

Celestina Dike — Thu, 30 Apr 2026 11:53:00 +0000

By Barakat Ajadi, Product Manager

Most product teams are sitting on research gold they don't know how to use. They conduct interviews, gather feedback, and collect transcripts, then struggle to turn it all into something the team can actually act on. This is that story, and more importantly, this is the method that changed how I approach qualitative data.

1. In the Beginning
You have carried out your user interviews and research, but what do you do with the messy data you have gathered? How do you make sense of it and use it to make informed decisions?
I recently conducted user discovery for a new feature we shipped. I grouped users into three categories to understand them at every phase of the journey and to see how each step was perceived.
I started by gathering users across the different groups and creating a research plan, which I shared with the customer research team for vetting. A process was then set up for interview slots, and the journey began. But in reality, this was only the beginning.

2. Making Sense of the User Groups
Dividing users into groups wasn't just for structure. It was the only way to get a complete picture of the journey.
Each group represented a different stage. Group one had completed the process. How did you complete it, and what were the hurdles you had to cross, if any? Group two was still in the process. Are you experiencing similar hurdles or a different one entirely? Group three hadn't started the process. What prevents you from starting this flow?
Understanding every stage helps uncover pain points and how to make the flow seamless for users throughout the cycle. A single user group would have collapsed very different experiences into one. We would have missed the fact that blockers at the start of the journey are completely different from blockers at the end.

3. Carrying Out the User Interviews
Before the first call, make sure you have recording and transcription enabled on your meeting platform. Get approval from the user upfront. This is non-negotiable.
A plan? Check. Interviews scheduled? Check. Now this is where you start to acquire data. A bunch of user interviews are lined up for the week; the interesting part is where you ask questions and listen to your users talk. Because you have a plan set up with your question bank, it makes it easier, but a user may say something you are not expecting, and it is important to ask follow-up questions to dig deeper.
We have AI infused into our meeting platform, so recording and transcribing were seamless. Tools like Otter.ai, Fireflies, or even the built-in transcription on Google Meet and Zoom work well here. The transcript becomes your best friend in the next phase. Trust me on that.

4. The Storm Before the Calm
Phew. The interviews are done, and it has been quite a week. Twenty calls across three different user groups, and now I am sitting with a folder full of transcripts and recordings staring back at me.
Here is the thing nobody really tells you about user research. The interviews are actually the fun part. You are in a flow state, asking questions, listening, picking up insights in real time. Post-interview is when the actual work begins. You have raw data and need to analyse it and draw insights.
I opened the first transcript. Then the second. By the fifth one, I already had contradicting information. A user from group one said the process was straightforward. A user from group two said they had no idea what they were supposed to do at the exact same step. Both were right. They were just at different points in their journey. But reading transcript by transcript, it is genuinely hard to hold it all together.
I needed a way to find patterns from these conversations without losing the nuance. That is when I turned to thematic analysis.

5. Introducing Thematic Analysis
Thematic analysis is a way to form patterns from qualitative data. You break down your data into labels called codes, and then group those codes into bigger themes.
Here is how I approached it. I gathered all the transcripts and read through them, coding and labelling each one. A code is simply a short label that captures what a user is saying or feeling at that point. For example, a user said, "It took me 5 minutes to complete," and the code for that was completion time. Another said, "One thing I like is that delivery is swift", and the code was ‘merchant satisfaction’. Another said, "I don't think anyone should have issues filling the information", and the code was ‘perceived difficulty’.
Doing this across 20 transcripts, you start to pick up patterns. The same ideas are showing up just in different words. That is your signal.
Next, group similar codes into themes. Codes like completion time, perceived difficulty, and document readiness all pointed at the same underlying problem. They became one theme: Activation Friction. Where you have a cluster of related but distinct codes under one theme, those become sub-themes, a way of preserving the detail without losing the bigger picture.
By the end, I had 8 themes that cut across all three user groups. What made this powerful was seeing which themes were universal across the journey and which ones were specific to a particular stage.

6. Where AI Fits In
Now let's address what everyone is thinking. Reading through twenty transcripts? Three groups? Coding responses manually? This sounds like a lot, and this is where AI can come in to make your work significantly easier.
Once I had my transcripts ready, I fed them into an AI tool. ChatGPT works well for this, as does Claude or a dedicated research tool like Dovetail. I prompted it to code responses, identify similar phrases, and flag recurring sentiments. What would have taken me an entire day was done in a fraction of the time.
Here is something important, though. AI gives you a strong starting point, not a final answer. The interpretation of what those patterns actually mean for your product still sits with you. You handle the thinking.

7. From Themes to Product Insights
Having 8 themes feels good. But themes alone don't ship features. The next step was turning what I found into something the team could actually act on.
I broke down each theme into four sections in my research report.
What We Heard. This section was a brief summary of what users said about the theme, with sample quotes to support it. For example, under the theme of Activation Friction, quotes clustered around not knowing a document was required, or needing time to gather specific documents before completing the flow.
Why It Matters. How does this theme affect the user journey? Does it cause delayed activation? Drop-off? Frustration that only surfaces later? This section connects the theme to a real business or experience consequence.
What It Means. This is where you translate the theme into a product diagnosis. Where does the issue actually come from? Is the form too long, or is it the missing visual cues that tell users what to prepare? Are users benchmarking against a competitor's experience? This section separates the symptom from the cause.
Recommendations. Based on everything identified, what should the team do? This is where research becomes a roadmap. Before the analysis, conversations with stakeholders were centred on surface-level fixes. After that, we were talking about the right problems.

8. What Thematic Analysis Changed
Honestly? It changed how I think about qualitative data altogether.
Thematic analysis gave me a process, and having a process meant I could defend my insights. Walking into stakeholder meetings, the conversation wasn't "users seem frustrated with the journey." It was saying "across all three user groups, activation friction and perceived difficulty were the two most consistent themes, and here is the
If you are a product manager sitting on a pile of interview transcripts right now and wondering where to start, start here. The themes are already in your data. Thematic analysis just helps you find them. The messy data was never the problem. It was always the signal.

Barakat Ajadi is a Product Manager at Moniepoint.
Read more articles from our technical team on the blog

When Code Becomes Cheap, Thinking Becomes Expensive

Celestina Dike — Thu, 26 Mar 2026 12:27:53 +0000

From "Prove It in Code" to "Prove It in Judgment"

For decades, credibility in software came from what you built with your own hands. Writing robust systems required stamina, coordination, and deep technical craft. The effort itself acted as a filter; only ideas worth the cost were implemented.
That constraint is gone.

Today, large language models can generate entire services, documentation, tests, and deployment scripts in minutes. The barrier to producing software artefacts has collapsed. The limiting factor is no longer typing speed or knowledge of syntax; it is clarity of thinking.

Inside an organisation adopting AI, this shift is profound. A team can spin up a prototype payments reconciliation service over a weekend using AI assistance. But the real question becomes: Who defined the problem well? Who validated the trade-offs? Who understands the system well enough to maintain it?
Code is abundant. Judgment must not become scarce.

When Output Becomes Cheap, Signal Changes

Well-structured codebases and thorough documentation used to be signals of maturity and care. Today, AI tools can generate pristine README files, polished APIs, and layered architectures instantly.
This makes surface quality an unreliable proxy for depth.
Within an AI-enabled engineering team, you might see beautiful documentation generated in seconds, clean abstractions suggested by the model, and automated test scaffolding created in bulk, but none of these guarantee that the system handles scale, edge cases, or operational realities.

An AI can generate an event-driven order processing service, complete with retry logic, dead-letter queues, and idempotency keys, and the code will look immaculate. But does it handle message ordering under partition rebalancing? Does the retry backoff account for downstream rate limits? A model can scaffold a Kubernetes deployment manifest with health checks, resource quotas, and horizontal pod autoscaling, yet miss that the pod affinity rules will starve a specific availability zone under real traffic patterns.

The signal of quality shifts from how polished it looks to something harder to fake: Does the team understand the system deeply? Is there ownership and accountability? Can someone explain why the circuit breaker threshold is set to 60% and not 40%, without re-prompting the model?
In AI adoption, governance and provenance become more valuable than aesthetics.

The Compression of Effort

AI drastically reduces the mechanical cost of building software. Tasks that once required weeks, writing gRPC service definitions with protobuf schemas, building CDC pipelines to sync state across bounded contexts, and standing up end-to-end integration test harnesses with containerised dependencies can now be compressed into hours.
This is not hype. It is leverage. Used correctly, AI frees engineers to spend more time on architecture and systems thinking, explore multiple design alternatives quickly, and run experiments that previously felt too expensive. In an organisation adopting AI at scale, this means faster iteration cycles and broader experimentation: scaffolding a complete OAuth2 flow with PKCE, token rotation, and role-based access control in an afternoon instead of a sprint; generating contract tests between fifteen microservices to catch breaking changes before deployment; spinning up a feature-flagged canary release pipeline to compare two ranking algorithms in production traffic. Teams can prototype an entire event-sourced domain model, evaluate its query performance against a traditional CRUD approach, and make an informed architectural decision all before the old process would have finished the design document.
However, speed without discipline produces fragile systems. The advantage goes to teams that combine AI acceleration with experienced technical oversight.

The Risk: Infinite Artefacts, Finite Understanding

If software can be generated endlessly, its perceived value drops. A pull request that took weeks of focused effort once carried an implicit sense of respect. Now, large AI-generated diffs may appear instantly with unclear human involvement.
This creates tension. Reviewing becomes harder than generating. Accountability becomes blurry. Junior engineers may rely on tools without building fundamentals.

For organisations, the real danger is not "bad AI code." It is teams that lose the ability to reason about systems independently.
If AI writes the data pipeline, optimises the SQL, and configures the infrastructure, but no one fully understands the flow, technical debt becomes invisible.

AI adoption must therefore include a strong review culture, explicit learning paths, and clear architectural ownership. Otherwise, productivity gains today become fragility tomorrow.

Talk Becomes the Multiplier

In this new landscape, the most valuable skill is not typing code, it is articulating intent`
The engineer who can frame a problem precisely, define constraints clearly, ask the right questions, and evaluate model output critically will outperform someone who merely executes.
AI does not eliminate engineering roles. It amplifies differences in clarity and systems thinking. Organisational structures compress too - design, coding, testing, and iteration increasingly blur into tight feedback loops.

The Future Is Thinking-First

The future of software development is not code-first. It is thinking-first.
When machines can generate implementation at scale, the competitive edge shifts to strategic problem definition, technical stewardship, responsible governance, and mentorship that builds foundational skill.
Code may be cheap now. But reasoning, accountability, and leadership are not.

Got any questions? Drop a comment

Pavan leads multiple engineering departments at Moniepoint

Curiosity Doesn’t Kill the Engineer

Celestina Dike — Wed, 25 Feb 2026 18:48:48 +0000

It Gives Them Nine More Lives in the Age of AI

“Curiosity killed the cat” is a warning.
In engineering, it is survival. And in the age of AI, it may be the single trait that keeps us relevant.

AI can autocomplete code. It can scaffold services. It can generate infrastructure templates, tests, and even architectural diagrams.
But AI is trained on patterns. Curiosity questions patterns.
That difference matters.

The engineer who stops at “it works” will slowly be replaced by systems that can also make things “work.” The engineer who asks “why the queue saturates at this load”, “what the true bottleneck is”, “what assumption an abstraction is hiding”, and “what happens when the model is wrong” cannot be easily replaced.

Curiosity operates below the surface layer where AI is strongest.

Every Deep Question Is an Extra Life

When you trace a request from the load balancer to the kernel to userspace and back, you gain a life.
When you understand how WAL durability interacts with fsync semantics, you gain another.
When you read the consensus paper instead of just using the library, that’s another.
And another life when you model throughput using queueing theory instead of guessing,
These are not just technical wins. They are resilience wins.

AI can produce solutions. Curious engineers understand trade-offs.
AI can refactor code. Curious engineers understand failure modes.
AI can summarise documentation. Curious engineers build mental models.
Mental models compound.

The Real Threat Is Complacency

The danger is not that AI will replace engineers.
The danger is that engineers will outsource their curiosity.
If we let tools think for us, abstractions become opaque walls instead of glass windows. We become operators of systems we do not understand.
The curious engineer uses AI differently.
Not as a crutch but as a multiplier.
They ask better questions.
They interrogate outputs.
They test assumptions.
They dive into edge cases that the model glosses over.
Curiosity turns AI from a replacement into an amplifier.

Curiosity Makes You Antifragile
When production fails, the incurious engineer searches for a quick answer.
The curious one traces signals.
Why did the replication lag spike?
Why did tail latency explode?
What is the queue discipline actually doing?
Is this a coordination limit or a physical limit?
Each failure becomes another life added to the stack.
Over time, systems stop looking like random collections of tools. They start revealing deeper patterns.
Entropy and compression.
Backpressure and channel capacity.
Cache hierarchies and storage engines.
Scheduling theory and latency.
Once you see principles instead of products, you cannot be easily automated away.
AI predicts tokens.
Engineers reason about constraints.

Nine Lives in the AI Era

Technologies will change.
Frameworks will expire.
AI models will improve.
But the engineer who remains relentlessly curious about fundamentals, failure, and first principles keeps regenerating.
Each layer of understanding is another life.
In an era where automation accelerates everything, the only durable edge is the willingness to keep asking ‘why?’ long after others have stopped.

Curiosity will not kill the engineer.
It will give them nine more lives.
And it may be exactly how we survive.

Opeyemi Folorunsho leads the Engineering Research & Development team at Moniepoint.

How to Build Engineering Teams That Think in Systems, Not Tickets

Celestina Dike — Wed, 25 Feb 2026 17:41:21 +0000

                    _Commits by John_

The Performance Conversation That Changed the Room

During a performance review, an engineering manager highlighted that an engineer had spent several late nights debugging production issues and pushing features. It was presented as proof of performance beyond expectation.
The room expected agreement.
Instead, I said something that made it uncomfortable.

Spending more time is not the same as performing better. Effort alone is not performance. Outcome is.

Yes, features were shipped quickly. But months later, we were still fixing subtle bugs tied to that release. Every small enhancement required touching core architectural decisions. During the product review, assumptions were not questioned. The design was implemented verbatim.
The engineer looked busy. The system was fragile.

In the same period, another engineer worked normal hours. No heroics. No drama. Since his release, there have been no production incidents in that module. He questioned the PRD. He challenged design decisions. He wanted to understand how the feature affected customers. As we scaled, extending his work became easier, not harder.
He was rated beyond expectations.
That contrast exposed something deeper — a flaw not in the engineers, but in what we had trained ourselves to value.

• • •

We Reward What Is Visible, Not What Is Valuable
Most engineering performance systems are biased toward visible work.
Hours spent. Story points completed. Tickets closed. Production calls attended.
These are observable. They are measurable. They make managers feel progress is happening.
But systems thinking is often invisible.
Clean architecture is invisible. Prevented incidents are invisible. Reduced complexity is invisible. A system that rarely breaks does not receive applause.
Over time, engineers optimise for busyness instead of durability.
When that happens, ticket completion becomes the goal instead of system integrity.
And nowhere is this more apparent than in how we treat incidents.

• • •

Prevention Should Matter More Than Recovery
Recovery is important. Incident response discipline matters. Mean time to recovery matters.
But prevention should carry more weight.
If I were to assign weights, prevention should count for 80 per cent and recovery for 20 per cent. It is cheaper to prevent than to recover.

Reducing incidents from 10 per month to 1 is more valuable than reducing recovery time from 2 hours to 30 minutes.
When teams focus primarily on recovery, they build better firefighters.

When teams focus on prevention, they build better architects.
If you celebrate the firefighter more than the architect, you are building a culture that creates a fire incident all the time.
The root cause of this pattern is almost always the same — teams that have been conditioned to think in tickets.

• • •

Ticket Thinking Creates Avoidable Work
Ticket thinking creates the illusion of velocity while increasing fragility.

Architecture gets reworked after release. Hotfixes stabilise features that should have been designed more carefully. Refactoring becomes necessary because shortcuts were taken to meet sprint targets. Adding new modules becomes increasingly expensive because the foundation is unstable.

Velocity looks impressive in the short term. But complexity compounds quietly.
Every new feature becomes harder to ship safely. Every release carries anxiety. Engineers spend more time fixing than building.
That is not scale. That is activity disguised as progress.
So how do you break the cycle?

• • •

How to Build Teams That Think in Systems

Shifting from ticket thinking to system thinking requires deliberate leadership.

Redefine performance. Stop rewarding just hours spent or story points completed. Start recognising engineers who reduce incident frequency, simplify architecture, and make future changes easier. Promotion should reflect ownership of outcomes, not volume of output.

Change what you measure. Track incident recurrence, change failure rate, and the safety of extending the system. Measure the reduction of avoidable work. If every new feature destabilises the system, velocity is meaningless.

Involve engineers earlier. Engineers should not simply implement requirements. They should challenge assumptions, clarify ambiguities, and consider second-order effects. An engineer who takes a PRD verbatim is implementing tasks. An engineer who questions it owns outcomes.

Reward complexity reduction. Promote engineers who simplify flows, clarify domain boundaries, and reduce cognitive load. Complexity is invisible until it explodes. Recognise those who prevent that explosion.

When you start doing all of this, one question inevitably comes up — especially from engineers who have been grinding hard but not seeing the results they expect.

• • •
Promotion Is About Mastery, Not Busyness

Many engineers ask why they are not being promoted despite long hours and visible effort.
Promotion panels are not looking for busyness. They are looking for depth.

Companies are looking to promote masters.
Mastery in engineering is not about writing more code or responding to more incidents. It is about understanding systems deeply enough to design them so that problems do not repeatedly occur. It is about building foundations that scale and optimising for the long term.
Speed and quality are not enemies; they answer to mastery.

• • •

This is ultimately a leadership problem. If we want to build engineering teams that think in systems, not tickets, we must reshape how we define performance, what we measure, and what we celebrate.

Tickets close.
Systems endure.

And endurance is what separates coding from engineering.

*John Ojetunde leads multiple Engineering Teams at Moniepoint
*