Once you drop, you can’t stop
In the essay “Why software is eating the world” from a decade ago Marc Andreessen makes the case for why “every company needs to become a software company”.
In the essay “Why software is eating the world” from a decade ago Marc Andreessen makes the case for why “every company needs to become a software company”. His reasoning still holds true today. In the modern climate businesses from all sectors are simultaneously aiming to grow while protecting their flanks from the next Uber, Amazon, Netflix, or AirBNB that could fundamentally disrupt the normal course of operations. Even if you aren’t competing against the next behemoth there is a significant case to be made that improving your customer experience and improving the efficiency of the business will pay dividends.
From a practical point of view we see this every day in our work. Companies from all backgrounds are looking at ways that software can be used to strengthen their existing position whether those companies are software startups or what might be considered a more traditional brick and mortar businesses such as manufacturing, engineering, construction, and the like. The reality is that software can and should be leveraged to improve customer experience, drive efficiencies, and continue to build a moat around your business. Today; everyone walks around with smartphone in their pocket and that more than any other technical advance has put business into a position where customers demand a consumer friendly experience! Businesses that succeed acknowledge and embrace this shift and will be well prepared for the next section of this article.
For many businesses the question is no longer “should we be in the software business” and is now “why haven’t we invested more”.
This post isn’t designed to convince you that you should take these steps. This article is designed to outline a set of realizations for those businesses that have decided to make the move but need a mental model and guidance for key concepts and differences you might encounter building out a software practice in your organization. We often simplify this conversation into the difference between a software project and thinking about your investment as an ongoing software product.
Fundamentally speaking, projects by their nature are short term and not strategic. Projects have a defined start, end, and rigid milestones. They don’t typically allow for flexibility and we rarely see a “project” that has time allocated for proper customer experience feedback and reprioritization of needs based on observed behavior and/or opportunity. Projects by their nature are a rigid thing and the natural goal with a project is placing the focus away from your customer and instead focus on internal measures like “on time and on budget”.
Products on the other hand evolve. They are adaptable, and create the space for the team to interact with customers and users, collect feedback, observe behavior, and flow towards value. Products are often driven by a larger values statement and will consider any and all methods for achieving that end executed by many small iterations delivered constantly. For some this is a difficult concept to envision because when you are in the software product space the process never really ends.
Below we’ve constructed a table that highlights some of the key differences between project and product thinking. We submit this as a frame of reference from our experience working with many companies of all sizes in a myriad of industries for your consideration.
At Tarmac we’ve been around the block and have worked on a variety of different software solutions including both traditional projects and the latest software products. More and more frequently we’re seeing significant benefits in agility, cost and efficiency when our clients make the shift from a project to a product mindset. To enable this fundamental change we’ve invested heavily in our DevOps capability to help clients make the necessary changes and implement this switch.
Our friends over at Fforge have recently bloggedabout their own move to a DevOps culture and the impact it will have on their managed service clients. As they correctly point out, there are many different flavors of DevOps and every organization will have a slightly different interpretation of how to do it. Tarmac is no exception and we’ve formalized our approach to the entire development lifecycle into the Tarmac 10 framework. Regardless of your primary business and how you manage your software development, a shift from a project to a product mindset will ensure you have good technology foundations on which to build your new “software” business.