CITADEL
Building a SaaS solution that simplifies security and compliance in the cloud
How might we make the accreditation process simpler, faster, and cheaper than it actually is, leaving customers to focus on what matter most: their business?
The Citadel Business
Citadel is a Software as a Service (SaaS) solution for managing your Amazon Web Services (AWS) cloud infrastructure. It allows customers to remove the complexity and easily create, manage and maintain resources whilst being audit-ready, highly secure and compliant with industry standards such as SOC 2, ISO 27001, HIPAA, PCI DSS, and CDR (Consumer Data Right).
1 -Market Analysis
Two years ago, Citadel was only an idea. I was there working at DNX Solutions, which is the main Citadel’s investor until the moment I was writing this case study, listening to people saying that there are a lot of things on DNX Solutions that could be automated, providing huge benefits for both business and customers. From the business side, we could build a digital product that scales up, from the customer side, having a solution that simplifies their lives, reduces costs, and accelerates the cloud journey, sounded amazing and we would be crazy if didn’t look at this opportunity.
However, when we talk about the cloud, the opportunities are endless. When we consider AWS (Amazon Web Services) cloud, it becomes impossible to track everything. AWS has over 200 fully featured services for a wide range of technologies, industries, and use cases. This broad set of global cloud-based products includes computing, storage, databases, analytics, networking, mobile, developer tools, management tools, IoT, security, and enterprise applications.
So, what is the best way to pick an industry, sector, service, tool, or user to start my data analysis?
As a good designer, I started listening to people and stopped making poor assumptions. As I told you, I used to work at DNX Solutions at that time we were building a new offering called CDR (Consumer Data Right) - Open Banking. You might or might not be familiar with this term, but basically, it’s a legislative, regulatory, and standards framework for consumer data portability in Australia. This framework has been created and introduced by the Australian Government, which is implementing the framework on a sector-by-sector basis. The first sector to adhere to CDR was the Banking sector and it directly impacted three stakeholders.
- Big Banks: they are the four major banks in Australia and they are called ‘Data Holders’. The name is pretty obvious as these four banks hold the majority of bank accounts in Australia.
- FinTechs: institutions responsible for providing banking experience by developing new-age financial products and services. They were entitled ‘Accredited Data Recipients - ADR’. They seek to access the consumer’s data which can be used for improving services and acquiring more users for their products.
- Customers: have the ability to share their banking data with third parties such as FinTechs that have been accredited by the ACCC (Australian Competition and Consumer Commission). This allows customers to get better-suited banking products and switch products or banks more easily.
Clearly, we can see a huge benefit for customers that don’t need to fill out lots of papers every time they want to change a financial provider, and only authorise the data holder to share their data with the FinTech provider. The second beneficiary of this regulation is the FinTechs as they now can access consumer data to simplify and accelerate their customer acquisitions or customer onboarding process. However, accessing consumer data is not easy as it sounds. They need to be Accredited Data Recipients, which means being audited and proving you have the necessary security to receive and hold customer data.
That’s where the Citadel’s story started and how I left DNX Solutions to start working as a Service Designer and Project Manager at this company.
2 - Market Analysis
Definitely, companies on the run to become Accredited Data Recipients (ADR) are the main focus as they see more value than obligations for the business. That’s why Financial Services Industry (FSI) is on the top list. Another industry we considered at the time was HealthTech. The reason why is that when we created a solution focused on protecting customer data, it might be used for other standards that follows the same security principles, such as HIPAA, SOC2, and ISO27001, which are standards that healthcare needs to be compliant with.
Financial Sector Industry:
- The most common sub-segments in this industry: Payments, Verification, Wealth & Investing, Personal Finance, Financial Planning, Lending, Credit & Broking, Buy Now Pay Later, and Digital Native Banks.
- Business size: Startups/scale-ups and SMBs, between 10–200 employees. Revenue: < 1M (33%) - 1M-5M (25%) - 5M-10M (8%) - 10M-25M (15%) - 25M (7%) - Not applicable (12%)
- Capital: About 41% raised capital in the previous 12 months and 21% between 1–2 years. 30% have not raised capital so far.
- Location: <NSW (60%), VIC (22%), QLD (10%), SA (5%), WA/Auchland (1% each)
- Customer examples: Spriggy, Stake, Zestmoney, Symple, Airwallex, Fin-Pay, Payble, PayOk, Deferit, InDebted, DiviPay,Koba, Cache, , Verifier, Adatree, Bill Identity
As CRD has been expanded to Open Energy and Open Telco, these are sectors that will drive an increased demand soon, however, it was not considered for this content.
HealthTech Industry:
- The most common sub-segments in this industry: Awareness, Treatment, Prevention, and Clinic Workflow are the most common.
- Business size: Startups/scale-ups and SMBs, between 10–200 employees, turnover between 1M - 25M>
It’s more than 400 companies that did an initial public offering - Location: Sydney and Melbourne, followed by Adelaide and Perth
- Customer examples: Coviu, Medinet, Perx Health, Cochlear, HotDoc, Mosh, Strenght By Numbers, myDNA, Scalamed.
3 - The Challenge
FinTechs started a fast run to access consumer data and suddenly the technical side became the most critical topic to be addressed. I’m saying that because most startups are improving their business while building it. As they are validating market fit sometimes they are more concerned with selling, acquiring new customers, and releasing new features than looking at security and compliance in depth.
But now it’s different. To become an ADR, these companies must demonstrate they are a fit and proper person/organisation to manage Consumer Data Right data and are able to take the steps required to adequately protect CDR data from misuse, interference, loss, unauthorised access, modification or disclosure. It means they need to invest time - lots of time - and money to achieve it, not to mention the burden of managing a project like that, which means managing auditors, technical providers, internal teams, and budgets, only to mention a few.
I remember thinking, “It is exactly what we are looking for”. From that, we came up with our first assumption of what could be our problem statement.
How might we make the accreditation process simpler, faster, and cheaper than it actually is, leaving customers to focus on what matter most: their business?
4 - The Design Process
I know that applying design approaches to build a digital product is not something we do in weeks, sometimes not even months. But believe me, it becomes more complicated when we are building a new company, instead! That is exactly what we decided to do: set up and run a new business, following the best practices that startups have been using.
Hold a second, what about validating it before start building something? No worries, we did that by applying the three lenses of innovation: desirability, viability, and feasibility.
4.1 - Desirability
As I previously mentioned, I became aware of customer complaints during my time at DNX Solutions. If we want to address these complaints, a logical first step would be to listen to these customers and it was exactly what I did.
As part of this phase, I considered the anatomy of an interview guide as I got used to it and I don’t like to see myself stuck with closed questionnaires, rather than that I prefer only a guide that will flow as the interview goes.
The main personas I interviewed were:
- Current customers: to address the problems and opportunities based on what they have experienced.
- Potential customers: to understand the decision-making process, concerns, pain points, feelings, what prevents them to make a decision, and so on.
- Partners: while delivering projects with DNX we realised that these providers such as Auditors, Independent Software Vendors, and Consulting companies would be essential to deliver what we intended to, as they were part of the whole problem.
- AWS: as we intended to build a solution for AWS customers, which scales up the product quickly, AWS was a key stakeholder to be considered.
- Employees: to understand what we could be done differently, what could be automated, how was the experience while delivering a project like that was, and so on.
Data Analysis & Validations
After gathering and analysing all qualitative and quantitative data from market analysis and research phases, I finally started to materialise our learnings and discoveries.
At that moment, I was able to complete our first design tools such as personas and customer journeys and validate our problem statement, which fortunately has changed nothing. Yes, we were right about the main pain points.
At a high level, they are:
- CEOs of startups and SMBs.
- Technical Decision Makers
- Developers and Operators
- Partners: Auditors and ISVs
Persona Example
Customer Journey Example
Service Blueprint Example
Problem Statement
How might we make the accreditation process simpler, faster, and cheaper than it actually is, leaving customers to focus on what matter most: their business?
4.2 - Viability
I like to consider a viable product something that makes economic sense, in other words, it needs to be profitable - at least based on Citadel goals. After analysing the potential of the market - more specifically FinTechs and HealTechs industries - I started provoking the team to build our Business Model as it pushes the team to think about things like value proposition, mission, competitors, goals, target, and so on. I also leveraged the opportunity with the team to create our Product Vision and the Product IS - IS NOT - DOES - DOES NOT DO canvas.
4.3 - Feasibility
On the feasibility side, we have analysed all the critical aspects of building the solutions we intended. However, as most of the solutions are already delivered by DNX Solutions, for instance, we knew it wouldn’t be a concern. The more in-depth analysis we made was related to AWS APIs as part of the solutions to create a cloud infrastructure in the AWS cloud without the need to access the AWS console for it.
The Citadel Design Process
After validating customer needs, seeing an opportunity as a business, and understanding technology would not be a high concern, I was free to start thinking about the digital product solution. However, we knew a lot about the potential solution Citadel could become, but at that moment I was more concerned about giving a product roadmap, building a prototype to be tested, and then having an MVP to be released.
5.1 - Lean Inception
To achieve it, I suggested to the team to run a Lean Inception Workshop. It’s a one-week workshop focused on aligning people and building the right product or MVP, to be more specific it is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a workshop divided into several steps and activities that will guide the team in building the ideal product.
The agenda covers topics related to business, UX and technology:
- Product Vision
- Product Is-Is Not-Does-Does Not Do
- Persona
- Feature Brainstorm
- Tech, UX, and Business Review
- User Journeys
- Journeys & Features
- Sequencer
- MVP Canvas
- Showcase
After running our Lean Inception Workshop we would be able to see our Miro board completed with a clear view of what we intend to build as a MVP.
As I have already covered a few tools earlier in this article - Product Vision, Is-Is Not-Does-Does Not Do, Persona, and Customer Journey - I’ll share briefly the new ones we literally built from scratch over Lean Inception Workshop.
Technical, Business & UX Review
After either building or only validating the Product Vision, what the product Is-Is Not-Does-Does Not Do, Personas, and User Journey we ran an ideation process to come up with potential features and ideas that might or might not become part of the solution later.
With all those ideas on our Miro board, it’s time to evaluate and review those ideas. The focus of this activity is to discuss how the team feels about technical, business and UX understanding for each feature. New clarifications happen and disagreements and doubts will become more apparent.
Sequencer
The sequencer assists in organising and viewing the features and the incremental validation of the product. There are rules to follow that helped me to ensure we are building our product sprints in the right way.
MVP Canvas
MVP Canvas is a visual chart that helps the team to align and define the MVP, the simplest version of the product that can be made available to the business (minimum product) and that can be effectively used and validated by the end user (viable product).
5.2 - The Ongoing Process
With everything in place, I started organising the design process that we need to follow to ensure we are updating documents and building the right solution still.
I’m not going to focus on everything here, however, I want to highlight a few processes such as the user flow the prototyping phase, and how I hand over things to the product development team.
Upstream process
Everything I explained until this point is considered upstream projects/processes. The name is because I was more focused on discoveries and validations and it’s the precursor to the product (development team).
User Flow
To finalise the upstream phase, based on the features sequencer we created in the Lean Inception Workshop, I start to create the user flow for each feature, see examples below.
Prototyping & Usability Testing
After testing and validating the user flow I started creating the prototype on Figma, which later would be tested with customers to be improved, basically, I ran the iteration process at this point. See examples of the prototype in Figma.
Downstream Process
Having approved the feature with the user, it’s time to build the feature, I mean to develop it.
To hand over my job to the development team I used use ClickUp as a project management tool. BTW, the developers were familiar with everything as they took part in the Lean Inception Workshop to decide about technical impacts and come up with different ways to execute it. I like it, as it makes my job much easier.
We used to work with sprints, moreover, we had a daily sync to align what needs to be done and how we were evolving with what we have compromised ourselves. As soon as we finished a sprint, we looked at the sequencer to define which features will be part of the next sprint. While developers were working to build and release features, I was working on the upstream process to generate more features that would be developed later.
It became our ongoing product design and development process.
