When designing something, development teams tend to treat the job as a construction team would go about building a house. Through a series of stages, they set the foundation, install the infrastructure, put the finishing touches on it, and never touch it again. In short, developers look at their work as a one-time project.
This strategy is fine when building a house with various stages and there’s a finite end date to send it to market, but for SaaS products, which need to be constantly updated and configured, it can be harmful to approach work with such a short-term mindset. Changes will always be required – what you think you need will be different that you actually need. In other words, you have to start thinking in terms of the product.
Rather than thinking in terms of short-term projects, developers need to educate potential clients on the importance of playing the long game and why companies need to have a standing relationship with their developers even past the launch of a product. The problems that result from this mistake could be avoided by recognizing that any SaaS endeavor must be product-focused. Here are three reasons why valuing product over project is essential.
Continuous improvement cycle
For developers, the continuous improvement cycle should be held as a golden standard when working on a product. Within the continuous improvement cycle, the product is never finished – it’s a constant circle of identification, planning, executing, reviewing, and repeat.
However, with SaaS products, many developers have the mentality that it’s going to be done in a few weeks – in reality, the product is never done. They should instead plan in terms of how many years they’ll be putting on the product; even if the product is released, it’s still never done and consistently needs to keep being improved upon.
Look at the global juggernaut Facebook, for example. Mark Zuckerburg didn’t think of it in terms of a project that would be done in three months. They didn’t abide by strict dates but kept on a dedicated team of developers, which they continue to employ to this day, consistently improving upon their product year after year.
The ability to divert from the blueprint
Sometimes – or all the time – things don’t go exactly to plan. In order to counter unforeseen external variables, you need to be able to divert attention from the original task if need be.
Projects, with strict deadlines to take into account, don’t allow developing teams to divert too much from the original game plan as higher-ups often would rather push something to market before it’s ready. Furthermore, many times a final product turns out to be something completely different than what the initial plan had in mind. The ability to be flexible is essential for SaaS products to be profitable.
Slack is a good example of this. Surprisingly enough, designers originally planned for the now ubiquitous cloud-based workspace to be a video game. However, they ran out of money before the game was ready and they decided to release the tool that they used to communicate while creating the game – what we now know as Slack. They then abided by the continuous improvement cycle, improving the product, identifying new features to highlight, and improving upon them. Slack is now a highly profitable tool, largely because they were afforded the ability to divert from the original blueprint.
Saving money and improving efficiency in the long-term
Lastly and perhaps most importantly, viewing a job as a product saves time and improves efficiency on the design team. When you stop seeing development as a one time only affair, you see it as an expense that you’ll always have and are able to pull together more resources. The more resources you obtain, the better project you’ll have.
For a project, a company simply gives a quote and then when the product is done, that’s the end of the development team’s contribution. Because projects have a deadline, after the date has passed, there is no reason for the development team to continue. When problems inevitably occur, the company is forced to rehire and requote a new development team to finish the project – a cycle that will inevitably continue to occur once a new problem arises.
Viewing a development job as a long-term product is a much more efficient way to go about things. In this scenario, a client will pay month to month, continually improving and expanding upon the product even after the final release. Even better, as the development team has a close relationship with the product, they will also be much more invested in the success of the product.
Not everything has to be structured into a series of finite steps. Building houses, while no easy task, nonetheless can be much easier planned than a SaaS product. Viewing your SaaS as a product will go a long way in allowing your team to succeed in a crowded market – you never know what the final product will turn out to be.
About the Author:
Phil Alves is the CEO and Founder of DevSquad.
