This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

# Phase 3: Minimum Viable Service (MVS)
<a name="phase-3-minimum-viable-service-mvs"></a>

 Once you have built and validated your business planning and product strategy, you need to start thinking about what will be included in the first rollout of your SaaS offering. The Minimum Viable Service (MVS) is the first version of your offering, with just enough features to effectively deploy the product and attract early adopters to provision their footprint in your offering before selling it successfully to the mass market. It is a cost-effective way to collect early user feedback for future product development until a desirable product/market fit is obtained. This strategy is especially important in a SaaS model, which presents opportunities to engage with customers repeatedly throughout their lifecycle. At this stage, the delivery team, on both business and technical, is ensuring the required pieces to productize and operate the service. This effort might look quite different for different company profiles. For some, this may be about finding a scope of changes that can begin to lay the foundation for moving to SaaS. For others, this will be more about the features that will represent a minimum set of functionalities needed to offer something to the market. Your company may be going through a transformation to deliver a customer facing product and, in this phase, you are thinking about how you plan your delivery to ensure the success of the entire companies. 

 It is important to highlight one key principle of the MVS model that is pulled directing from the world of agile development. The goal of identifying an MVS is to find a minimal scope that will enable you to focus on an initial milestone. The features and capabilities of this MVS could be released to a customer, if decided. This means all the moving parts of the customer, operational, and company experience need to be included in this offering. It does not mean that you will actually release the MVS to the market. That decision is deferred until you get closer to having a working service. As you approach completion of the MVS, you will then decide whether or not you want to go forward with releasing this version. The purpose of every MVS should be to deliver a clear value to a particular customer use case. If you decide not to release the MVS to your early adopters, then you begin to look at the next collection of features and experience that will be needed to close that gap. Additionally, MVS enables us to focus on getting all the moving parts of releasing a product done without getting lost in whether this combination is the best fit for the market, which could change while you are building the MVS. At the same time, use this moment to challenge yourself to find the minimum set of capabilities that could be needed. 

**Topics**
+ [Entry Point](entry-point-2.md)
+ [Key Activities](key-activities-2.md)
+ [Guiding Questions](guiding-questions-2.md)
+ [Factoring in your Company Profiles](factoring-in-your-company-profiles-1.md)
+ [Who Should Participate?](who-should-participate-2.md)
+ [Expected Output](expected-output-2.md)

# Entry Point
<a name="entry-point-2"></a>

 To start this phase, you should already have a good understanding of the general business and product strategy. Specifically, this means a plan to deliver your solution to meet the needs at or before launching the MVS to a set of customers. Think about how your path to the customer also transforms the entire company responsible in delivering this solution. Once these foundational concepts are filled in, you are ready to begin asking questions about the scope and goals for an initial offering. The phase of the journey requires you to balance the long-term goals of the business with the near-term realities of finding a solution that will enable your solution to get into the market and begin to pivot based on actual customer feedback. The key is to find the collection of capabilities that represent value to your customers without committing to a delivery schedule that may cause you to miss your window of opportunity. 

# Key Activities
<a name="key-activities-2"></a>

The activities for an MVS are about defining a clear near-term deliverable that encompasses everything you would need to build, operate, and support this service. This is where thinking of this through the lens of a service is a key differentiating aspect of this exercise. While the activities for defining your MVS will likely differ significantly across different domains and starting points, this section captures some of the concepts that are often included in this exercise: 

