I’m Lazy - it’s true!
I’m lazy. Not in the way that I avoid all work, but I just feel uncomfortable building things that aren’t fully fleshed out. I want to think about what the easiest and quickest way to get to our destination is, not just get into an endless grind building some massive system.
There’s something deeply unsettling to me about the idea of spending months on a complex project without being sure it’s actually going to solve the problem. I’ve seen too many teams disappear into these elaborate builds, emerging months later with something technically impressive that customers use politely but don’t love.
So when someone comes to me with a big request, my first instinct isn’t to start architecting. It’s to figure out: what’s the smallest thing we could build that would actually make people happy? What if we’re overthinking this? What if the solution is simpler than the problem?
This kind of laziness has taught me the most important lesson about why smart, well-intentioned teams consistently build the wrong thing. It’s not about incompetence or poor communication. It’s about a fundamental bias toward complexity over understanding, building over questioning, solutions over problems.
Which is how I ended up saving a major customer account with two days of work instead of three months.
The call came from my boss: we had a large customer threatening to churn unless we built a specific feature they demanded. Sales was panicking, leadership was involved, and I got tagged as the technical lead to “help save this account.”
In the first meeting, the dynamic was clear. Sales was ready to bend over backward—this was a big customer, and losing them would hurt. The customer had done their homework. They knew exactly what they wanted: a complex feature that would integrate with their existing systems in very specific ways. They had wireframes. They had technical specs. They even had a timeline of when they needed it delivered.
It would take us at least three months to build. Maybe four. It would be complex to test, risky to release, and would pull our entire engineering team off other priorities. But hey, customer is always right, especially when they’re paying us a lot of money.
While sales was nodding along and taking notes, my lazy brain was doing different math. Three months of development. Weeks of QA. High-risk deployment. All for one customer’s very specific use case. What if we built this whole thing and they still weren’t happy? What if other customers hated it? What if it broke something else?
So I started asking questions.
Not to be difficult—I genuinely wanted to understand if there was a way to avoid three months of potential misery. What problem were they really trying to solve? Why did they need this specific approach? What would happen if they had to wait another quarter? What were they doing right now instead of having this feature?
The customer was patient at first, then a little annoyed. They’d already explained what they needed. Why was I making this complicated?
But as we kept talking, something interesting emerged. The feature they described wasn’t really about the technical capabilities they’d outlined. It was about a workflow problem they were having. Their team was spending hours every week doing manual work that felt repetitive and error-prone. They’d looked at our product and reverse-engineered what they thought would solve it.
Here’s the thing about customer requests: they’re usually solutions disguised as problems. This customer had done what smart customers do—they’d diagnosed their pain point and come up with a technical solution. But their solution was based on their understanding of our product’s architecture, not our understanding of their actual problem.
Once I understood the workflow issue, I had a different idea. Instead of building their complex feature, what if we broke their request into seven smaller milestones? The first milestone would address the manual work problem directly, but in a much simpler way. The other six milestones would gradually add the complexity they thought they needed.
Sales loved this because it sounded like we were giving the customer everything they wanted, just spread out over time. The customer agreed because milestone 1 sounded like it would solve their immediate pain, and they’d get the rest eventually.
But here’s where it got interesting: my team didn’t understand why we were starting with milestone 1. It seemed unintuitive. The customer had clearly explained what they wanted, and milestone 1 wasn’t that. Why weren’t we building the thing they’d actually asked for?
Sales kept pushing me for detailed timelines for all seven milestones. I resisted. I had a strong feeling that once we delivered milestone 1, the conversation would change, but I couldn’t really explain why.
Two days after we shipped milestone 1, the customer called us. They were ecstatic. The feature solved their workflow problem completely. They renewed their contract immediately and said they didn’t need us to prioritize the other six milestones anymore.
My lazy approach had worked. Two days of development instead of three months. One simple feature instead of a complex system. A happy customer instead of a risky bet.
But why?
The Psychology of Surface-Level Thinking
That customer experience taught me something about how our brains work when we’re trying to solve problems. There’s a natural human tendency to jump to solutions, and when we’re under pressure—especially pressure to keep a big customer happy—that tendency gets even stronger.
Everyone in that room was smart. Sales understood the customer relationship. The customer understood their own business. My team understood our technical capabilities. But we were all operating at different levels of abstraction, and most of us were staying at the surface.
The customer had done what customers always do: they’d identified a pain point and worked backward to a solution. But their solution was constrained by their outside view of our product. They could see what features existed, but they couldn’t see all the ways those features might be recombined or simplified to solve their actual problem.
Sales had done what sales teams always do: they’d focused on the relationship and the revenue. Keep the customer happy, get the signature, hit the number. The specific technical approach was less important than the customer feeling heard and valued.
My team had done what engineering teams always do: they’d focused on the technical requirements. The customer wants X, so we build X. Clean, logical, straightforward.
But I was being lazy, which forced me to ask a different question: what’s the smallest thing we could build that would make this customer happy?
That question led me to dig deeper into the actual problem rather than accepting the proposed solution. And what I found was that the customer’s elaborate solution was solving for a much simpler problem than anyone realized.
Why Smart Teams Stay Surface-Level
This pattern plays out everywhere, not just with customer requests. Smart, well-intentioned teams consistently default to surface-level thinking, even when deeper understanding would save them enormous amounts of work.
Why?
Surface-level feels safer. When a customer gives you detailed specifications, it feels risky to question them. When your boss gives you clear requirements, it feels insubordinate to push back. When stakeholders align on a plan, it feels disruptive to ask whether it’s the right plan.
Abstraction creates the illusion of clarity. Requirements feel measurable, defensible, professional. “The customer needs advanced reporting capabilities” sounds more credible in a stakeholder meeting than “Sarah gets anxious on Fridays and needs to know she didn’t make any mistakes.”
Surface-level feels faster. Taking requirements at face value lets you jump straight into solutions mode. You can start architecting, designing, building. You can make progress that feels tangible and measurable.
Deeper questioning feels like it’s slowing you down. Those conversations are messier, more ambiguous, harder to quantify. It’s not obvious how much digging is enough digging. It’s not clear when you’ve understood the real problem versus just uncovered another layer of complexity.
Surface-level feels more professional. Engineers and product managers are trained to think systematically, to break down complex problems into manageable components. We’re rewarded for our analytical thinking, our ability to create order from chaos.
Customer empathy, on the other hand, feels squishy. Understanding someone’s Friday anxiety doesn’t feel like a core technical competency. Asking about emotions and workflows and fears feels like soft skills territory, not the hard skills that got us promoted.
But here’s what I learned from that customer experience: surface-level thinking creates more work, not less.
The Hidden Costs of Abstraction
When teams operate at the surface level, they pay a tax that’s largely invisible until it’s too late.
The Rebuild Tax. You build the wrong thing, then you have to build it again. Or you build something that sort of works but doesn’t quite hit the mark, so you spend months iterating and refining until it finally solves the actual problem.
The Context Switching Tax. Without a deep understanding of the problem, your team lacks conviction about the solution. Every decision becomes a debate. Every edge case becomes a research project. Progress slows down because no one is quite sure what “done” looks like.
The Feature Creep Tax. When you don’t understand the core problem, you end up building around it. The customer asks for modifications, stakeholders request additions, edge cases multiply. What started as a simple feature becomes a complex system because you’re solving symptoms instead of causes.
The Maintenance Tax. When you don’t understand the core problem, you end up building features that customers only kind of need. And “kind of needed” features are the worst kind—they get used just enough that you can’t remove them, but not loved enough to justify their existence. Every time you refactor your codebase, you have to work around them. Every time you update your infrastructure, you have to make sure they still work. Every time you onboard a new engineer, they have to understand these half-loved features and why they exist. You’re paying an ongoing maintenance cost for features that solve problems nobody really cared about in the first place.
My lazy approach—asking questions until I understood the real problem—helped us avoid all of these taxes. We built exactly what was needed, nothing more. The team was confident in the solution because the problem was clear. The customer was thrilled because we solved their actual pain point.
The Paradox of Productive Laziness
The counterintuitive thing about laziness is that it often leads to better outcomes than heroic effort.
When you’re lazy, you’re naturally motivated to find the most efficient solution. You don’t want to build more than you have to. You don’t want to solve problems that don’t need solving. You don’t want to spend months on something that could take days.
But efficiency isn’t just about writing less code or having fewer meetings. The highest leverage efficiency comes from solving the right problem in the first place.
That customer story wasn’t really about my superior questioning skills or my deep intuition about their business. It was about being too lazy to spend three months building the wrong thing.
The questioning happened because I wanted to avoid work, not because I had some sophisticated customer research methodology. The milestone approach happened because I wanted to minimize risk, not because I had a grand product strategy.
But the laziness forced me to think differently about the problem. Instead of asking “how do we build what they want?” I was asking “what’s the least we could build to make them happy?”
That shift in perspective—from customer requirements to customer satisfaction—opened up solution space that wouldn’t have been visible otherwise.
What This Means for Your Team
If you recognize your team in this story—smart people working hard on clearly defined requirements but somehow missing the deeper human problems—you’re not alone. Most teams operate this way most of the time.
The good news is that shifting from surface-level to human-level thinking doesn’t require a complete organizational transformation. It just requires cultivating a different kind of laziness.
The next time someone brings you a detailed request, try asking: what’s the smallest thing we could build that would make them happy? Not what’s the minimum viable version of what they asked for, but what’s the core problem they’re trying to solve?
The next time you’re scoping a complex project, try being too lazy to build it. What if you had to solve this problem with one-tenth the effort? What would you focus on then?
The next time stakeholders align on requirements, try being too lazy to take them at face value. What’s the human story behind these abstractions? Who is the Sarah in this scenario, and what is she really afraid of?
You might be surprised how often the lazy approach leads to better outcomes than the heroic one.
And you might discover, like I did, that the most productive thing you can do is refuse to work harder than you have to.
This is Part 2 in a series about finding the humans behind your requirements. Part 1 explored how surface-level customer feedback kills products. Part 3 will dig into why smart teams get trapped in abstraction even when they know better.
