How to work with Product: At the tea table

The most impactful, and delightful work I’ve done as an engineer, has been on projects where I’ve had a great relationship with the product manager(s). Poorer the relationship, poorer the impact and experience.

This relationship between people represents the relationship between problem and solution. In real life, problems and solutions evolve together. Each one affects the other. Similarly, the people need to grow a meaningful relationship together. They need to listen empathically, understand needs, comprehend each others’ writing, create artefacts together, communicate well, and have fun solving problems together.

Since I’ve predominantly played the engineering role, I’m writing to other engineers based on that experience. This series of posts details when and how engineering can work with product to create the synergy that powers wonderful products.

We reflect on our problems over tea. Or coffee. Or sutta, if you’re into that. A casual conversation that’s not bound by the colder confines of an office or work space, where we’re calm, set to truly listen and receive. Courageously vulnerable with our true thoughts and ideas. Reflection provides fertile ground for germination of ideas. It’s in this mental-space that people often understand, empathise, and find camaraderie. These are flaps of the butterfly wings, or rolls of that snowball of building product as a team.

When someone who knows the problem very well is speaking about it, even casually, lean in. Listen empathically. Diagnose, before you can prescribe. Once you have a deep enough understanding of the problem, and the needs of the people therein, then you can start thinking about how to be valuable with your engineering skills.

Following this are some autobiographical experiences. Read, and be inspired! Yeah, no, I’m just trying to illustrate what I mean, drawing from my experiences. If you don’t want to read my life stories, just skip to the list at the end.

It’s in this kind of tea-table space that we found the courage to say “screw it, lets go offline first”, with our initial efforts at simple.org. Daniel had spent months in the field with nurses, and in talking to true experts, understanding the problems of treating hypertension in public health. He then expressed to us, the engineering team, a deep need for nurses in rural areas to be independent of internet needs. We understood that need, and decided it’s worth a try with a “how hard can it be” attitude. After some 6 years, we still see that as one of the most important decisions to make the product successful, and truly useful to thousands of health care workers and millions of patients.

After a hearty lunch one day on the nilenso terrace, we were talking about how we need better mechanisms to validate ideas with nurses in the field. [Dhruv](https://x.com/_droov) said *“Ideally, I just want to be a fly on the wall, and observe the nurse use the app with real patients”*. Prototypes didn’t cut it, and user-research questions were based on possibilities that weren’t easy to communicate. I suggested building a separate app that we can use to [run experiments quickly](https://www.youtube.com/watch?v=1FqOF9P0nEY) in the field. This would normally take months with a small team (it was 2018), but I had built prototype-apps quickly before, and could confidently say *“Give me a couple of weeks, no one else needs to be involved and their work can continue”*. That was a small enough risk the leadership could take, and it paid off. We iterated on scanning UUIDs of various densities using low-spec phones, various error feedback mechanisms, and a custom number keypad for entering blood pressures, tried all these out with nurses in the field, and then built them into the actual app.

When I was working at [GoFood](https://gofood.co.id/en), we were out for dinner in Jakarta when I noticed [Hareesh](https://www.linkedin.com/in/hareeshwar-g-86240712/) kept returning to what seemed like a small issue: customers accidentally placing orders and immediately cancelling them. It didn’t look urgent, but it was quietly blocking a major release: restaurants that auto-accepted orders the moment they were placed. He never said this directly, but his fixation was the signal. I asked, *“How does Zomato do this?”*, and when we checked their app, we found a straightforward pattern—a 10-second confirmation timer and a clear message about non-cancellable orders. Because the app already had all the information needed to decide when to show that timer, I could confidently say, *“This can be an app-only change; we can ship it in a few days.”* The engineering work was trivial. Identifying that it was a blocker and needed a quick solve was the real contribution.

While working at a logistics firm recently, we had spent more than a month wrestling with the onboarding journeys for new partners. It was a legacy system where every bug fix spawned new ones, and understanding the possible solutions was even more painful than understanding the problems. Our competitors could onboard new partners in hours while we took days, and the decade-old architecture simply wasn’t letting the product evolve. One evening, after venting about all this with the head of product, I asked him, *“If we were to re-implement the entire onboarding flow from scratch, what would you do?”*, and it turned out he had been thinking the same thing but couldn’t voice it unprompted. It was too big and too costly a leap to suggest outright. That question unlocked the real conversation: by the end of it, we had enough product clarity and engineering rationale to justify a half-year rewrite.

I’ve tried to break down my instincts from such experiences at the ideation phase, to what I might tell another fellow engineer:

• Seek first to understand. Listen to the users. Listen to subject matter experts. Listen to people who understand the problems and product very well. Pay attention to emotional cues and subtext. They often point to deeper problems than any ticket or spec reveals. Create casual and trust-heavy settings intentionally, where conversations can surface such problems.
• Be involved early. The early conversations of ideation, direction setting, and strategising are pivotal in building products, and engineering insight is very valuable in these conversations. Usually engineering is only involved in later stages.
• Find cheap ways to prove hypotheses. What’s the thinnest slice of cake we can serve to customers? Can we scrounge up some analytics that can make the case? What’s the simplest experiment we can run? Should we build a PoC, or fire a tracing bullet that tells us how expensive this is going to be?
• Don’t wait for product to propose solutions. You can introduce new solution spaces as engineers that product might not even know exist. Don’t be afraid to push boundaries to make meaningful progress.
• Create space for unsaid ideas. PMs often have solutions or directions in mind, but don’t voice it because they feel too big, risky, or premature. As engineers, you can unlock strategies by asking questions that give them permission to speak openly about the real problem or the bold solution they’re thinking about.
• Build feasibility intuition: It is your responsibility to bucket ideas on the spectrum of a pipe-dream to practical to trivial. If the product manager is informed on which things take hours, days, weeks, months, they can make much more reasonable decisions than otherwise. If you don’t know enough to make that kind of call, learn, and build that capability. Be resourceful, have trustworthy sources, look at prior art or competitors, and then form your own opinion and share it with product.
• Surface system constraints: Talk to product about things that are generally considered engineering territory, like missing abstractions, why integration with some third-party is slow and buggy, why adding another workflow is complex, etc. This transparency builds empathy, and trust. When you surface these constraints, they can proactively reorient product strategy to account for them. Or perhaps give room to solve for those constraints.