You’ve just finished building a beautiful custom Lightning component. The code is clean, the architecture is solid, and it follows all the best practices you’ve learned. But when you demo it to the business stakeholders, their response is lukewarm at best. “It’s nice, but this isn’t really what we needed.”
Sound familiar?
As a Salesforce developer, you’re incredibly skilled at solving technical problems. But here’s the thing that took me years to learn: the best developers don’t just write great code, they solve the right problems in the first place.
After a couple of decades of building on the Salesforce platform and working alongside countless product managers (and as one), I’ve discovered that the developers who advance fastest in their careers are those who think beyond the technical requirements. They think like product managers.
From “How” to “Why”
Let me tell you about a mistake I made early in my career. I was asked to build a custom approval process for opportunity discounts. I spent weeks crafting this elegant workflow with multiple approval layers, automatic escalations, and detailed audit trails. I was proud of the technical complexity.
The business hated it.
Why? Because I built what was asked for, not what was needed. The real problem wasn’t creating a complex approval process, it was helping sales reps get quick answers on discount requests so they could close deals faster.
This is the fundamental difference between developer thinking and product thinking. Developers ask “How can I build this feature?” Product managers ask “Why does this feature need to exist, and what problem does it solve?”
User Stories That Actually Matter
You’ve probably written user stories before: “As a sales rep, I want to request discounts so that I can close deals.” But product managers dig deeper. They want to know the user’s emotional state. Are they frustrated? Rushed? Confused? What’s the business context? Is this rep about to miss their quota? What happens after the approval?
Here’s how I learned to rewrite that user story:
“As a sales rep in the final week of the quarter, I’m stressed about hitting my number. I need to quickly understand what discount level I can offer without approval, and if I need approval, I want to know exactly what information to provide and how long it will take, so I can confidently negotiate with my prospect without looking incompetent.”
See the difference? This story tells me that the solution isn’t just about building an approval process, it’s about reducing anxiety and building confidence.
Problems != Not Features
Product managers are obsessed with problems. They know that features are just potential solutions, and there are usually multiple ways to solve any problem.
Let’s say you’re asked to build a dashboard showing “all opportunity data.” Instead of jumping straight into SOQL queries and chart components, start asking questions. What decision is this dashboard supposed to help someone make? What specific action should they take after viewing it? What happens if they can’t access this information?
Back in my consulting days, I discovered that a “comprehensive opportunity dashboard” request was actually about helping a sales director quickly identify which reps needed coaching. The solution wasn’t a complex dashboard, it was a simple alert system that flagged concerning patterns.
No is OK
Product managers live in a world of infinite requests and finite resources. They’ve mastered the art of saying “no” to good ideas so they can say “yes” to great ones.
As a developer, you can apply this same thinking to your technical decisions. Instead of asking “Should I build this custom component or use an existing one?” ask yourself, “What’s the minimum viable solution that solves the core problem?” Instead of “How can I make this code more elegant?” ask “What’s the simplest implementation that delivers user value?”
Becoming a Translator
One of the most valuable skills I’ve developed is translating between technical possibilities and business value. Product managers do this constantly, and it’s incredibly useful for developers too.
When a business user asks for a “real-time sync between Salesforce and our ERP,” don’t just think about APIs and integration patterns. Think about what “real-time” actually means to them. Are they worried about inventory accuracy? Do they need to make faster decisions? Are they tired of manual data entry?
Once you understand the underlying need, you can propose solutions that they may never have considered. Maybe the answer isn’t real-time sync, maybe it’s a smart notification system that alerts them to important changes.
Different Metrics Matter
Developers love metrics: code coverage, performance benchmarks, error rates. Product managers love different metrics: user engagement, task completion rates, time-to-value.
Start tracking product metrics for your services. How often do users actually use the feature you built? How long does it take them to complete their task? What do they do immediately after using your feature?
I built a custom quoting tool that had perfect technical performance but terrible user adoption. By tracking user behavior (not just system performance), I discovered that users were confused by the interface, not frustrated by speed. The fix was UX design, not code optimization.
Better Communication
Product managers spend half their time communicating. They know that the best solution in the world is useless if people don’t understand it, adopt it, or use it correctly.
Instead of saying “I implemented a trigger that validates data integrity across related objects,” try “now when sales reps create opportunities, the system automatically prevents the data inconsistencies that were causing problems in your forecasting reports.”
Instead of “The batch job processes records more efficiently,” say “your monthly commission calculations that used to take 6 hours now finish in 30 minutes, so your team gets paid faster. You are welcome.”
It’s the same technical work, but framed in terms of business value.
Start Small
You don’t need to become a product manager overnight. Start by incorporating one product-thinking habit into your daily work.
This week, before you open VSCode, write down the user problem you’re solving and the success criteria. Next week, ask one “why” question in every requirements meeting. This month, track one user-focused metric for something you’ve built.
Why This Matters for Your Career
Again, what I’ve observed: developers who think like product managers become the ones everyone wants to work with. They build solutions that stick. They get invited to strategy meetings. They become technical leads, solution architects, and yes, sometimes product managers (the horror!!).
But more importantly, they build things that matter. They solve real problems for real people. And in a world where technology moves fast but human problems remain constant, that’s a skill that will never go out of style.
Your code will be refactored. Your technical solutions will be replaced. But the product thinking skills you develop and the ability to identify problems, prioritize solutions, and deliver value, those will accelerate your career for decades to come.
The next time you’re asked to build something, don’t just ask “how.” Ask “why,” “what if,” and “what’s next.” Your users will thank you, your stakeholders will trust you, and your career will benefit.
After all, anyone can write code. But not everyone can solve the right problems.
