The Art of Shipping: Prioritizing Product Development Amidst a Developer-Centric Landscape

Cover Image for The Art of Shipping: Prioritizing Product Development Amidst a Developer-Centric Landscape
Tanner Linsley
Tanner Linsley

Amidst the current tech trends, there's a noticeable surge of resources such as blog posts, developer tools, tutorials, and videos that underscore the importance of processes, tech stack decisions, performance, speed, distribution, and scalability. However, there's a seemingly diminishing emphasis on the creation of products tailored for non-developer users.

As a developer frequently crafting tools for my peers, I understand the urge to enrich our developer toolbox. Yet, it's crucial to remember that these tools must eventually be put to use - not merely accumulated.

It's all too easy to become ensnared in the intricacies of process optimization, distribution logistics, performance enhancements, and other factors that might constitute your job or resonate with your interests. While these elements may substantially impact your performance metrics, bottom line, or professional credibility, I've recently been exploring the challenging yet rewarding realm of building user-centric products.

In an environment pulsating with competition and filled with alternative solutions, the pressure to release timely updates has helped me empathize with product managers and development teams. They are often tasked with balancing user needs and stringent deadlines against process adherence, tool utilization, and developer workflows.

A concept that has resonated with me throughout this journey is that the most vital resource for a company isn't the employees, tools, or processes, but the product itself. As explained on Conversion Rate Experts, the product and its development should hold precedence, and all other components – including developers, tools, and processes – should be flexible and adaptive to the product's requirements.

This product-centric perspective often necessitates letting go of deeply cherished processes, tooling decisions, and quality measures, at least in the initial stages. As software engineers, the saying "it depends" is a common refrain. However, I've come to realize that this should be frequently coupled with another maxim - "right time, right place." As a product or feature garners sufficient success, aspects like process, performance, scalability, and appropriate tooling inevitably rise in importance.

We often tend to optimize for ourselves as developers, aiming to streamline our tasks and make our lives easier and more efficient. While this is a natural instinct, it might not always be the most practical or successful approach. True productivity in software development often requires us to battle this instinct and strive to eliminate potential future difficulties from the equation. Time, after all, is the most precious resource we all possess, products included. If you succeed now at the cost of your product failing, your time will be cut short. However, if your product succeeds now while you manage to do "well enough," you'll gain more time for your future self to continue succeeding.

Our role as software engineers involves maintaining a careful balance. We need to consider the mantra "it depends," make informed decisions based on our constraints, and identify the opportune moments for making these decisions and compromises. We must keep the product's momentum at the forefront of these considerations.

Having adopted this approach over the past few months, I've noticed it has significantly amplified my career impact. While the code I've written recently may not be the most pristine, scalable, or performance-optimized I've ever produced, it's merely an implementation detail. The true success lies in the productivity and satisfaction experienced by my users, a result of timely, well-informed decision-making as a team.

In his blog post, Mitchell Hashimoto discusses the importance of driving results as early as possible and striving to achieve "demoability" as soon as possible, reinforcing the need for swift product development and shipping.

If your current projects don't demand such critical decision-making, I encourage you to seek ones that do. Exercising decision-making muscles under real-time constraints for real users is indeed invaluable. Let us remember: we're not merely developers - we're product builders, and our primary focus should be to ship products that provide tangible value to our users.