The Consulting Mindset: From Order Takers to Offer Makers
“If you do the same thing for 10 years, you don’t have 10 years of experience—you have one year of experience repeated 10 times."
Picture this: a developer, a product manager, and a QA walk into a room. The developer brags about squashing 300 bugs, the QA beams at running 10,000 tests, and the product manager… well, they’re stressed, juggling roadmaps. But somewhere in this mix, everyone missed the memo: The customer doesn’t care about your lines of code or your test scripts. They care about their problem getting solved.
This is where the consulting mindset swoops in, wearing its cape of clarity and wielding its sword of problem-solving. A mindset that says, “Let’s stop taking orders. Let’s start making offers.”
Problem First, Code Later
Here’s a truth bomb: solving problems is our job, not just writing code. If you dive into solutioning without understanding the problem, you’re basically writing love letters to ambiguity. And as one of my favorite quotes goes, “Ambiguity is failure.”
Take, for instance, the infamous tale of the zero-gravity pen. American engineers spent millions creating a pen that worked in space, while their Russian counterparts just used a pencil. Whether or not this story is entirely accurate, the lesson hits home: problem-solving starts with asking the right questions, not just jumping into solutions.
The Art of Asking “Why”
Think of yourself as a 3-year-old with a purpose. Ask “why” until you get to the root of the issue. Why is the website slow? Oh, it’s the backend? Why is the backend slow? The database? Why is the database slow? You get the drift. Without peeling back the layers, you might end up optimizing a process that no one even cares about.
But don’t stop there—ask “what” and “how” too. What’s the impact of this problem? How does it affect your customer’s KPI? KPIs aren’t just corporate jargon—they’re the North Star guiding your solutions. Want to help a client retain more users? First, figure out why they’re leaving. (Hint: It’s rarely because the code isn’t pretty.)
Active Listening: TDD for Conversations
Developers love Test-Driven Development (TDD), right? Well, think of active listening as TDD for conversations—get constant feedback to validate your understanding. Turn on your camera in meetings, nod like a bobblehead, and paraphrase to confirm you’ve got it. “So, what I’m hearing is…” goes a long way in showing you care.
And let’s talk about distractions. Nothing says “I value your time” like NOT checking your Slack pings mid-call. Oh, and one golden rule: don’t slip into solutioning mode while someone’s still explaining their problem. We’ve all been guilty of jumping to conclusions, waving our sonar-scanner wand, and yelling, “CI/CD will fix it!” Spoiler: It won’t.
Aligning with Customer KPIs
Here’s a quick exercise: Think of a project you worked on. Now ask yourself, “What KPI was I improving?” If you’re drawing a blank, you’re not alone. Most developers see “tickets” instead of the bigger picture. But KPIs—like customer retention, revenue growth, or time saved—are where your efforts truly shine.
For instance, imagine Amazon wants to increase customer retention by 20%. You might brainstorm ideas like loyalty programs, personalized recommendations, or faster delivery options. But without understanding why customers leave, you’re shooting in the dark. Maybe it’s not the speed of delivery but the lack of engaging product reviews. See? The right problem leads to meaningful solutions.
Let’s Talk Metrics (And Avoid Clickbait)
Output vs. outcome—it’s the age-old tussle. Building a dashboard (output) is great, but the real win is when that dashboard helps sales teams close deals faster (outcome). Focus on the latter, and you’ll avoid falling into the clickbait trap of creating flashy features that add zero value.
Speaking of metrics, ever heard of Net Promoter Score (NPS)? It’s a fancy way of asking, “Would you recommend us to a friend?” Whether it’s NPS, customer acquisition cost, or monthly recurring revenue, these metrics guide us to what really matters—making customers ecstatic.
A Consulting Mindset in Action
In one of our recent team exercises, we played the role of IRCTC (the Indian Railway Catering and Tourism Corporation).
The problem? A high drop-off rate during ticket booking. Developers, product managers, and even QAs brainstormed solutions, ranging from faster payment gateways to simplifying UI. But the real breakthrough came when someone asked, “Why are users dropping off?” Turns out, most users were stuck at the CAPTCHA step. Fixing that small hurdle made all the difference.
Final Thoughts
Adopting a consulting mindset isn’t about abandoning your developer roots; it’s about evolving them. It’s about being curious, empathetic, and outcome-driven.
Remember: you’re not just writing code; you’re crafting solutions that change lives.
So, the next time you’re knee-deep in a sprint, pause and ask: “Am I solving the right problem?” Because when you do, you’re not just a developer—you’re a consultant. And trust me, that’s where the magic happens.
Note: The above article is generated automatically from the transcript of a recent training I did at Incubyte. More parts to follow.
Feel free to check out previously published articles-
