2 years ago

Managing the future of the Brand iQ product

Stuart Cripps-Schnoor

post image
Building a scalable and maintainable SaaS product creates many challenges and how these are managed can affect the success and quality of the product in the long-term. 
My view is building the right foundation in the product and ultimately, the right culture. 
From a strategy and development perspective, the product will drastically improve itself, improve team morale and create more value for your business. 
This isn’t something we got right first time and in fact, the combined experience of developing products both for clients and ourselves for over 20 years has helped us to focus our mindset and learn valuable lessons. 
It’s also important for me to note that this approach doesn’t necessarily work for everyone.
Finding the strategy that works for your business and product will require an element of test and learn.
To help you out, we can provide some insight into our own journey so far and how we manage our vision and strategy. 
 

Our Brand iQ journey

The first point to make is that building an application and building a SaaS product are two very different things. 
It’s important to understand the differences and ultimately how your decisions will affect future decisions and opportunities. 
First, we will look at building an application for a client.
When building an application for a specific project that you are being paid for you will most likely base your tech choices and functionality on:
  1. How much are you being paid? 
  2. What is the quickest way to achieve the desired results?
  3. What is the lifetime of the application? 
  4. How many people do we expect to use the application? 
Your main concern is going to be “how do I deliver an application that is fit for purpose in the shortest possible time, therefore retaining as much profit as possible?” 
It’s likely that when updates are required, you will be paid additional fees and the shelf-life of the application isn’t likely to be long. 
From a development perspective, this also makes the choice of framework simpler as you can always change this for the next project if it doesn’t work as expected.
This is in stark contrast to building your own SaaS solution. 
The considerations are far greater and can have a larger affect over the success of your product.
You should consider asking yourself the following:
  1. What framework can I use that will be well supported, maintained, and attractive to continue working with for both the company and potential employees?
  2. Are there potential purchasers for the product and is it going to make enough money to continue the development effort?
  3. What is our long-term vision for the product and where do we want it to get to?
  4. What infrastructure are we going to put in place to ensure it remains scalable?
These questions will ultimately influence the technology choice, but there are also other areas to consider that will also have effect on the profitability and sustainability of your technology business. 
  1. What is the revenue model going to be?
  2. What infrastructure are we going to put in place to ensure it remains scalable?
  3. How will we market the product to attract customers? 
Once you’ve decided what technology stack you’re going to use, the next thing will be to understand how you will deploy your first version and ultimately, what that version will include. 
My advice here would be to start as simple as possible.
Plan out what you think the product needs to do as a minimum and stick to that. 
Don’t get to focused on “what it could do?” and “wouldn’t it be great if…” From my experience, you will end up chasing your tail and never end up making your product live. 
Once your minimal viable product is live, it’s then time to develop your strategy for how you will continue to develop and maintain the product and choose how you roll out new updates. 
From our experience the most important thing to remember is that it’s your product.
You must control every aspect of what is built and when its built, as you are the only ones who understand the impact and the effects of new functionality and changes. 
Ultimately, your roadmap will still be driven by your clients and prospective clients as their needs are what will shape the product and make sure it continues to add value and drive new sales. 
However, managing this in the right way will ensure you remain on track and focused on the product you set out to build. 
We find the simplest way to manage this is to run an overall roadmap that consists of what you want to build (basically your vision for the product) and then manage a simple process of “feature requests” from your clients. 
You can then judge the priority of these based on the below factors:
  1. Is it the first time the request has been made or do you have many customers wanting the same thing?
  2. Is it related to an area you already have work planned for and therefore it can easily fit in?
  3. Is it something that you already have on the roadmap and therefore it can be re-prioritised? 
It’s also important to manage the feature request process with your customers, so they don’t feel like it’s just a black hole.
If you’re going to consider the request then let them know, it doesn’t have to mean a commitment on the timescale but it’s a positive indication that you will be working on it. 
If you’re not going to entertain it at all then let them know it’s been rejected and why. It’s far easier to manage that process upfront and explain why it’s not valid at that stage in the product lifecycle. 
Finally, we come to what we consider one of the most challenging elements to developing a product:

What methodology do you employ to shape, scope and then ultimately build the required functionality

We’ve experimented with many different methods over the years - e.g., writing a very clear and concise specification with no areas for manoeuvre, which sounds great but in reality, you never capture everything, and it can often stifle the quality and agility of the functionality you’re developing. 
In contrast, giving the development team free reign can also work against you as many options get explored and rabbit holes dug meaning things take even longer and might not be exactly as expected 
Through these experiences we believe we now have a better method although one that is continually refined and improved where possible. 
  1. We create a high-level brief for the functionality, which really is a one pager about what the functionality needs to achieve/do
  2. We then try and develop out the logic flows and use cases for the functionality to make sure we’ve considered all avenues
  3. Often, we will create a basic UI of the main interactions to give the dev team something to work to, but also to check we’ve covered all the user flows and logic
  4. We then give the development time a set period to develop the minimum viable product (not the fully featured vision) 
  5. Once we have the MVP and it’s been fully tested, it can be deployed, and the feedback process can start.
  6. This will then give us the “real” environment testing that can help us continue to iterate and improve the functionality, if we feel it’s required
Based on our 20 years of experience developing both client-side applications and our own SaaS products, we’ve settled on a solution that works for us and our clients and ultimately is helping us develop, maintain, and deploy our product to the market. 
My biggest advice would be to continue to question, test and improve your processes of development to ensure you find what fits best for you, your product, and your clients. 

Book a demo with us to find out how Brand iQ can work within your organisation.
hello@brand-iq.co.uk
Brand-iQ logo icon

Follow us

© 2024 Brand iQ Technologies. All rights reserved.

Privacy Policy

Brand iQ UK Operated By Brand iQ