![\[Diagram showing the MVS cycle of development.\]](http://docs.aws.amazon.com/whitepapers/latest/saas-journey-framework/images/mvs-cycle-of-development.jpg)


## Defining the Target Early Adopters for the MVS release
<a name="defining-the-target-early-adopters-for-the-mvs-release"></a>
+  **Goal**: Define the specific users and roles that you will target with the MVS. This may be internal and/or external users. 
+  **Outcome**: A clear list of early adopters that you expect to support with this initial release, along with any qualifiers that might narrow the scope of the experience (initially) for them. 
+  **Key Decision Point**: Can the MVS target a subset of the target users/tiers that will ultimately need to be supported by the system? Will narrowing to a smaller set of users/tiers undermine the success of your system? 

## Outlining the Minimum Product Functionality
<a name="outlining-the-minimum-product-functionality"></a>
+  **Goal**: Based on the tiers/personas you will target; define the set of product functionality you will need to include for this offering. 
+  **Outcome**: Capture high-level notions of key product features that will be needed to support the scope and customer targets you have identified. This is not about being granular, it is about defining high-level concepts that you see as core to this solution. 
+  **Key Decision Point**: Have you identified a set of features that will be viable for the target users you have identified? How will these features enable you to attract and retain customers? Which capabilities may need to be included as part of making this available in a service model? 

## Outlining the Minimum Operational Experience
<a name="outlining-the-minimum-operational-experience"></a>
+  **Goal**: Define the elements that will need to be put in place to successfully operate this solution. 
+  **Outcome**: A well-defined view of the operational experience that includes tooling, processes, and insights that will be needed to support this new environment. The emphasis here is on automating and streamlining the operational experience to lay the foundation for rapid innovation, agility, and market response. 
+  **Key Decision Point**: Do you have the tooling, skills, and experience needed to build a best practices operational experience? What will you do to ensure that operations and agility are prioritized within your overall culture and development process? 

## Target Feedback Experience
<a name="target-feedback-experience"></a>
+  **Goal**: Determine how you will engage potential customers to capture feedback on your minimum viable service. 

**Note**  
This could be in many forms and not necessarily a feature you are building (e.g. interviews, forms, real-time, or offline). 
+  **Outcome**: Selection of a strategy that defines how and if you plan to incorporate users into your MVS development lifecycle. 
+  **Key Decision Point**: Will you have customers integrated into your process during the active development? How will you expect to identify the customers that will engage in this process? 

## Defining Core SaaS Tenets for the MVS
<a name="defining-core-saas-tenets-for-the-mvs"></a>
+  **Goal**: Capture and document the core tenets that will define where the SaaS bar is being set for this initial offering. This is important to ensure success at each delivery. 
+  **Outcome**: A list of the tenets that outline precisely which goals you are targeting for the business, operational, and agility attributes of this minimum viable service. The challenge here is to have your sights on general SaaS best practices while still acknowledging that you may not target the longer-term experience for this MVS. Being clear about this is essential to defining where the bar is. 
+  **Key Decision Point**: Which compromises you are making in this MVS? How those compromises will impact the success and agility of your overall SaaS story (this is about forcing your team to agree on these goals and boundaries)? 

# Guiding Questions
<a name="guiding-questions-2"></a>

 To help with this exercise, we have outlined a number of questions that help collect the data that is needed to shape your MVS vision. The questions represent an example of the concepts that are commonly part of this discussion. However, there are likely questions that are unique to your domain/market/opportunity that will need to be added to this list. 

## Defining the Target Early Adopters for the MVS release
<a name="defining-the-target-early-adopters-for-the-mvs-release-1"></a>
+  Which customer personas (from the broader list of personas) are you targeting with this solution? 
+  Will you be supporting a product tiered model and which tiers will be included in this MVS experience? 
+  Are there enough customers in this target set of personas to drive the adoption you will need to drive the platform forward? 
+  How many customers do you expect to add as net new customers for this offering? 
+  Are there specific scaling and performance considerations that need to be considered for this population of customers? 
+  Are there concerns about how this offering will be positioned against any other offerings that might be in your portfolio? Are there clear boundaries between the offerings that will limit any confusion for the market? 

## Outlining the Minimum Product Functionality
<a name="outlining-the-minimum-product-functionality-1"></a>
+  What are the primary functional attributes of this SaaS service offering? 
+  Which features (if any) will be used to draw clear boundaries between personas/tiers? 
+  Are there specific performance requirements that will be part of this service? Will you use performance as a way to distinguish tenant tiers? 
+  Will customers impose any specific requirements around security and data protection? 
+  What will be the registration process for introducing new tenants into the system? 
+  Will you offer a demo or free trial version of your product? 
+  Do both delivery and business teams understand what you are planning to deliver? Is there alignment on what the delivery approach is? 

## Outlining the Minimum Operational Experience
<a name="outlining-the-minimum-operational-experience-1"></a>
+  What are the non-functional attributes of the service offering? 
+  What are the non-functional attributes that of this service that will enable/promote operational efficiency and agility? 
+  What are the metrics (if any) will you be collecting to gather insights into the consumption and activity of your customers? 
+  Will you track service-level agreements (SLAs)? Are there specific SLAs you will need to meet for customers? 
+  Are you expecting to have a zero-downtime policy for this service? 
+  What strategy or mechanisms will be in place to migrate changes to data representation without incurring downtime? 
+  What tools and processes will be used by your operational team to proactively detect and manage tenant issues? 
+  How will customer report issues? Will this be an interactive experience? 
+  Do you expect to have a customer success company in place for this MVS and how will they be integrated into the broader operational experience? 

## Target Feedback Experience
<a name="target-feedback-experience-1"></a>
+  What data will be used to assess the customer’s perspective on this new service offering? 
+  Will targeted customers be enables to provide feedback during the development process? 
+  How will you identify customers that will participate in this process? 
+  Will you be able to engage customers from segments you may not target today? 

## Defining Core SaaS Tenets for the MVS
<a name="defining-core-saas-tenets-for-the-mvs-1"></a>
+  What are the key business and technical tenets that will guide your implementation of this MVS? 
+  What near-term tradeoffs will be made to get to market at a faster pace? 
+  How will these tradeoffs impact the customer experience and long-term viability of your solution? 
+  What measures are part of this MVS to ensure that the company is enabling the operational efficiency and agility that will be needed to support the growth and innovation of the platform? 

# Factoring in your Company Profiles
<a name="factoring-in-your-company-profiles-1"></a>

 **ToeDipper Software:** This company type tends to focus on a niche market and might under-invest in a complete product strategy with the assumption that this is more of an experiment. While it may not seem normal for these companies, there is still great value to be extracted from having a solid product strategy. Answering some of the hard question about tenant profiles, compliance, data isolation, and tiering will help you be hyper-focused on where this new niche is, and which dynamics you will need to think about as you are defining the capabilities, experience, and value proposition of your new SaaS offering. 

 **SurvivorTech:** This company type needs to have a clear picture of the product strategy to effectively compete against current and emerging offerings. The key is to have a strategy that goes beyond just having a SaaS offering. The companies need to find the tiering and value boundaries for their offering that will enable them to retain and grab market. A carefully considered product strategy will enable these companies to map out a more complete survival path that is less reactive and more strategic. 

 **UnicornExpress.com:** This company type tends to share some traits with the SurvivorTech profile in that these companies are often so driven to acquire customers and generate revenue that they too will short-circuit the product strategy process. While the pressures to get something out is real, the danger is that executing without a clear product strategy may undermine the company when the growth curve kicks in. If you have left tiering, compliance, and many of the other factors outlined here out of your vision, you may find yourself struggling to address the needs of the market and fully maximize this growth. 

 **New Horizons Software:** This company type must look at the product strategy as if creating a new line of business. The real difference is that these companies are not necessarily facing the financial and time pressures that you see in a startup. These companies may also have to form new teams that can operate separately from the rest of the company as they build their new SaaS offering. 

# Who Should Participate?
<a name="who-should-participate-2"></a>

 This part of the journey is about the actual company transformation and change management. Ultimately the entire company will be impacted and will require adoption of this journey, however, how and when parts of the company participates depends on your company profile, what you are building and launching, and how many steps to customer adoption you are defining. Product teams would play a key role in this part of the journey with program management. The leadership team would also play a role to ensure there is oversight and all teams are building and delivering to the promise of the defined state. As you define the MVS and get feedback, it will determine who should be involved in this phase. For example, if you are launching a new onboarding experience, the product, sales and marketing teams should be involved. Additionally, support and customer Success would also be informed as part of continuous support. If the strategy is to target new segments and customers, all teams would be involved. 

# Expected Output
<a name="expected-output-2"></a>

 The outcome from this phase is an MVS release with clear definition and expectations of the launch. The MVS release itself is not the end of this section of the journey, but a start of one, or one of many, next steps to ensure a data-driven and customer-focused roadmap that drives continuous improvements. Failure of an MVS release does not mean a complete failure, but yet another data point to help re-align and focus.