I've been building customer-facing products for seven years now. From the Test Creation Experience used across 1.9M+ tests at HackerRank to GPT-4o powered features in production, I've seen what separates products that stick from those that get shelved after three months of development.
Here's what I've learned: the only limitation in the AI era is product thinking.
The AI Acceleration Problem
Everyone's talking about AI making us 10x faster. Write a prompt, get a component. Describe a feature, get working code. The demos are compelling. The productivity gains are real.
But here's what nobody's talking about: speed without direction is just expensive motion.
I see engineers shipping faster than ever and wondering why their features don't land. They can build anything now. The question they can't answer is: what should I build? 🤔
That gap is product engineering.
What Product Engineering Actually Means
Product engineering isn't about choosing React over Vue. It's not about microservices architecture or deployment pipelines.
Product engineering is building with the user's problem as your north star, not the technology.
Back in 2023, I was discussing my promotion with my manager at HackerRank. Around the same time, I stumbled upon Gergely Orosz's The Product-Minded Software Engineer on The Pragmatic Engineer blog. Reading it felt like someone had written down exactly what I do. Every trait he described, from proactive product ideas to end-to-end feature ownership, mapped to how I have been working for years. That article became my pitch for the promotion. I've never been the strongest "pure coder" in the room, but I've always been a solid product engineer. That's what sets me apart 💪 There is another book on this, The Product-Minded Engineer (November 2025) by Drew Hoskins, and it reinforces the same core truth: the engineers who have the most impact are the ones who care deeply about the product, not just the code.
When we built the Test Creation Experience at HackerRank, the engineering challenge wasn't the hardest part. The hard part was understanding that recruiters weren't failing to create tests because our UI was clunky. They were failing because they didn't know what good technical questions looked like in the first place.
The feature that moved the needle wasn't better form validation. It was a question recommendation engine that suggested problems based on the role they were hiring for.
Product engineering is seeing the gap between what users say they want and what they actually need.
For the longer career arc behind that idea, see seven years as a software engineer. For shipping under a brutal clock with a product-shaped goal.
Why AI Makes This More Critical, Not Less
In 2019, if you wanted to build a feature, you needed to:
- Design the database schema
- Write the API endpoints
- Build the frontend components
- Handle edge cases and error states
- Deploy and monitor
That took weeks. The friction forced you to think: is this worth building?
In 2026, I can describe a feature to Claude and have working code in 20 minutes. The friction is gone. The forcing function for good judgment disappeared. 🫠
Now anyone can build anything. The engineers who survive aren't the ones who can prompt better. They're the ones who know what's worth building.
The Obsession With "Great Engineering"
I've worked with brilliant engineers who could optimize a database query from 200ms to 15ms, architect systems that handle millions of requests, and debug race conditions in distributed systems.
Some of them built features nobody used. 😅
The ones who had impact? They started every conversation with: "What problem are we solving, and for whom?"
They asked questions like:
- Who specifically has this problem?
- How do they solve it today?
- What would make them change their workflow?
- How do we know if we fixed it?
Those questions matter more than knowing the latest JavaScript framework.
My Product Engineering Principles
After seven years and dozens of shipped features, here's what I've learned:
1. Fall in love with the problem, not your solution.
I've killed features I spent months building because user research showed we were solving the wrong problem. It hurt. But shipping the wrong thing perfectly is worse than not shipping at all.
2. Build for one person first.
Every successful feature I've shipped started with understanding one specific user's workflow in detail. Generic "user personas" don't build products. Real humans with real problems do.
3. The best code is code you don't write.
Before building anything, ask: what's the simplest thing that could work? Half the features I thought I needed to build turned out to be configuration changes.
4. Measure behavior, not opinions.
Users will tell you they want feature X. Then you build feature X and nobody uses it. Watch what they do, not what they say they'll do.
The AI Era Divide
I predict a split in our industry:
AI-Assisted Code Writers: Fast at implementation, focused on technical craft. They can build anything you spec out.
Product Engineers: Focused on what to build and why. They use AI as a tool to ship faster, but they're solving the right problems.
Both roles matter. But if you're building customer-facing products, you need to be in the second category.
The companies that win in the AI era won't be the ones with the best AI engineers. They'll be the ones with the best product engineers who happen to use AI. 🚀
What I'd Do Differently
If I were starting my career today, I wouldn't spend time learning every new framework or AI tool that comes out.
I'd spend time with users. I'd sit in customer support calls. I'd read every piece of feedback. I'd understand how people actually work, not how I think they should work.
The frameworks change every two years. Understanding humans compounds forever.
Product engineering isn't a nice-to-have anymore. In the AI era, it's how you stay relevant.
The future belongs to engineers who can think like builders, not just coders. AI will handle the coding part. The building part still needs humans. ✨
Originally published at souravdey.space.
