My career has included successfully delivering numerous software products to market.  These were fat-client, Android/IOS, and web-based apps delivered as both SaaS and on-premises.  While early products were developed using waterfall methodology,  I am a trained Agile Scrum master and Agile Product Owner.

I have been in numerous roles for each,  full-stack front end developer,  backend DB/API, developer team lead,  product owner, and customer success. As such, I am very familiar with the entire SLDC of a software product, what it takes to deliver a product, and what it takes to be successful in the marketplace.

Software products I have developed and managed were:

  • ERP  – order processing, purchasing, Inventory, fullfillment, finance
  • Healthcare payor side – claims payment,  medical claims encounters, actuarial
  • CRM – lead intake through delivery and billing including IOS and Android supplemental applications
  • Loan and funding – consumer finance
  • DoD – U.S. Navy Supply System
  • Education – class and student scheduling

Besides a variety of vertical markets, the software products were delivered in a number of architectures.  Each of these architectures provides unique challenges.

  • on-premises – installed locally and managed entirely by the client
  • on-premises managed – installed locally but managed by the vendor
  • cloud hosted – off-premises servers at a hosting company
  • SaaS – cloud hosted and managed by the vendor

Each architecture style brings with it both advantages and challenges and it is important for product leadership to understand the environment the product is used in.  

Some examples:

  • a software product delivered as a SaaS product means the vendor controls all the backend servers.  Developers can be more narrow in the tools and code libraries because the impacts of external items such as server OS and version,  installed libraries,  runtime versions,  are all managed by the vendor and can be controlled.

    An on-premises installation, however, is managed by the client. Their internal policies may mandate 24 hours installation of zero-day patches which could break the vendor software or they may not be deploying the latest generation of a server OS or  SQL database because of other in-house needs.  The vendor software has to be designed with supporting this in mind.

  • a mobile application may be used for updating customer data.  If the customers will be using the applications in areas with poor to zero cellular reception  (such as rural areas or basements),  it is important for the software to be able to work “offline” and then sync with the cloud when connectivity is restored.