Background – In today’s’ fast paced digitally connected world as ideas germinate within the minds of entrepreneurs there is a demand for application platforms that help reduce the time to market. Most entrepreneurs realize that in this digital world there is a small window of opportunity and to be able to address that small window of opportunity they have to move fast with not just a suitable go-to-market strategy but also a very strong product/service strategy. And at the core of a successful product/service strategy is inevitably a scalable platform that delivers the required functionality combined with excellent End User Performance. To deal with the complexity of developing such scalable platforms in ever compressed time frames where requirements keep evolving, we have developed a few different approaches to address some of the issues we’ve mentioned above i.e. Agile Development practices, DevOps, Continuous Integration, BizOps, Web Operations & Performance, etc.
Wouldn’t it be just great if while we built systems the teams who were responsible for developing the system i.e. the Architects, Developers, Functional Testers, Performance Testers, Infrastructure experts, Network experts, Storage experts, etc. could be forced to experience the pain that the customer would eventually face when they used the solution. Getting the project team i.e. the Architects, Developers, Functional Testers, Performance Testers, Infrastructure experts, Network experts, Storage experts, etc. to experience the pain upfront i.e. pain due to a poorly designed system, pain due to a poorly performing system, or whatever the pain might be, could potentially go a long way in helping the project team realize the importance of building a solution that works efficiently and more importantly deliver a solution that not just meets business’s expectation but exceeds it.
While in this article we will not focus on the various trends that are shaping development practices, the intention of this article is to call out some of the more fundamental practices that entrepreneurs should keep in mind when launching their own MVP (Minimum Viable Product) with a view to building products/services that not just meet customers expectation from a functional standpoint but also with regards to performance and scalability.
Approach – Let’s look at the various different dimensions you might want to consider when building your MVP and scaling it out to meet your customer’s needs. An MVP can be described as follows –
From Wikipedia (https://en.wikipedia.org/wiki/Minimum_viable_product) – In product development, the minimum viable product (MVP) is a product which has just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than using a product with more features which increase costs and risk in the case where the product fails, for example due to incorrect assumptions. The term was coined and defined by Frank Robinson, and popularized by Steve Blank, and Eric Ries. It may also involve carrying out market analysis beforehand.
We understand an MVP (Minimum Viable Product) is what it is i.e. an MVP and you obviously want to avoid boiling with ocean over unless you’ve ascertained that the idea of yours really has some legs. Some of the recommended dimensions below might be an overkill for your product/service so think through what’s relevant for you and your MVP (Minimum Viable Product).
Here’s a look at some of the relevant dimensions that you might want to consider –
- Do I have the right set of Non Functional Requirements for my MVP (Minimum Viable Product)? An example of some relevant Non Functional Requirements or NFR’s are scalability, failover, high availability, security, reliability, etc.
- Do I understand the relevant aspects of Non Functional Requirements that are important to my MVP (Minimum Viable Product)?
- Am I building into my solution components that lock me down to a particular Cloud Service Provider
- Am I incorporating suitable and agile development practices i.e. DevOps, Continuous Integration, etc.
- Is it possible to integrate performance validation into the Continuous Integration processes for my product/service?
- Do I have suitable monitoring and diagnostic tools to monitor the underlying infrastructure/networks/storage that proactively sound out any potential issues before they turn into show stoppers
- Do I understand the need for an APM (Application Performance Monitoring) solution
- Have I mapped out the APM (Application Performance Monitoring) or NPM (Network Performance Monitoring) tools required to understand the customer journey and map our the customer experiences see by my customers in the real world
- Have I thought through the need for a Performance Test to validate scalability/performance of the products/services we intend to launch
- Do I understand the capacity requirements as my customer base increases and the product/service platform needs to scale
- Do I have the right capability to manage the performance of the platform and complement the development capability that I already have
- Are my operations support team, development team and performance management team all talking to each other.
Don’t treat the above list of questions as an exhaustive list but rather a set of questions that should get you thinking in the right direction. Also, as we’ve mentioned earlier not all of the dimensions we’ve listed in this article might be relevant to your MVP (Minimum Viable Product), so think carefully of the investments you need to make to scale your MVP as your customer base grows. The intention of building an MVP is to get out there, see what the real world is like and most importantly see if what your customers think about the great product or service you wanted to launch.
Conclusion – Those of you who have worked on building, supporting or delivering complex systems realize the importance of building for both Functionality and Performance. Performance of the underlying system is as important as the functionality your customers expect. Scaling your MVP (Minimum Viable Product) requires focus on not just the underlying business model, the underlying service delivery capability, the customer service management capability but also the engineering capability to deliver products/services that scale and deliver a great End User Experience.
Trevor Warren (Linked In) loves hacking open source, designing innovative solutions and building communities. Trevor is inquisitive by nature, loves asking questions and some times does get into trouble for doing so. He’s passionate about certain things in life and building solutions that have the ability to impact people’s lives in a positive manner is one of them. He believes that he can change the world and is doing the little he can to change it in his own little ways. When not hacking open source, building new products, writing content for Practical Performance Analyst, dreaming up new concepts or building castles in the air, you can catch-him bird spotting (watching planes fly above his house).
Practical Performance Analyst as an Open Body Of Knowledge on Systems Performance Engineering (SPE) built + maintained by Trevor with the support of his army of volunteer elves (PPA Volunteers). You can reach trevor at – trevor at practical performance analyst dot com. The views expressed on this web site are his own.