At Cemplicity, we’re a SaaS (Software-as-a-service) platform. There are many practical advantages for organisations to use SaaS including reduced cost-of-ownership, simple in-house IT capability requirements, low maintenance effort and a streamlined procurement process. I’m not going to talk about this well-documented list today but instead will focus on a more subtle and harder to quantify aspect often overlooked in the SaaS value discussion.
So, what am I talking about then? A good SaaS platform is Evergreen; it’s living and breathing, it learns, it evolves, it even solves problems you might not know you have yet! A good product design helps you fall into the pit-of-success by giving you best practice ways of doing things and avoids you from re-inventing your wheel – saving your organisation precious time and energy.
The SaaS model is not magical, the lofty statements above do not just happen, but it often shakes out this way when you have continuous Research & Development investment coupled with a strong Product Management & Design function supporting your platform.
So how does Cemplicity make this happen? We have a skilled, experienced and collaborative product team, but that’s not enough by itself. I’ll outline a few of the things we strive to do very well.
Balancing new functionality with increased platform complexity
At the extreme end of this continuum, if we developed everything requested of us it would not be a pretty outcome. Our product would be over complicated, our implementation team would take months to set-up a client and our development team capacity would regularly be consumed by a single customer’s wish-list.
Every piece of development adds incremental complexity to our platform. Our product team’s aim is to make sure the cost of the complexity is worth the value it adds to all of our customers – or else it’s usually not a good trade-off. One of our approaches here is to apply the 80/20 rule (Pareto principle) to develop the 20% of requested features that provide 80% of the value to the majority of our customers. This thinking is the top reason when we choose to say “no” or “not now” to a customer feature request.
Partner product collaboration and co-development
We work closely with partners when extending our platform feature set. We recognise evolutionary product development is the best way to produce valuable software, and getting direct fast feedback loops from a variety of clients is critical. This validation approach will help get us a great outcome, and other customers will leverage this exceptional ready-to-use functionality out-of-box with the magic of SaaS!
Some recent examples of this co-design approach are the PROMs visualisation work we did with Southern Cross Health Society and more recently with North West Melbourne PHN in our PROMs Clinician portal.
We leave our preconceived ideas and egos at the door
We all have personal biases, some we’re aware of, other we’re not. With this front-of-mind, I want to outline one more thing we do well at Cemplicity. We don’t come into the design process (partner or internal) with a formed solution. It’s far too easy for smart people to think they know what the answer is and you risk leaving better solutions unexplored. To avoid this closed thinking, we spend a lot of time focussing on the problem domain and our User Personas, often spending days concentrating here before we move towards the solution and our delivery planning. We regularly use “our take” on Google’s Design Sprint methodology as the mechanism to facilitate this thinking and encourage our co-development partners to do the same thing.
These are some of the things we do to make Cemplicity a vibrant evergreen platform, where our customers benefit from the healthy SaaS ecosystem we nurture.
It takes great product teams and great customers to make great SaaS.