2/9/25: 'Embedding' as a form of Empathy.
As Taleemabad has evolved from a startup into a more established organisation, I've been haunted by a nagging question: are we becoming insulated from the very people we hope to serve?
It's probably not intentional. It never is. But as we've grown, layers have formed between us and our users - layers of processes, assumptions, and comfortable office routines. This distance becomes even more concerning as we expand to serve new customers like PSRP schools and government schools in Punjab. The responsibility to truly understand our users' needs has never been greater.
So we decided to do something radical: stop imagining their challenges and start living them.
Day One: From Leadership Team to Field Helpers
At 9:30 AM, after a two-hour drive from Islamabad, Mashhood and I arrived at the Moawin field office in Jhand. The office was barebones, with two rooms and three people — yet the weight it carried was substantial: it was responsible for the oversight of over 126 privatized government schools in a ~100km radius.
The field office had been told they were getting "helpers", nothing more. No titles, no special treatment. Within minutes of arrival, we were thrown into the deep end of their daily chaos.
The Punjab government had sent out a form requiring teachers and cluster coordinators to report flood damage to their schools. Simple enough, right? Wrong.
When Good Intentions Meet Poor Design
The government form had a fundamental flaw: it only allowed schools to confirm flood damage and specify reopening dates. But what if your school hadn't been flooded? Most schools in Jhand hadn't been affected, yet teachers were forced to fill out reopening dates for schools that never closed.
By the time we discovered this design disaster, countless teachers had already submitted confused, inaccurate responses. We watched as frustration rippled through the network, from field coordinators to cluster coordinators to teachers. This wasn't just bad UX; it was hours of wasted time multiplied across hundreds of schools.
The Photo Request Avalanche
Then came request number two: Someone higher up the chain wanted photographic proof of student attendance. Not just any photos—specific ones showing students in front of their schools holding their EMIS codes.
First, we had to create a sample image showing exactly what the Punjab government wanted. Then build a form. Then distribute it via WhatsApp to all teachers. The deadline? Two hours.
Many cluster coordinators were away or overwhelmed with other tasks. WhatsApp messages got buried under the daily flood of communication. So we built a quick automation—reminders every five minutes to those who hadn't submitted. The pressure was palpable, but the clock was ticking.
In the middle of all of this, another issue arose.
Three schools had developed technical flaws, either with solar panels or with water coolers.
The problem? The nearest electrician was hours away and would charge money to come and check. But the system would only approve requests when the total cost of the repair was estimated. I tried to reason on the phone with the electrician. Could we get pictures of the damage to him so he could estimate the costs?
He refused.
All this while, Mashhood had to get facility data (walls/washrooms/chairs/tables) from 28 schools, but several schools were off-grid and were unreachable.
Just when we thought we'd seen it all, another request arrived. To comply with Dengue prevention protocols, teachers had to:
Take a photo of a dirty area in their school
Upload it to the Punjab SIS platform
Wait five minutes
Clean the area
Take another photo of the now-clean space
Upload again
This wasn't just about cleanliness; it was a convoluted way to verify teacher presence and compliance. The absurdity wasn't lost on us, but we weren't there to judge. We were there to experience.
As requests multiplied and chaos mounted, we realised even we (two presumably ‘tech-savvy’ individuals) couldn't keep track of all the sequential tasks. Mashhood started building a CRM system on the spot, showing the field coordinator each iteration as he coded. I worked on a WhatsApp bot to automate reminders and track task completion.
We weren't building in a conference room based on user interviews. We were building while drowning in the same floods of requests our users face daily.
Watching the flow of these data requests revealed the true pain architecture of the system:
Punjab Government → Moawin Headquarters → Field Team → Cluster Coordinators → Teachers
Each layer amplifies the pressure. Each layer adds confusion. And at the bottom, teachers who are already overwhelmed with actual teaching bear the accumulated weight of every poorly designed form and arbitrary request from above.
Living someone else's life means you can't cherry-pick which parts to experience. When that Moawin coordinator couldn't question why a data request seemed pointless, neither could we. When they had to comply with strange requirements, so did we. We couldn't retreat to our comfortable assumptions about what users "really need."
We learned that even while moving fast, we can't solve every pain point simultaneously. We'll start with the field team's challenges, then tackle cluster coordinators' problems, and eventually address teachers' burdens. It's sequential — sometimes frustratingly slow, but it's real.
One day, if done long enough, all of these tiny builds will become an OS that can solve the pain of running one of the world’s largest network of schools.
Over the coming weeks, we'll return to the field repeatedly. We'll work with cluster coordinators, then teachers, experiencing each layer of this complex system. We're not observing from the outside anymore - we're living it from the inside.
This approach has already changed how we think about product development. The gap between our assumptions and reality was wider than we'd imagined. But now we know. Not because someone told us in a focus group, but because we spent a day chasing down WhatsApp messages, building hacky solutions, and feeling the genuine frustration of serving multiple masters with conflicting demands.
The only way to solve real problems is to experience them, day in and day out.
We can't truly serve our users from the comfort of our offices. We need to stand where they stand, struggle with what they struggle with, and feel the weight of the systems they navigate daily. Only then can we build solutions that actually matter.
This is just day one of our journey into our users' reality. The road ahead is long, but if we’re building in this way, I’m confident that we’ll never veer off track.
Taleemabad/Orenda returns to its roots, Godspeed!
"The only way to solve real problems is to experience them, day in and day out"
Journey from hypothesis to implementation ❤️❤️