Website:
theproducthighway.com
Job details:
The Product Highway is an AI-native product strategy and engineering firm helping businesses go from idea to enterprise scale. We grew to multi-million ARR in our first year, working across India, APAC, Europe, and North America.
While AI has transformed how software is built, the real challenge—deciding what to build and why, remains. That’s our focus. We design solutions that reflect real business needs, customer behavior, and value creation.
AI isn’t just a feature for us. It’s how we think, build, and deliver.
Why we're hiring
Most engineering teams need a PM to tell them what to build and an engineer to build it. We need people who can do both. Someone who looks at a client's business problem, figures out what the product should do, and then builds it. No handoff, no lost-in-translation, no waiting for a spec.
This is the person who sits in on a client call, hears "we need our users to do X," and by the end of the week has a working version that solves the actual problem — which is often different from what was literally asked for. You have the product instinct to know what matters, the technical skill to build it properly, and the judgment to know when good enough is good enough and when it isn't.
At TPH, we run small teams on fast timelines. We don't have the luxury of a 6-person squad with a PM, a tech lead, two engineers, and a QA. We have 2–3 people who are each capable of carrying more weight than a traditional role would ask of them. The Product Engineer is the core of that model. You're the person who makes a small team feel like a big one.
You'll be embedded in a client engagement end-to-end. One engagement you're building a consumer app from scratch. The next, you're rearchitecting a legacy system. The constant is depth — you carry the full context of the product you're building, and you own both the product thinking and the engineering execution.
Who we're looking for
Regardless of role, every person at TPH shares these traits:
- End-to-end owners. You own outcomes, not tasks. If something you're responsible for falls through a crack, that's on you, because bugs are easier to fix, misalignment is expensive.
- Clear, direct communicators. Bad news doesn't get better with age. You surface problems early and communicate with precision.
- Uncompromising on quality. You have a quality bar that's yours, not your manager's. You won't ship something you wouldn't stand behind, even under deadline pressure.
- AI-obsessed. You see AI as how work gets done, not a nice-to-have. If you're still doing something manually that AI could handle, you feel that as friction, not normalcy.
- Structured thinkers. When faced with an ambiguous problem, you break it down, reason through the trade-offs, and arrive at a position. You don't wait for someone to tell you the answer.
What you'll own
Product Thinking & Decision-Making
- Look at a business problem and decide what the software should do. You don't wait for a PRD. You talk to the client, understand the context, and form a view on what the product needs to be.
- Make product trade-offs on the fly. What do we build first? What do we cut? What's the smallest thing we can ship that validates the assumption? These are your calls, made with conviction and communicated clearly.
- Push back when something doesn't make sense. If a client asks for a feature that won't solve their actual problem, you say so. If a PM suggests a scope that's architecturally wasteful, you offer the better path.
- Think about the user, not just the ticket. You consider edge cases, empty states, error handling, and the experience of actually using what you build. You ship products, not features.
Engineering Execution
- Write production-grade code. You build things that work under real load, handle failure gracefully, and don't need to be rewritten in three months. Your code is clean, well-structured, and maintainable.
- Work across the stack as needed. You have depth in one area and enough range to be dangerous everywhere else. Frontend, backend, infrastructure — you go where the problem is.
- Make architecture decisions at the project level. You choose the right tools, the right patterns, and the right level of complexity for the problem at hand. You don't over-engineer, and you don't cut corners that will cost the team later.
- Ship fast. You use AI tools (Cursor, Claude, Copilot) to move at a pace that would have been impossible two years ago. You're not just writing code faster — you're using AI to think through problems, generate test cases, and explore solutions you wouldn't have considered.
Client Context & Collaboration
- Sit in client conversations and understand what they actually need. You don't need someone to translate business requirements into technical language for you. You speak both.
- Communicate what you're building and why, in terms the client and the team can follow. You write clear updates, explain trade-offs without jargon, and keep people aligned without waiting for a standup.
- Collaborate with the PM (when there is one) and the designer as peers. You're not taking orders. You're contributing to product decisions because you understand the technical implications better than anyone else in the room.
- Work with other engineers on the team, review their code, and set the technical direction on your engagement. You make the people around you better.
Must-haves
- 5–7 years of professional software engineering. You've built products that real people use, and you can talk about the decisions you made and why.
- You've shipped products where you owned the product decisions, not just the code. You've decided what to build, scoped it, built it, and stood behind it.
- Strong across the stack. You have real depth in at least one area (backend, frontend, mobile, or infrastructure) and working fluency in the rest. You pick up new frameworks and languages quickly because you understand the fundamentals underneath.
- You can talk to a client about their business problem and translate it into a technical approach without needing a translator. You're comfortable in rooms with non-technical stakeholders.
- You've worked in fast-paced environments where scope changed, timelines were tight, and you had to make judgment calls without perfect information.
- You write code that other engineers can read, extend, and trust. You care about code quality because you've been burned by the alternative.
- You use AI tools daily in your engineering workflow. Cursor, Claude, Copilot — these are part of how you work, and you're measurably faster and better because of it.
Strong signals
- You've worked at a startup or a small team where you were the person who figured out what to build and then built it. No PM, no detailed specs, just a problem and a deadline.
- Experience across multiple domains — you've built a fintech product, then a healthcare platform, then a consumer app. You adapt your approach to the domain rather than applying one playbook everywhere.
- You've worked in a consulting or services environment where you shipped products for different clients and had to ramp up on new business contexts quickly.
- Background in AI/ML engineering or significant experience integrating AI capabilities into products. You understand LLMs, embeddings, RAG architectures, and how to build AI-powered features that actually work in production.
- You've mentored or led other engineers informally. People come to you for code reviews, architecture advice, and product input because they trust your judgment.
- You've worked with React Native, Flutter, or similar cross-platform frameworks and understand the trade-offs of cross-platform vs. native development.
AI-native expectations
- AI tools are embedded in your daily workflow. You use them for writing code, debugging, writing tests, exploring architectures, and prototyping features. You're not experimenting with AI — you've already integrated it.
- You can evaluate AI-generated code critically. You know when it's production-ready, when it needs refinement, and when it's confidently wrong. You direct AI rather than blindly accepting its output.
- You think about how AI changes what's possible in a product. When scoping a feature, you consider whether an LLM, a classifier, or a pipeline could solve the problem better or faster than hand-coded logic.
- You're comfortable building AI-powered features — integrating APIs, managing prompts, handling model outputs, building evaluation and feedback loops.
Not the right fit if
- You need a PM to tell you what to build. At TPH, the Product Engineer is often the person making those calls. If you're uncomfortable deciding what the product should do, this role will frustrate you.
- You only want to write code. This role requires you to think about the product, talk to clients, and make decisions that go beyond the technical layer. If you want to stay heads-down in an IDE all day, this isn't it.
- You've only ever worked on one product at one company. TPH engineers move between engagements as projects evolve. You need to ramp up fast on new codebases, new domains, and new client contexts.
- You build things the "right" way regardless of context. Sometimes a quick solution is the right solution. If you can't ship a v1 without a microservices architecture, you'll clash with how we work.
- You don't use AI tools in your engineering workflow today. This isn't a place where you'll learn to use AI on the job — it's a place where AI fluency is a baseline expectation on day one.
- You're uncomfortable with ambiguity. Some engagements start with a vague brief and a client who doesn't fully know what they want. If that sounds like a nightmare instead of a challenge, this isn't the right environment.
How to apply
Please fill out this short form to be considered for the role: https://forms.gle/NVz5Zyuq1vMHnhos8
Click on Apply to know more.