It’s time to address a common misconception about custom software: it’s built, delivered, and then boom – done.
While that would be easier for businesses and development partners, it’s not the case. Software is not built; it’s grown.
Here’s an example to get you thinking…
We can draw parallels between software development and buying a new custom vehicle. Go to the dealership, pick the model, trim, color, wheels, interior features, etc. – pay, wait for it to come in, then drive it off the lot. Think of this as the basis of ‘building’ your product.
However, routine maintenance is needed to keep your vehicle ‘healthy’ and retain its value. Think of oil changes, rotating tires, the occasional new battery, and, in some cases, recalls. This maintenance is similar to that of growing software; however, the difference is that you’re not just maintaining your software’s value but increasing it.
This blog will outline the shortcomings of ‘built’ products, explain why the ‘growth’ mindset is so important in software development, and provide some relevant examples to give additional context.
Let’s dive in.
Beware of ‘Building’
The opportunity to simply build your product is out there. Maybe you’ve already built your product and haven’t thought twice about it until you came across this blog.
Plenty of development partners are willing to do exactly what you tell them and then send you on your way. The problem is, while your product might be everything you’d dreamed of upon delivery day, eventually, it will need maintenance.
Here are some common things that call for updates to your product:
- User feedback
- Changes in business operations
- Updates to libraries and frameworks
- Compliance requirements
- Operating system compatibility
Failure to meet users’ needs, adapt to technological advancements, or comply with security requirements all have detrimental effects on the long-term health of your software product. However, the overarching theme is simple: grow or die.
The right software development partner will make it clear from day one that your product is a living system that requires continuous nurturing to thrive.
Why Software is Grown
User’s Needs Evolve
Software is either built for external or internal use, but in both cases, your user’s relationship to the software and the solution it’s providing will evolve.
In the software development process, we typically have a “Product Backlog” where all your ideas for features live. While ideas are great, we can devote only so much time and resources to them. So, we narrow them down to the users’ absolute necessities and deliver those as a minimum viable product (MVP).
This approach allows you to build your product’s core value propositions and internally implement or take it to market faster. The primary purpose, however, is to gather user feedback to iterate and improve the product.
Additionally, compatibility comes into play. When users’ devices evolve, the applications or operating systems meant for those devices must be updated to continue serving them.
Business Environments Change
Software is unlike physical products in some fundamental ways. When done well, software reflects and models the real world.
Think of your business; consider how people interact with each other, how physical products flow through a manufacturing process, how documents are edited, etc.
It’s so fortunate that it never changes, right? Wrong. Of course, it changes; to keep up and stay relevant, it has to.
Consider new risks, opportunities, and competitors. All of these require businesses to adapt and change, including the software they may use. This is arguably the most important driver of software growth.
Example: The World’s First Open Industry Platform for Lawyers
The work we did alongside a big law client is a great example of how software is grown, not built. For context, the legal space has been slow to adapt when it comes to technology. Historically, legal professionals relied on outside factors for all things tech, but a consortium of firms approached us with an idea in 2019 to create a collaborative platform for lawyers.
Prior to development, we went through a Validation, Design, and Planning engagement as a part of pre-project consulting with the group to align on vision. During this time, thousands of hours of input from legal professionals helped to identify common pain points and user needs.
Planning Your Project/Product
De-Risking Software Projects Upfront: A Quick Guide to the VDP Engagement
Read postThroughout the engagement, we refined ideas, project plans, and expectations. The user research period allowed us to later grow a product that would meet the needs of legal professionals exactly where they were – creating software that reflects their reality.
Along the way, ideas and concepts were tested in front of working lawyers and their clients, to understand what capabilities were useful, and what ideas would be distractions. This approach helped the team to tune the direction and product roadmap over time, to better provide value for people using the software.
The outcome was a collaborative platform for lawyers that utilizes a “matter-centric” approach that facilitates seamless interactions for clients and their law firms. The product also features a collaborative workspace and seamless integrations with existing storage, document, and communication tools all backed by robust legal sector security and compliance.
We continued working with this global legal tech startup through launch and many iterative rounds of improvements to grow the product as time went on.
Final Thoughts
Building static software, or software that never needs to change, means that your product will not continue to reflect the real world, ultimately losing its value as the environment around it moves on without it.
At Frogslayer, we’re committed to our partners’ success post-launch. After delivery, we partner with our clients to ensure software stays as dynamic and user-friendly as possible through recurring looks at the backlog, frequent innovation checkpoints, and analytics-driven analysis of performance.
No solution can remain frozen in place – that won’t suit your growing needs nor those of your users.
Your software is never ‘done.’ Don’t build it, grow it.
-
Tim Scott
