PCR Tech and IT retail, distribution and vendor news
Ken Miller, CTO at Panintelligence discusses how CTO’s can feel more confident in the SaaS tools they invest in.
Acting decisively to solve problems is simply part of the day job for anyone responsible for a SaaS product, true. But every so often, a blue light issue comes in that challenges us, and the urgency only grows as we comprehend what decision to make. Often, this blue light issue is a particular feature that a significant customer is calling for, and it’s got to the point where if the issue is not resolved soon then they could walk. By this point, there’s a monkey on each shoulder shouting conflicting messages at you. On the one hand, is the urgency to jump for fear of losing that customer, and on the other, there’s the hesitancy to act, as making the wrong decision could have disastrous consequences. You’re in the hot seat, invested in success, but mistakes can be all too visible. Sound familiar?
But as we’ve already established, hesitation is not an option. To quote the late, great, Patrick Swayze in his 1991 blockbuster, Point Break, “Fear causes hesitation, and hesitation will cause your worst fears to come true.” Having dedicated much of my career to building SaaS products and embedding new technologies, platforms and features within them, here’s what I’ve learned about overcoming the fear and choosing the right course of action when implementing new features and software into a SaaS product.
Defining the issue
The first step on this journey is to define the issue you need to solve. It sounds obvious, but it’s important to consider ‘why’ your customers need this solution as well as ‘what’ they need it to do. In the case of Panintelligence, for example, SaaS vendors come to us because they want to help their customers make better decisions and improve their business’s performance, and they want to do this by embedding improved reporting and analytics functions within their platform. The ‘why’ really helps to craft a solution that delivers value rather than simply ticks a box.
Build Vs Buy
You’ve now defined the issue you need to address, and you know the value that this solution needs to deliver. Here comes the ultimate test. Do you build or do you buy? In the past, for many of us CTOs, if we have the resource and expertise in house to do it ourselves then nine times out of ten, we’d build. Why? That fear factor again. The fear of an external solution not meeting the criteria, not integrating properly, and causing more problems than it solves. Using your own team that has intimate knowledge of your product is the safe option.
But is it really? Do we really have the knowledge and expertise of a company that has already built and refined this solution, and knows what it entails? Can we build a solution ourselves that gives us market-leading capabilities? With this in mind, more and more CTOs are now choosing to buy.
Here are the five main considerations to weigh up when making this decision:
1. Cost – It’s important to look at the big picture and calculate the overall lifetime cost of building vs buying a piece of software. Building in house still has a large cost attached to it and may not be cheaper once you’ve added in ongoing maintenance, opportunity costs due to the time it takes to build, and the fact that if your DEVS are building this – they aren’t doing something else. Often buying can seem more expensive until you’ve delved deeper and looked at the true price of building.
2. Control – While building will undoubtedly give you more control, there’s a significant amount of flexibility and adaptability that SaaS to SaaS vendors can deliver. It’s important to consider how personalised they can make both the solution and the integration experience.
3. Expertise – How important is this new feature to the future of your product? We’ve all been there when a build turns out to be far more complex than we thought. How much value is there in the expertise of a vendor having experienced this hundreds of times over? In the case of Panitelligence, business intelligence (BI) and data management is a rapidly evolving area which is hard to keep up with. For us it’s our day job, but for the SaaS vendors we work with, it’s not a battle they want to face themselves. They’d rather spend their time focussing on their core area of expertise.
4. Speed – How quickly do you need this solution implemented, both in terms of keeping the client happy and giving you the headspace to get on with other issues? It’s also worth considering a self-service approach, where you enable your customers to build a ‘right fit’ solution that works for both them and you.
5. No code – Does the solution require coding or not? Is it designed to embed quickly, and keep your dev resources focused on your core application? In the case of BI, developers tend not to be consumers of BI in their working lives, so often don’t have a practical understanding of how it should and will be used. It’s important to bring in people with business experience rather than tech experience as they drive better results for the end customer. This is where no code really helps.
Fast deployment
Whether you’ve built or bought, time is still of the essence. A structured roadmap with clear deliverables and timings are crucial. If something starts to slip be on top of it and don’t be afraid to change tack completely. If you’ve chosen to buy, make sure it’s a solution that’s simple to install. Some solutions can be hooked up to a cloud database and be operational in minutes. Whatever your solution, ‘less haste more speed’ is always the mantra.
The human touch
It’s important not to forget the people element when implementing any new solution. If you’ve bought a solution, then the human capital provided by the vendor should be a significant consideration when making that choice. You need a team that will take the time to understand your needs, your customer’s ‘why?’ and then guide you through the onboarding process, smoothing out any roadblocks along the way.
Either way, once a solution is implemented it becomes an integral part of your product. Involving your people at every step of the way, from DevOps to customer-facing representatives, will ensure a solution that’s fit for purpose and that customers can quickly onboard with, once it’s rolled out.
By carefully defining your objectives, weighing up the pros and cons of whether to buy or build, ensuring a fast but efficient deployment and bringing your people with you along the way, CTOs can overcome their fear, act decisively and ensure their SaaS products continue to meet customer needs. It’s taken us 17 years to build rather than buy our own solution to BI and data analytics, however. Would I do it again? Hell no. I’d buy.
