A Product Perspective for Software Hackers

Caring deeply for, and being in love with our code is something that comes naturally to all of us who treat coding as our craft.
It is a natural approach for artisans to think deeply, code meticulously, and then forever and always guard our creation with the passion of a zealot.
This almost always works beautifully for small, well defined (or well definable) modules of code.

When I became a Lead¹, it was natural for me to carry the same approach towards building larger systems.
Given a problem statement, I worked to find a grand design. It was always built to scale. With a model so good, it would last a lifetime of changes.
I firmly believed that, once it was conceived, all future tradeoffs were in deference to this grand design. Any requirement and/or change that was a deviation from this was a hack or tech-debt. Too many changes meant we were losing our way and must defer to our design deity for future course correction.

There were early warning signs that this was not the best way to approach things.
I distinctly remember a conversation with the Head of Engineering who had a different approach to building systems.
To him, it was all about the product, not the system. The architecture/design, so to speak, was simply a set of reasonably well thought out boxes - something that one can come up with an hour or two of pondering - not unlike what we expect to get from good² system design interviews.
The initial set of boxes are enough for us to get something out there and start our learning process. There is nothing permanent about this architecture - it simply keeps evolving along with the product. I didn’t dwell on the fact that he mentioned product multiple times, didn’t really mention the word system.

Years later, the grand design driven development approach (and, my developer pride) came under more direct attack. I was part of the infrastructure team and we needed to make some core changes. I proposed a grand design whereas a coworker proposed a quicker solution that seemed suboptimal to the purist in me.
My argument: This is a core infrastructure piece and lets take time to build it right.
His argument: Building it right will take weeks whereas his proposal would lead to immediate productivity benefits for engineers that would lead to more features for our customers which means more dollars for the company now.

Dollars?, Sales?, Customers?. Doesn’t my company have an unlimited supply of those?
Besides, weren’t systems supposed to be built right ? Shouldn’t it always scale from now to forever? Didn’t getting it right trump getting it early?

Well, turns out - almost never.
My coworker was right. I was missing the bigger picture - of what mattered to my company and how, what I was working on fit into the larger product picture.
It was important for the company to save man hours now to make a better product faster.

Look, I’m not saying there is no place for good engineering. But engineering is all about tradeoffs, right? These have to be a function of what the company / product needs and not your affinity to a great tech solution. These tradeoffs can almost always be mapped to the real MVP - the customer. And, when it comes to $$, customers or productivity benefits - it’s almost always more important to have them now than some time from now.
Few people are capable of managing these tradeoffs efficiently while delighting the customer. I wish there was a handbook I could cite here, but there isn’t.

It is imperative, I think, for a software developer to develop an intuition towards knowing what’s best for the customer. You may think it doesn’t apply to you. You may be working with a brilliant Product Manager, or may be part of a core engineering team far removed from the end product.
I disagree. For one, you may not be in that position forever. Two, some of the most kickass engineers I know worked on core infrastructure in Azure. Not only was their knowledge about their system unparalleled, they went above and beyond themselves to work closely with us, understand our needs and ultimately use those inputs to build their product better.

So how does one build intuition around what’s best for the customer? Well, I’m still learning too! But here are a few things that have helped me

• Be your own customer. Also known as dogfooding
• Go talk to your customers!
  If you’re developing a consumer product, find someone that uses it and talk to them about what they love or hate about it!
  If you’re into enterprise SaaS, get on a sales call or go out in the field with someone from Sales³
• Work with Designers
  Designers, the really good ones I’ve been fortunate to work with, have this amazing ability to step into the shoes of their customers.
  An ability to think like a designer - to visualise the final solution for your end customer - is a life skill for a developer!
• At the very least, Bug your Product Manager
  Like most of you, I love to fight with the PM. Sometimes it’s just so fulfilling to say No and win.
  But it’s also important to understand their thought process. Probe them. Empathise. Keep doing this till you can truly understand their mental model - especially how/why they prioritise what to build.

Remember, even the most sophisticated technology is useless if it doesn’t empower, improve the life of, or bring joy to the customer.

Would love to read about your experiences building products & systems! Please feel free to email or get in touch over LinkedIn

Thanks to Sourav for helping me write this and providing feedback.

---

Footnotes

PS: The title of this is somewhat inspired by A Hardware View for Software Hackers . An old piece, but a must read if you haven’t already.

1. Which was very early in my career, thanks to being in a high growth startup ↩︎

2. These are not the ones where we have to design Uber in less than 30 mins ↩︎

3. Btw, they’ll always have great stories to tell! ↩︎