Building products that understand the work they're meant to do.
Hi. I'm Muslimah. I'm a Product Manager drawn to products that solve real problems, especially where systems, people, and day-to-day workflows meet. My work sits across SaaS platforms, AI-assisted tools, and operational experiences, and I care deeply about building things that feel clear, useful, and human.
What's here
About Muslimah
I'm a Product Manager with a background in software engineering. I'm drawn to problems that sit between systems and people, where thoughtful product decisions can turn complexity into something clear and usable.
My approach to product starts with understanding the problem properly. Before thinking about solutions, I spend time learning how people actually work. The constraints they deal with, the workarounds they've built, and the small decisions they make every day because the tools around them were never designed with them in mind.
I'm comfortable working in uncertainty. Most product work starts without perfect information, so I've learned to move forward while still asking the right questions. For me, good product management is about creating clarity for the people building the product, not just producing roadmaps for stakeholders.
Outside of product, I enjoy reading, writing, and following ideas that help me understand how people learn and interact with technology. I'm especially interested in tools that make complex things simpler and more accessible. Most of the time, I'm either exploring a new idea, writing about something I've been thinking about, or building a small experiment to see where it leads.
Product Work
Some of the products I've had the chance to build and shape. Each one started with a messy problem and ended with something real people now use.
Case Studies
A deeper look at selected projects, from the original problem to the decisions that shaped the outcome. I also reflect on what worked, what did not, and what I would approach differently now.
NeuroStudy Buddy is an AI-powered study assistant designed to support students who struggle with dense academic material, particularly those with dyslexia and attention difficulties.
Academic resources are often written in language that assumes strong reading fluency and sustained concentration. For many students, this creates a barrier before learning even begins.
Instead of focusing on understanding the concept, students often spend most of their energy simply trying to decode the text.
The goal of NeuroStudy Buddy was to explore whether AI could act as a support layer for learning by transforming complex academic language into clearer explanations while preserving the original meaning.
The product was built as a working prototype using Streamlit and the OpenAI API. Students paste academic text into the interface and receive a simplified explanation designed to reduce reading friction and improve comprehension.
The prototype focuses on a single, distraction-free workflow designed to minimise cognitive load.
A student copies a paragraph from lecture notes, a textbook, or a research article and pastes it into the NeuroStudy Buddy interface.
The AI processes the text using prompts designed to simplify sentence structure and clarify terminology without losing the meaning of the original content.
Within seconds, the system produces a clearer explanation that helps students grasp the concept faster.
The interface intentionally remains minimal so the tool supports the user’s focus rather than competing for attention.
Academic writing frequently assumes a level of reading fluency that many students do not have.
Long sentences, dense terminology, and layered explanations require multiple passes to understand.
For students with dyslexia or ADHD, this creates an exhausting learning experience where effort is spent decoding language instead of understanding ideas.
The real barrier is not access to information, but how that information is written.
Existing accessibility tools focus mainly on reading mechanics such as text-to-speech. While useful, they do not reduce language complexity.
The discovery phase focused on understanding how reading complexity affects learning for neurodivergent students.
Research explored literature on dyslexia, cognitive load theory, and comprehension barriers in higher education.
One recurring insight was that many accessibility tools change the format of information rather than the clarity of the information itself.
Listening to complicated text does not necessarily make it easier to understand.
This shifted the framing of the problem. Instead of helping students read faster, the product should help them understand faster.
Several constraints shaped the early development of the prototype.
First was scope. The objective was not to build a full learning platform but to test whether AI-driven text simplification could meaningfully support comprehension.
Technical resources were also limited. The product was built independently using Streamlit and external APIs, which required prioritising simplicity in both architecture and interface design.
The biggest constraint was accuracy. Simplifying text is only valuable if the meaning remains intact.
Prompt design and repeated testing were therefore critical to ensure explanations stayed faithful to the source material.
One of the most important decisions was to focus on a single capability: simplifying academic text.
Many additional features were possible such as flashcards, summaries, or automated notes. However expanding too early would dilute the core value of the product.
The product needed to solve one meaningful problem extremely well.
The interface was intentionally designed to be minimal. Students paste text, receive a simplified explanation, and continue studying.
Significant time was also spent refining prompts to ensure explanations were simpler but still academically accurate.
The result was a functional AI-powered prototype capable of transforming dense academic text into clearer explanations within seconds.
Early testing showed that language models could reduce sentence complexity while preserving meaning, suggesting strong potential for accessibility-focused learning tools.
The experiment validated a key hypothesis: AI can act as a support layer that helps students engage with difficult material rather than avoid it.
This project reinforced how often accessibility problems are framed incorrectly.
The challenge is not always the user's ability to process information, but the way the information is presented.
It also highlighted the importance of simplicity in product design. The most valuable version of the product was not the one with the most features but the one that solved a clear and meaningful problem.
Finally, building with AI requires strong product thinking. Language models are powerful tools, but they require careful constraints and clear objectives to produce reliable outcomes.
At eLinkedUp, I worked on improving the client onboarding experience so the team could collect the right information earlier, reduce confusion, and create a smoother handoff into delivery.
As a startup, the company was moving quickly, but onboarding still relied too heavily on fragmented information, repeated follow-ups, and manual coordination.
What looked like a simple intake process was actually creating avoidable friction for both clients and the internal team.
My role was to help turn that messy early experience into a more structured workflow. I worked closely with the founder and engineers to identify inefficiencies, shape the onboarding flow, test functionality, and improve how the product supported the business process.
This project gave me direct experience working on product inside a live startup environment where speed mattered, priorities shifted often, and product decisions had to support both user experience and operational efficiency.
The onboarding experience was designed to guide new clients through sharing the information the team needed to begin delivery without relying on scattered messages or repeated clarification.
A typical flow started with a new client entering onboarding and submitting key business, brand, and service information through a more structured experience.
That information could then be reviewed internally and used by the team to move more confidently into setup and execution.
The product value was not just in collecting information, but in collecting it clearly, consistently, and at the right stage.
Because the company was still growing, the experience had to support a lean team while still feeling professional and reliable for clients.
Before the improvements, onboarding new clients was more manual and fragmented than it needed to be.
Important information arrived across different channels, details were sometimes incomplete, and the team often had to go back to clients for clarification before work could properly begin.
This created friction on both sides. For clients, the process could feel repetitive or unclear. For the business, it meant slower handoffs and more internal effort just to reach a usable starting point.
The real problem was not just missing information. It was a workflow that was not structured enough to reliably gather what the team needed.
In a startup environment, that kind of inefficiency affects speed, consistency, and the team’s ability to scale service delivery.
My discovery process started with understanding how onboarding was actually happening in practice, not just how it was expected to happen on paper.
That meant reviewing the existing workflow, identifying where information gaps appeared, and looking closely at moments that slowed the team down.
I also worked through stakeholder discussions with the founder and collaborated with engineers to understand what was technically possible, what had already been built, and where the experience was breaking down.
A clear pattern emerged. The issue was not isolated bugs or missing fields. The onboarding journey itself needed better structure.
That insight shifted the direction of the work. Instead of treating onboarding as an admin task, we approached it as a product experience that needed to be intentionally designed.
Several constraints shaped the work.
First, this was a startup environment, which meant priorities could shift quickly and engineering capacity had to be used carefully. Any improvement had to be practical, focused, and realistic to implement.
There was also the challenge of building while still learning. The workflow was being improved in real time, so product decisions had to balance immediate operational needs with longer-term usability.
The onboarding flow needed to be structured enough to reduce gaps, but flexible enough to handle variation between different clients.
These constraints pushed the team toward incremental improvements instead of overbuilding too early.
One key decision was to prioritise structure before complexity.
Rather than introducing too many advanced features, I focused on making the onboarding flow clearer, more intuitive, and more useful for both clients and the internal team.
I also focused on identifying where incomplete information or unclear steps were creating downstream inefficiencies. This helped shape decisions around what needed to be captured earlier, what needed better guidance, and how the workflow could reduce unnecessary back and forth.
Not every issue needed a new feature. In several cases, the better solution was simply a clearer sequence, cleaner flow, or stronger guidance.
Throughout the project, I collaborated with engineers during development and tested functionality as prototypes became available. That helped surface issues earlier and gave the team a better sense of where the experience still felt unclear or inefficient.
The result was a more structured onboarding experience that better supported how the company collected information and moved clients into delivery.
The workflow became clearer, easier to test, and more aligned with the actual needs of the business.
The improvements helped reduce friction in onboarding, made inefficiencies easier to spot, and supported a more organised internal handoff between client intake and execution.
Even without a flashy new feature, the product work created operational value by making the process more repeatable and easier to run well.
It also helped shift the company toward more deliberate product thinking instead of relying only on reactive fixes.
This project taught me that some of the most valuable product work is not always flashy.
Sometimes the biggest win is reducing friction, improving clarity, and making the business run more smoothly behind the scenes.
I also learned the importance of observing how workflows actually behave rather than relying on assumptions. A process can look fine at a surface level while still creating hidden inefficiencies for users and teams.
Working in a startup environment also strengthened my ability to balance ambition with practicality. Not every problem needs a huge solution. Sometimes the strongest decision is the one that makes the experience clearer, leaner, and easier to execute well.
Overall, this experience strengthened my confidence in translating messy operational problems into clearer product opportunities.
ClearPath is a citizen-first web platform designed to simplify access to social services while aligning with UK Government Digital Service standards.
The product was created to replace outdated, PDF-heavy application journeys with a more accessible, mobile-friendly, and human-centred experience.
Many public service application processes are still difficult to navigate, especially for people already dealing with financial stress, low digital confidence, or urgent personal circumstances.
The goal was not just to digitise a paper process. It was to redesign the service around the real needs of the people using it.
ClearPath supports citizens through guided step-by-step flows, clearer eligibility checks, real-time feedback, and progress visibility, while also supporting staff who need to assist with more complex cases.
ClearPath reimagines the social services application journey as a guided digital experience rather than a static form.
Instead of asking users to download, complete, and submit complex PDFs, the platform walks them through a structured process that is easier to follow and easier to complete correctly.
The experience begins with a lightweight eligibility checker that helps citizens quickly understand whether they may qualify before spending time on a full application.
From there, users move through accessible GDS-compliant form steps supported by plain language guidance, inline validation, and contextual help.
The experience was designed to feel clearer, faster, and more reassuring for people who often need confidence as much as they need functionality.
Once submitted, users can track their application status and receive updates through SMS or email notifications. A separate staff mode allows support teams to review entries, make updates where appropriate, and respond more effectively to citizen queries.
Legacy application processes for social services often rely on PDF forms and fragmented communication.
These journeys are typically hard to complete on mobile, difficult to understand, and prone to user error.
For citizens, this can mean confusion, repeated mistakes, incomplete submissions, and delays in accessing support.
For service teams, it creates avoidable pressure through higher support call volumes, manual correction work, and slower case handling.
When public services are structured around forms instead of people, users are forced to carry the burden of complexity.
The core challenge behind ClearPath was to create a digital experience that made access to services clearer and more manageable while still meeting operational and compliance requirements.
The discovery phase focused on understanding the barriers citizens face when applying for social services and the operational strain these systems create for support teams.
I approached the problem through a service design lens, looking at both the citizen journey and the staff experience behind it.
A major influence on the product direction was the UK Government Digital Service framework, particularly its emphasis on accessibility, simplicity, assisted digital support, and designing around user needs rather than organisational convenience.
Many of the problems associated with public service applications come from preventable friction, not unwilling users.
Users are often willing to complete the process, but the process itself can feel difficult to interpret, difficult to trust, and difficult to recover from when mistakes happen.
That insight shaped the direction of the product. Instead of digitising every part of the legacy workflow exactly as it existed, the focus shifted toward simplifying the experience at each stage and reducing avoidable failure points.
Designing for public services introduced several important constraints.
First, the product needed to align with GDS principles, which meant prioritising accessibility, clarity, inclusivity, and consistency across the experience.
Another key constraint was the diversity of users. The platform had to work for people with low digital confidence, limited access to high-end devices, or additional accessibility needs.
This influenced everything from language and layout to responsiveness and error handling.
The challenge was not designing for an ideal user. It was designing for people under pressure, on imperfect devices, in imperfect situations.
There were also operational constraints. Public services still require internal visibility and staff support, so the platform needed to serve both external users and internal teams without becoming overly complicated.
These constraints pushed the product toward a lean, practical solution focused on usability, trust, and service efficiency rather than unnecessary feature complexity.
One of the biggest product decisions was to move away from a document-first experience and design around guided user flows instead.
This changed the interaction from completing a form in isolation to being supported through a step-by-step service journey.
I also prioritised a lightweight eligibility checker early in the experience. This was important because it gives users quick clarity before they invest time in a full application and reduces avoidable drop-off caused by uncertainty.
Real-time validation and help text were included to reduce submission errors at the point where they happen, rather than leaving users to discover problems later.
Mobile optimisation was treated as a core requirement, not a later enhancement.
Many users access services through phones, often on lower-end devices, so the experience needed to be responsive and lightweight from the start.
Finally, I included both a citizen-facing journey and a staff mode because a strong service product has to support the full system, not just one side of it.
ClearPath resulted in a service concept that transforms a fragmented, PDF-led process into a clearer and more supportive digital journey.
The platform demonstrates how public services can be made easier to access without losing the structure and accountability required by government systems.
The proposed experience reduces friction for citizens by improving clarity, supporting self-service, and making application progress more visible.
At the same time, it creates operational value by reducing preventable errors, lowering avoidable support demand, and helping staff respond more effectively.
When users feel guided rather than overwhelmed, the service becomes more humane and more effective.
More broadly, the project shows how product thinking and service design can improve trust in public services.
This project strengthened my understanding of how product management overlaps with service design, especially in public sector contexts where the challenge is often not a lack of functionality but a lack of clarity.
Accessibility is not a side consideration. It is a core product decision that shapes whether people can actually use a service when they need it most.
It also reinforced that good digital services do more than move forms online. They reduce uncertainty, support people through decisions, and make complex systems feel more manageable.
Overall, ClearPath sharpened my ability to think about products not just as interfaces, but as end-to-end experiences that affect real people in high-stakes moments.
The Lab
Smaller experiments and prototypes I've built to explore ideas, test a hypothesis, or simply satisfy curiosity.
Writing
I write about product, systems, and the messy reality of building things that actually work. Click any piece to read more.
Notes
Short observations, fragments, and thoughts I keep returning to. Just me thinking out loud.
Contact
Whether it's a role, a collaboration, or simply a conversation about product, I'd love to hear from you.
The best way to reach me is by email. I usually reply within a few days. If you're reaching out about a role or opportunity, a little context helps me respond more thoughtfully.