Here’s a word of advice to anyone itching to build software solutions to make life easier for your clients or colleagues.
Stop.
Don’t start work on turning your brilliant brainwave into a product until you’re clear in your head exactly what you – and, more importantly, your clients – need. Avoid investing time and other resources in software development until you have factored in channels for involving the end-users of your product in every stage of the process.
While we love empowering lawyers and other professionals to create their own digital products and solutions, this does not mean neglecting the golden rule of “Agile” development: to continually seek client feedback.
To understand why this is important, and the dangers of getting it wrong, let’s recall the traditional approach to enterprise software development. Even if you were not directly involved in the process, you may remember when monolithic computer corporations with great fanfare foisted new releases on their entire customer base to suit their own internal timetable. Any bugs that emerged with the new release – and bugs always emerge – were noted and squirrelled away to be fixed in the next release, again timetabled for the developer’s convenience.
This methodology known as “Waterfall” development ensured that user feedback was at least one software release behind the latest version. It was also filtered through business and systems analysts before it reached the developer, who frequently interpreted it in their own way. Even when they got it right, by the time the new release came out, the world had moved on again.
To the relief of nearly everyone, the digital world has largely replaced waterfall development with agile methodology. The aim here is to get inside the user feedback loop. Developers talk directly or have access to the end-users about what they need, put a prototype into their hands as quickly as possible for testing, then make iterative changes based on constant feedback about what the real users do with the product, not what analysts think they do.
This is what design thinking is all about, whether the aim of the product is to make internal efficiencies in a business, to create a service that clients pay for, or a give-away product to encourage clients to take up your core services.
No-code platforms like Neota Logic or our rapid prototyping tool, Canvas, encourage an agile, design-thinking led approach to product development. We support non-traditional developers such as lawyers to create digital services. But this will be worthwhile only if we remember the key part that client feedback plays in the agile development process and don’t get trigger-happy with the software.
In best-practice design thinking, we should be spending much more time than we think in the problem space, properly scoping out ideas, issues and use cases before touching any software solutions. The importance of this approach is even more pronounced when developing software for a law firm, which may have two sets of users: the internal lawyers at the firm and the firm’s clients. At every stage of product development, especially at the scoping stage and critically before any development has started, we should be getting feedback from the end-users of the software.
When development is underway, we need to keep our focus on the minimum viable product and get it in front of end-users regularly for iterative product improvements. We must always be aware of the temptation to add features across the board which have not been extensively verified by our target audience. Avoiding wastage, technical debt and unnecessarily cluttered product roadmaps is the name of the game here.
It doesn’t take much imagination to see what happens when we fail to adopt a user-centric approach. At best, a project that begins in a spurt of enthusiasm, perhaps from a partner, fizzles out when another member of the management team – typically, the CFO – puts roadblocks in its place. At worst, an unsuitable product is foisted upon reluctant users, and that’s a guaranteed way to alienate colleagues and clients alike.
Of course, it’s not easy to obtain useful user feedback. Developers may feel apprehensive about bothering senior partners or valuable clients. But we need to get past that barrier – hence the importance of building in a formal feedback mechanism at every stage of the process.
For legal professionals especially, agile methodologies can be counter-intuitive. Lawyers are always striving for perfection even with their initial draft documents, but this isn’t how iterative product development works. One way to get the message across is to recognise that lawyers are also transaction-oriented. We can look at software development in the same way: V1 is the first transaction, V2 is the next transaction, and so on.
How do we know it’s being done? Only by building constant feedback from multiple stakeholders into every stage of the process. If you’re talking to a broad spectrum of end-users and they’re all experiencing the same problems, you’re off to a good start. But if only one of the cohort reports a problem, be wary of making that the main priority (which is hard if that person has a loud voice!).
At Neota Logic we adopt quarterly release cycles which are informed by regular client feedback, client advisory boards and other methods to ensure that we are continually capturing in-depth feedback on the development of Neota’s products and services, the overall customer experience and strategic market opportunities.
What could be more valuable?
Vinay is a Senior Solutions Engineer at Neota Logic, where he designs and builds software applications for law firms and in-house legal teams using Neota Logic’s no-code AI automation platform. He spent 8 years as an M&A and capital markets lawyer at US law firms and investment banks before moving into the legal tech industry, where he has gained experience in product development and commercial strategy.