B2B Start-ups and Outsourcing: Lessons Learned
Below are the key points behind Squawker’s software development that perhaps highlight the very future of intelligent software development for mission-critical solutions.
The Beginning: Proof of Concept
There are many different ways to start new technology projects. The trick is to start with the creation of a small-scale Proof of Concept, or PoC, for the intended product. The PoC stage should produce some minimal piece of software that helps to achieve two main objectives: validate your early product vision and validate your preliminary ideas of the technical architecture. The resulting software should be neither too functional, nor too polished. A common mistake is to view this as the first release available to actual users and thus to overload it with features. Such a PoC can rarely be made into a usable product, but neither is it a cardboard cut-out to be later thrown completely away. Finally, you should specifically not try to make the PoC look and feel final – the full-scale UI/UX design is a sizable effort and will never fit within the disciplined, ascetic budget of a PoC.Nothing provokes unanticipated insight and heated debate like tangible, working software. After completing the PoC, its results can and must be shown to a broader range of potential user and customer base, investors, industry or technology experts and any relevant party whose opinion the founder team would value. We recommend spending a few months discussing, gathering feedback, learning, and adjusting your product concept before embarking on the actual development, even if you have secured sufficient funding. With this invaluable early feedback you will spend your development budget much more wisely.
Under the Hood: Technology Mix
Another set of important decisions to make lies with the architecture of the future product, and the pivotal aspect here is the choice of technology stack, or stacks, to serve as the foundation of the technical solution. The main trade-off here can be expressed in terms of the famous technology adoption curve, which reflects the progressive spread of a new technology across various segments of the target market or population.
For a start-up, the optimal point on the adoption curve is somewhere between early and late majority, the truly mass adoptions. The technologies that have reached that stage are already sufficiently commoditised and pose low risk due to their widespread adoption. Yet, they have enough remaining lifetime to make the investment viable. The lesson learned here is to pay attention to the trade-offs between the cutting edge technology and what has been proven to work.
Another important issue, specific to B2B and especially to financial services projects, is the very demanding operational constraints, or non-functional requirements. The system must be very reliable, as you are dealing with real money (and lots of it). Performance and response times should fall within a strictly prescribed range, in order to meet the users’ expectations. Compliance and related considerations demand complete auditability of everything happening within the system. All of these constraints require that the implementation technology be predictable in its key characteristics.
This “majority” approach was exactly the path Squawker took. The whole solution was founded on technology stacks and architectural patterns that are very up-to-date and fully proven. The elaborate knowledge of those technologies that the IT industry has gathered over years allowed for informed and methodical technical decision making process and helped avoid any unnecessary experimentation. The extensive ecosystem of supporting techniques and tools allowed easy implementation and automation of all parts of the development process, from performance management and optimization to optimal deployment topology.
Bringing It All Together: Responsibility Balance
The next topic begins when the start-up seeks to do part of the new product development with some help from an external specialist. With this decision comes the crucial and often overlooked question: What should be the optimal distribution of relationship areas in a complex project undertaken by an ambitious startup? Or, to put it simpler, who should own what?
Startup founders often begin with a very business-oriented team and assume that they can outsource all or almost all of the responsibility for the technical solution. After all, isn’t that what consulting and outsourcing are for? While vendors are happy to oblige, such a setup may lead to a wide range of execution risks, ultimately undermining the whole endeavor. The most critical among those risks is the potential misalignment between the way the system is structured internally and the way it is presented to the outside world. Technical decisions are never made in a vacuum, especially for mission critical systems. And no vendor, however experienced, can completely envision your product for you when you’re building something innovative and disruptive.
The Squawker team is a prime example of how to work on a development project. Their core team had between them many decades of trading and financial technology experience, so they were perfectly capable of steering the project while bringing in external partners to build an integrated implementation team. While iterating over the exact product definition and design and adapting to what was being learned in the course of development, the Squawker team has always had a clear and crisp vision of their ultimate goals and was able to guide the other contributors in all the essential business aspects of the project
Conclusion
In conclusion, let me reiterate the essential lessons that I deem valuable for both startups and consultants in the technology-intensive segments such as financial services:
- Start your product development with a small yet tangible Proof of Concept that will not be released to customers, but will help you validate and adjust your vision before plunging into a full-fledged and costly development effort.
- Pay attention to the technology choices you are making and consciously assess the trade-offs between the cutting edge and the proven.
- Make sure that the startup team has sufficient capability in-house to integrate and control all of the key aspects of the project, both at the level of business and technical implementation.
Dmitry Stillermann is vice president of Capital Markets at DataArt. Dmitry joined DataArt in 2004 and managed large-scale projects in the financial and travel & hospitality verticals. Dmitry is a member of DataArt PMO and Delivery Board and oversees and promotes best practices in project management. Since 2009 Dmitry is responsible for project delivery across DataArt Financial Practice, being in charge of HRM, infrastructure, project governance and training in the segment. Prior to DataArt, Dmitry worked as a software developer and project manager at Reksoft, an IT outsourcing company headquartered in St. Petersburg, Russia, where he was in charge of project management for large European telecom and fashion retail clients.
Tweet This