Product Engineering Teaches You the Business, Not Just the Code

Two Kinds of Knowledge at Once

Product engineering asks for two kinds of knowledge at the same time. The technical side is the one everyone expects: languages, frameworks, databases, tests. The other side is the domain: how the business works, what it measures, which rules it has to follow, and who depends on the numbers being right.

The two feed each other. You can't build a good feature in a domain you don't understand, and building the feature is the fastest way to learn the domain.

I'm about 5 months into my internship at Kairalitrails, and I understand how product engineering works much better than when I started. It goes beyond the technical side. I've picked up the domain knowledge too: how the travel business runs, and along the way parts of Indian tax law. GMV, credit notes and invoice sequencing didn't come from a finance course. They came from working on features and bug fixes for a travel product.

The Ticket

Here is how it happened. A ticket asked that a trip which had already departed could still convert into a booking if money had been paid on it, so the money could be refunded through that booking. It looked like a small rule.

To build it properly, I had to ask what that booking would do downstream, and every answer was a term I didn't know yet.

What Tracing It Taught Me

A metric is a definition, not a number. GMV, gross merchandise value, is the total value of what is sold through a platform in a period, counted before refunds, cancellations and fees. It is easy to confuse with revenue. If a customer books a trip worth ₹1,00,000, GMV can count the full amount while the company keeps only a fraction of it. Whether a later refund reduces GMV depends on how the company defines it. Here, it is the sales number the team is measured on, and it doesn't come down when a refund happens. So a booking created only to be refunded would sit in it permanently, for a trip that never ran.

Invoice numbers are not just IDs. Converting a quote into a booking creates a real tax invoice. Under GST, invoices are numbered in one unbroken sequence within a financial year (April to March in India), and a number can't be reused or quietly deleted. The tax split also depends on where the sale happens: CGST plus SGST inside a state, IGST across states.

A refund is more than money going back. Once an invoice exists, the tax on it has already been reported, so deleting the invoice isn't an option. You issue a credit note, a document that reduces the value of the original invoice, and the tax adjusts with it. Credit notes also have a legal window tied to the financial year-end. Miss it and the customer can still get their money back, but the tax already paid on that sale can't be adjusted, so the business absorbs it.

One line in a ticket touched tax, metrics and refunds at once. None of it was visible from the code alone.

How It Changed the Way I Work

• I ask "what rule does this touch?" before I write code. Often the answer is a metric, a tax rule or an operations policy, and one of those decides what "correct" means.
• I write the rule in plain words first. If I can't explain it in two sentences, I don't understand it yet.
• I make every surface agree. The button, the banner, the filter and the server check have to follow one rule. A page that offers something the server then refuses is a bug, however tidy the code is.
• I ask for the "why". A requirement that changes is usually a rule I didn't know about yet.

It Reaches Beyond Travel

What I value most is how far this reaches. Invoicing rules, credit notes and the way a metric gets defined show up in almost any business that sells something, so what I learned on a travel product is useful well beyond travel.

Still Learning

I joined Kairalitrails as a Full Stack Developer Intern in Product Engineering. Building real features across the ERP and the customer platform has helped me become a better engineer, and a better product engineer too. The first is about cleaner designs and checks that fail when a rule is broken. The second is seeing that requirements come from a business with metrics to protect, laws to follow and people who depend on the numbers.

I'm still learning more with every feature. Thank you to the team for explaining the why, not just handing out tickets.