Step-by-Step Guide To Successfully Creating and Launching an Saas Product

ContentsThe Anatomy of a Strong Market Requirement Document ...........................................................................................................4High-Level Requirements ......................................................................................................................................................................................................................6Persona Definitions ....................................................................................................................................................................................................................................7Major Feature Sets ....................................................................................................................................................................................................................................9Writing and Executing Great User Stories ..........................................................................................................................................10User’s Perspective ....................................................................................................................................................................................................................................... 12Simplicity ............................................................................................................................................................................................................................................................. 12Epics ....................................................................................................................................................................................................................................................................... 12Collaboration ................................................................................................................................................................................................................................................... 13Technical Requirements .......................................................................................................................................................................................................................... 13Assessing if Your Company Has the Resources to Execute on the Market Requirements Document .............................14Time-to-Market Requirements ......................................................................................................................................................................................................... 16Resource Requirements ......................................................................................................................................................................................................................... 16Flexibility Requirements .......................................................................................................................................................................................................................... 17Going to Market: Bridging the Gap between Development and Marketing ..............................................................................18Product Boundaries ...................................................................................................................................................................................................................................21Development Strategy ............................................................................................................................................................................................................................21Marketing Strategies .................................................................................................................................................................................................................................22Customer Onboarding .............................................................................................................................................................................................................................23Great! You Have Gone to Market, Now What? ..................................................................................................................................24Validation ............................................................................................................................................................................................................................................................26Innovation ..........................................................................................................................................................................................................................................................26Demand ..............................................................................................................................................................................................................................................................27About Tiempo ..............................................................................................................................................................................................28

3

The Anatomy of a Strong Market Requirement Document

A market requirements document (MRD) is used to define high-level market requirements for a product. It’s usually written by the product manager or product marketing manager and typically includes the product's high-level market requirements.

The MRD is primarily used by the product manager and senior executives to outline the product that's going to be built and the problems it's trying to solve. Other users of the MRD include business analysts, marketing and sales. The engineers define user and technical requirements based on the MRD and the release's goal. They may also use the MRD to create a product requirements document (PRD), depending on the organization. The engineers can then use the PRD to develop the product. Some organizations combine the MRD and PRD into a single document, according to Actuation Consulting. Product managers use the MRD to identify problems that people will pay to have solved and prioritize those problems based on the needs of the user personas.

4

High-Level RequirementsThe increasing consumer expectations in the modern business environment are making frequent communication between manufacturers and customers a more critical aspect of product development. Fritz Morgan, vice president of engineering for Color Kinetics, says, “We generate a market requirements document with initial forecasting information that we use for the first build.” This forecast of features is essential for prioritizing software requirements, especially the first release. Product managers may use categories like “must have,” “surprise and delight,” and “more is better” to prioritize requirements. It’s particularly important to ensure that all “must have” requirements are included in the first release. Must have requirements are based on what the market has identified as must have, not what the product manager has identified.

The MRD should make use of simplifying assumptions to facilitate the communication of ideas to its readers, allowing each reader to determine the MRD’s applicability to his or her unique situation. For example, the MRD for a software application often uses personas that encompass multiple users. A software engineering outsourcing team typically address this layer of complexity by scheduling use cases across multiple releases of the software, since these cases must be enabled for different user classes. Market problems should drive this schedule to ensure that developers focus on the problems that people will pay to solve.

A development team that uses an iterative development methodology such as agile can easily accommodate changes in the must have requirements as the project progresses. A release is based on a combination of budget, features and time, although no release ever meets all three of these requirements. As a result, the development team may need to re-class features as the release date approaches. The MRD can be changed to accommodate these changes.

The release schedule for SaaS software is dictated by the market. This schedule may be shortened if a prospective client needs a problem solved immediately and is willing to pay for it. However, the product manager can’t really assign a timeframe to this process. SoberIT advises that business objectives may necessitate trade-offs between features and time-to-market.

Persona Definitions

The definition of personas and their associated problems provide the market requirements in the MRD. The product manager should write these

requirements in the persona’s business language, rather than provide a technical definition. The description of each requirement should be brief, usually no more than a

paragraph or two and never more than two pages. The key to this brevity is to avoid suggesting any solution for a problem to the software engineering outsourcing team. A requirement for a new

product should state a persona’s business problem, whereas a requirement for an existing product could also state a usage problem. The product manager will then combine these individual requirements into a cohesive whole when adding them to the MRD.

A persona’s problem should clearly express a situation that the product should be able to address. Product managers are increasingly more likely to use personas as the primary method of defining complex problems and less likely to use the traditional requirements-and-specifications approach. The use of personas allows the development team to focus on the end result rather than implementing each individual feature. This strategy is more attractive to expert software development teams because it involves more analysis and design at the beginning of the project.

Pragmatic Marketing advocates the use of personas for both the buyers and users of the product. These two groups are usually different people in the case of software since software buyers have different requirements than software users. Buyer personas are primarily concerned with the software’s business value, while the user persona is more concerned with its capabilities. Each persona includes a biography that provides the context needed to guide the development team. For example, a user persona that’s adept at creating spreadsheets indicates that the development team should focus on the software’s export capabilities rather than its ability to generate reports.

7

Major Feature Sets

The MRD also includes a description of the software’s major feature sets, which is especially useful for framing decisions on large products. The product manager should prioritize these features according to their

expected frequency of use, especially when the development team is using a lean development methodology such as agile. Solving market problems is the key to driving value in software, so the product manager should

consider adding a feature if it will increase revenue. The development of the MRD’s feature sets begins with an analysis of market requirements, especially what problems the software will solve.

The MRD shouldn’t be a static document, so the product manager will continue to refine the marketing plan over time. A complete view of the product is needed to minimize the possibility of repeating the product

development process due to the omission o Writing and Executing Great User Stories of a required feature. As Abraham Lincoln is purported to have said, “If I had eight hours to cut down a tree, I’d spend six hours

sharpening the axe.”

The next phase in the development of feature sets is engineering validation, which is intended to align the product strategy with the customer’s expectations. This phase involves ensuring that the developers can

actually deliver the desired feature sets on schedule, on budget and with the required quality. The product manager also needs to incorporate any new information on current market conditions before committing

the project to full development.

The purpose of the design verification phase is to ensure that the development team can create a shippable product. This phase includes verifying the product specifications, including those of the interface. It also

includes ensuring the software meets the relevant regulatory requirements for that industry, especially healthcare and financial software.

9

Writing and Executing Great User Stories

Software development projects have a greater chance of success when they use an agile methodology, rather than a traditional waterfall methodology. The 2011 CHAOS Manifesto found that agile projects had a 42 percent of complete success, as opposed to 14 percent for waterfall projects. Twenty-nine percent of waterfall projects failed completely, whereas, only 9 percent of agile projects were failures. Fifty-seven percent of waterfall projects were challenged to some extent, compared to 49 percent for agile projects.

User stories are one of the factors that improve a software engineering outsourcing project’s chances of success, and they’re also one of the most common techniques for capturing product functionality in agile projects. A user story is a short description of what a user needs the software to do, often consisting of a single sentence. They must be written in the user’s usual business language and take the user’s point of view. They capture the details of the system’s functional requirements in a concise manner, such that 12 user stories are typically needed to capture one marketing requirement. At the same time, a single user story may include 30 or more specific technical requirements.

User stories provide the basis for defining the system’s requirements and also facilitate the management of those requirements. User stories follow from solid market requirements. Once you've identified the problems you are going to solve in the MRD, the user stories further break those down to a story where we can define the product requirements. Product managers often confuse user stories with tasks, especially if they’re new to agile.

Mike Cohn, owner of Mountain Goat Software, says, “A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.”

The following tips can help you write and execute great user stories.

1110

Simplicity

User stories need to be simple and concise so that they’re easy to understand. They should also use active voice and avoid ambiguous terms. User stories often have the following format:As <persona>, I want <what?> so that <why?>.

The terms in brackets represent specific information that the user story requires, so each user story must provide a persona, a “what” and a “why. However, this format isn’t obligatory, and product managers can write user stories in other ways.

Epics

An epic is a story that serves as a headline and placeholder, which the product developer will typically refine into multiple user stories over time. The use of an epic allows the developer to sketch product functionality first, without initially providing any details. This strategy is especially useful for describing a product’s new features, since it allows the developer more time to determine the best method of addressing the user’s needs. Epics also reduce the effort needed to integrate new insights into the product backlog. This advantage is due to the general trend that inconsistencies in the backlog become more common as its size increases.

The product developer will break epics into smaller user stories that are more detailed. All members of the development team should have a clear understanding of the user story’s meaning. Furthermore, a user story must be testable, meaning the developers can effectively determine when the story is complete.

User stories must also acquire acceptance criteria as the product developer refines the epics. Acceptance criteria describe the conditions necessary to test the story, ensuring that the story is ready for release to the users. The user story typically has three to five acceptance criteria.

Collaboration

A user story is a tool for facilitating communication between the developers and users, rather than an actual requirements specification. The product manager needs to embed user stories in a conversation, instead of simply handing them off to the development team. Product managers can take this strategy even further and write user stories in collaboration with the development team, often as part of the product backlog process. The advantage of this approach is that it allows the development team to use its knowledge and creativity to create better stories. Use cases are a more formal technique for capturing product functionality than user stories, which product managers should use when they’re unable to collaborate with the nearshore software development team.

Early literature on Extreme Programming uses the term “story cards” instead of user stories since they were written on index cards. Even today, developers often capture user stories on paper cards because they’re inexpensive and widely available. Furthermore, cards encourage collaboration between developers since they can be displayed on a table and checked for inconsistencies and dependencies. Developers may then store the user stories electronically once they’re complete.

User stories should remain highly accessible since their primary purpose is to communicate information. They should not be placed in a restricted location such as a private network, company intranet or proprietary tool. User stories should be placed in a visible location such as a wall in the development. This practice promotes the collaboration and transparency that user stories need to be useful. A physical location also has limited space that helps to illustrate when stories are added too quickly.

User’s Perspective

A user story must be written from the user’s perspective and is particularly useful for capturing a specific functional requirement such as making a booking or performing a product search. The user tells a story that the software engineering outsourcing developer then uses to implement the desired functionality. A developer therefore requires a clear understanding of who the users are and why they would want to use the software. This requirement means that product development companies must observe and interview users before they begin writing user stories, thus ensuring that the stories are based on empirical evidence rather than beliefs. According to Cohn, “Even with a well-intentioned and highly communicative team, it is possible that the results of an iteration could be found worthless when shown to the broader organization or external users at the conclusion of the iteration.”

Technical Requirements

User stories are most useful for capturing product functionality, but they aren’t well-suited for describing the user experience and visual design of software. Developers therefore need to complement user stories with other techniques, such as sketches, storyboards and workflow diagrams. Furthermore, developers shouldn’t use user stories to capture technical requirements. A technical story or modeling language is more appropriate for communicating a system’s architectural elements. Finally, user stories are most useful for reusable software and may not be necessary when developing a prototype for the sole purpose of validating a design idea.

13

Assessing if Your Company Has the Resources to Execute on the Market Requirements Document

A market requirements document (MRD) expresses a customer’s requirements and desires for a product or services. Specific components of an MRD include the following:

• Description of the product• Competing products• Target customers• Reasons for customers to choose this product over its competitors

A product manager typically develops the MRD as part of the product management or marketing process based on input from other departments within the organization, including engineering, finance, marketing, research and sales. It’s also a component of the organization’s business case, and its annual marketing plan will typically include portions of the MRD. The Product Development Assessment (PDA) developed by DRM Associates provides a review of the development processes used by organizations throughout the world. This review is based on 250 best practices that allow a product manager to identify specific strategies for implementing an MRD.

The product manager will provide the MRD to a software engineering outsourcing team and the product steering committee if the company has one. Conflict between the product manager and engineering department can occur when one party attempts to assume the other’s responsibilities regarding product development. For example, the product manager is responsible for what is developed and why, while engineering is responsible for how the product is developed.

The product manager must also ensure the organization can execute on the MRD. The challenges in this process may be categorized into time-to-market requirements, resource requirements and flexibility requirements. These requirements are generally common to all organizations, although the strategy for meeting these requirements can vary according to the organization’s size. In particular, a small business will typically use a more direct approach to develop a product from an MRD.

14

Time-to-Market Requirements

Time-to-market is especially critical for SaaS products. Tim Pullen, director at Saaspoint Consulting, says, “Firms cannot wait around for 18 months… to implement traditional software; they want a quick payback from their business consulting [programs].” Enterprises must determine if they’re able to meet various time-to-market restraints, while small business just need to ensure they can bring the product to market quickly enough to meet their business goal.

The process for a rapid-to-market project includes several key requirements such as a clear understanding of the customer’s requirements from the beginning of the project. A software engineering outsourcing team may perform virtual product development early in the analysis phase to minimize the time need for physical mock-ups. Personnel and other resources must also be dedicated for the project to bring it to market quickly. Additional requirements for rapid product development include adding staff as needed to design the product in parallel with marketing it. Minimizing product development through the standardization reuse of designs is also an effective method of optimizing the product development process.

The product manager can implement several staffing strategies to minimize the product’s time-to-market, including the early involvement of personnel in multiple functional disciplines. The use of full-time personnel is also essential, as switching tasks slows down product development. If the necessary personnel and resources aren’t immediately available, it may be better in the long run to delay the start of the project. It’s also important to minimize transition delays when the product moves into production by maintaining the core product development team. This strategy allows the product manager to move resources more quickly to solve production problems and provide feedback directly to the development team.

Resource Requirements

An enterprise should assign personnel with the skill sets necessary to support each phase of product development. A small enterprise needs to focus on ensuring that it has the budget it will need to build and launch the product. NPD Solutions reports that product development frequently begins at the beginning of the fiscal year, without regard to the available resources or priorities of other projects. Furthermore, organizations often give little thought to the risk that a project poses, due to a lack of project planning.

The combination of these factors results in an over-commitment of development personnel by an average of 75 percent. In addition, the cost and schedule estimates of more than three-fourths of all product development projects are off by at least 10 percent. Finally, less than a fourth of all organizations have the resources needed to undertake all of their planned development projects.

Benchmarking can enable product managers to identify the key issues in resource planning and management that will minimize time-to-market. Best practices in benchmarking require an organization to develop an action plan to improve its product development process. This action plan should generally emphasize the concentration of resources on a small number of nearshore software development projects to get them done as quickly as possible. These resources may then be reassigned to the next project with the highest priority.

Another strategy for identifying key factors in the resource allocation for product development involves the level of those resources. A product manager can assume that development activities have a high priority if time-to-market is the organization’s primary objective. The organization must therefore maintain sufficient resources to support all open requirements, even if this means those resources aren’t completely committed at all times. The benefits of a faster time-to-market will typically outweigh the cost of a higher allocation of development resources in the case of SaaS products. The unit development cost of these SaaS products typically represents a large portion of the product’s cost, which implies that development resources should be sufficient to minimize downtime even when it delays other development activities.

Flexibility Requirements

An enterprise must minimize the number of open projects if it is to achieve the flexibility typically required to implement an MRD for a complex project like an SaaS product. This type of development environment requires product planning that largely considers each development project independently of the other projects. An enterprise’s decision to proceed with a particular project implies that it has a higher priority than any other project and will therefore receive the resources it needs to support its development.

Small- and medium-sized businesses (SMBs) with fewer than 50 people frequently plan development budget on a fiscal-year basis at a relatively constant level. The level of commitment for each project is usually low to accommodate multiple projects. The product plan for these organizations must include a strategy to guide the selection of development projects by defining the competitive strengths of each market. They must then establish the priority of each project and estimate the resources needed for its development. SMEs must also create a high-level schedule for these projects that balances resource requirements against the budget of the overall business plan.

Flexibility requirements for SaaS products also include scalability. SaaS customers typically need to scale up quickly once they determine the product meets their production needs. Luis Aburto, CEO for Scio,

says, “Building successful, scalable SaaS applications requires more than Web development skills. It requires an understanding of the intricacies of building and operating highly scalable,

multi-tenant architectures.”

17

Going to Market: Bridging the Gap between Development and Marketing

Software as a service (SaaS) tools are gaining ground against on-premise software requiring a perpetual license, according to a recent Forrester report. This report shows that SaaS budgets rose by 53 percent from 2012 to 2013, while the budgets for on-premise applications dropped by 13 percent during the same time period. This trend continues to accelerate, as shown by the rapidly expanding SaaS market. For example, a report in Forbes predicts that the SaaS market should reach $12 billion by the end of 2016 and $55 billion within 10 years after that. On-premise software won’t go away anytime soon, but it’s clear your SaaS budget will eventually surpass your on-premise budget.

An examination of the changes caused by SaaS typically focuses on the improvements that SaaS can make to an organization’s business operations. However, SaaS will also create a fundamental shift in IT departments, as CIOs discover that the infrastructure, processes, and skills they have developed over the past two decades have become obsolete. Matt Griffiths, former CIO of Biogen, says in an interview by the Society for Information Management, “This is much bigger than just a technology change.” Referring to the shift from on-premise software to SaaS, Griffiths adds, “There’s an entire organizational and cultural shift required to support that change.”

These changes are also affecting the process of software engineering outsourcing and bringing software to market. Bridging the gap between the development and marketing of an SaaS product requires the product manager to own the marketing message, which should be based on marketing requirements. This process involves the following components:

• Product boundaries• Development strategy• Marketing strategies• Customer onboarding

18

Product Boundaries

SaasAddict reports that SaaS developers often isolate their product from its marketing strategy, which can be a costly error in the case of nearshore software development. Traditional software involves a certain

degree of disconnection between software companies and their customers once the customer purchases the software licenses. Unless the customer needs technical support, they may never need to contact the

software company. However, SaaS products require an always-on connection between the developer and its customers that keeps them in constant contact. SaaS products therefore require a development strategy

that establishes a connection with the customer as quickly as possible, which the developer should leverage throughout the customer’s life cycle.

SaaS developers must understand the customer boundaries to their product, which typically include factors such as purchase price, mobile access, and login requirements. SaaS customers generally make

little distinction between a product, its service, and its support. Developers should therefore design their products to provide a seamless online experience. Software engineering outsourcing teams never settle for

merely providing the required features and functions for the product; they also create an online experience that satisfies business, personal, and professional needs. The ultimate objective of this strategy is to drive

revenue growth by pushing the three buttons for SaaS growth, including customer acquisition, lifetime value, and network effects.

Development Strategy

The marketing strategy for an SaaS product often involves allowing the product to sell itself. The online connection between the company and its customers provides an opportunity to enable customer self-

service, which will reduce costs and accelerate revenue. Innovative and creative product managers can find many ways to use this connection to deliver faster, cheaper service than their competition.

No conflict should exist between the strategies for the development and marketing of an SaaS product. However, the marketing team and development team need to collaborate if such a struggle does arise. This

process generally involves identifying the ways in which the software’s features will solve the customer’s pain points and developing user personas for the product.

21

Marketing Strategies

SaaS marketing strategists understand that optimizing content for social media is essential for improving the online awareness of their product. They also realize that an SaaS product must be an integral part of a social strategy. Furthermore, the product must produce search results by popular search engines that are publicly available. SaaS customers frequently produce content when using their product, including social media profiles and webpages. Product managers can facilitate the creation of these pages as part of the user’s experience, which automatically optimizes these pages for use by social media and search engines.

An SaaS marketing strategy must also account for the fact that e-commerce involves more than just accepting orders over the Internet. E-commerce includes the entire process of streamlining a customer’s online shopping experience, allowing customers to separate shopping from their offline activities. An e-commerce platform must provide automated sales assistance and other automated processes such as the following:

• Account conversions• Billing• Collections• Contract signing• Invoicing• Payments• Pricing

Free trials can be an effective marketing strategy for SaaS products, although they can be a challenge to implement well. Free trials shorten the sales cycle and facilitate product evaluation. They also help to streamline purchases through the conversion of a trial to the full product. Furthermore, SaaS customers are typically willing to provide inbound sales leads in exchange for a trial product. A free trial also provides the vendor with an opportunity to greatly increase sales through self-service.

Customer Onboarding

SaaS products typically require customers to on board themselves, which requires them to study, understand, and use the product without outside help. This requirement means that product managers must ensure that even non expert users can easily access new features. A superior SaaS product also strongly encourages novices to explore the execution of fundamental tasks, while allowing expert users to customize advanced tasks for greater performance.

Product churning is a business practice in which the vendor sells more of a product than what the customer actually needs. SaaS customers are particularly averse to this practice due to the competitiveness of this market and will quickly switch SaaS providers if they feel victims of churning. Increasing the use of a product is the most effective marketing strategy for reducing churn in SaaS products.

This strategy includes increasing all forms of use, such as casual use, habitual use, and organizational use. All of these forms of use build customer-specific content, which encourages mass personalization of the product and allows the vendor to achieve an economy of scale. One of the biggest advantages of mass personalization is that it protects SaaS vendors from competition. Competitors can theoretically copy every feature of an SaaS product, but they won’t be able to copy a customer’s personal data, which includes business data, preferences, policies, and usage history.

Customers go beyond buying themselves and begin making referrals once an SaaS product reaches the top of its growth pyramid. The customer life cycle begins with each prospective customer, allowing the product to stimulate viral growth by sharing information between prospects and existing customers. However, the process of streamlining information sharing requires the product manager to provide something for customers to share. For example, the critical business analysis can be highly effective for driving the growth of an SaaS product, since a discussion on product use can include a referral.

22

Great! You Have Gone to Market, Now What?

A successful Software-as-a-Service (SaaS) product launch requires continual market innovation in today’s competitive software marketplace. Software engineering outsourcing often involves rushing these products to market in their 1.0 version, typically resulting in a flawed release that’s disjointed and inconsistent. In contrast, nearshore software development that produces an innovative product and is easily accessible to its customers is much more likely to enjoy long-term success.

Innovation and agility are some of the most important reasons that SaaS deployments are becoming mission critical, according to a 2014 Garter survey. The IT marketing research firm conducted this survey to determine the deployment of cloud services across various delivery models, including SaaS. Joanne Correia, vice president of research at Gartner, stated, “The most commonly cited reasons the survey found for deploying SaaS were for development and testing production/mission-critical workloads.” She added that the survey results were “an affirmation that more businesses are comfortable with cloud deployments beyond the front office running sales force automation (SFA) and email.”

Cost reduction was the most important reason for investing in an SaaS deployment, according to 54 percent of the survey respondents. However, organizing these results by role tells a more meaningful story. Respondents in junior roles such as IT managers and staff clearly indicated that cost reduction was the most critical factor for them. Senior business executives below the CIO level also considered cost to be important, although not at the same rate as staff members. Executives in top IT roles such as CIOs considered operational agility and innovation to be the top drivers in their choice of SaaS products.

24

Validation

A quality SaaS product may perform better than one that uses aggressive marketing tactics. Software engineering outsourcing projects that aren’t ready for market can be identified by multiple push updates shortly after its release, especially if they add basic functionality that was missing in the first commercial version. On the other hand, customers will often hail a quality product even when it receives little pre-promotion.

For example, Slack is a developer of cloud business software that has experienced remarkable growth in its short history. This firm released a collaboration tool by the same name in February of 2014, which had 285,000 users by November of that year. Slack had over 500,000 active users as of February of 2015. Slack achieved these results by creating an exceptional product rather than making aggressive promotional efforts. Instead, it focused its pre-release efforts on core functionality such as file sharing, searching and data synchronization.

Stewart Butterfield, co-founder of Slack, said in a recent interview, “We developed Slack around really valuing those three things. It can sound simple, but narrowing the field can make big challenges and big gains for your company feel manageable.” Mainstream media began writing about Slack since it

was a good product, which increased its adoption rate. Slack is now one of the leading SaaS solutions in addition to being one of the world’s leading collaboration applications. Slack’s story shows that a functional product can outperform one with poor future uptake, even when it has a faster time to market.

Innovation

The nature of a cloud platform means that SaaS developers can easily update their products after the initial release, although the reason for doing so isn’t always clear. The purpose of an update may be to provide basic functionality or additional features that are nice to have. A patch that consists of only a few minor changes can sometimes be only the prelude to a major upgrade. Furthermore, developers may also release an update just to appear innovative and generate more buzz on their product.

A SaaS company will generally find success when it’s able to provide true innovation. For example, Slack was able to find a niche in the communication applications market by developing a solution for office communications. This solution solves the common problem of employees reducing their productivity by constantly sending email to each other.

Other innovators in SaaS include Xero, which released its self-named cloud accounting app in 2006. This SaaS developer was Forbes’ Most Innovative Growth Company in 2015, primarily due to its sustained innovations in cloud accounting. Cloud accounting wasn’t even a recognized industry niche when founder Rod Drury began looking for ways to make business accounting easier. His efforts were well-timed because accountants were also looking for changes in accounting software, which was generally considered mature technology at the time. Drury says that he began developing Xero when he “realized that it was very difficult to get useful information out of your accounting software. There was also no true way to collaborate with your financial advisor.”

Xero is an innovative application that primarily simplifies accounting for small business owners. It was the first application to host various accounting functions on the cloud such as accounts payable, account reconciliation, invoicing and payroll. Xero has also been able to retain its advantage of being first in cloud-based accounting by continually updating the look and feel of its product. This strategy allows Xero to remain competitive in the increasingly crowded cloud accounting app market. Other innovations by Xero include the addition of software integrations with other online solutions such as Dropbox and Paypal, which allow users to further streamline their accounting process.

Demand

Pricing and accessibility remain some of the most important factors for creating demand for an SaaS product. A product that is only available on a small number of cloud platforms will have difficulty generating high demand just as much as a product that’s overpriced. The cloud services market currently has many players, so SaaS providers typically must offer their solutions on many platforms to improve market penetration. Providers achieve success by charging a higher price and selling their service on larger platforms that require a lower commitment from their users.

This delivery model attracts users who are more concerned about making a long-term commitment with a new cloud platform before they decide if they like the product, even with a high initial price. This is especially true with users who have already spent a significant amount of time tailoring their preferences on their current SaaS subscription service. An SaaS developer that fails to provide a truly innovative product runs the risk of its potential customers remaining with what they already have or using nothing at all.

SaaS customers generally obtain applications from a platform that charges a subscription fee by the month or year. These platforms usually use tiered subscriptions rather than fixed subscriptions, meaning the fee is determined by factors such as campaigns, clicks and users. MailChimp is a typical example of a tiered subscription service. This service launched in 2001, although it didn’t offer its “freemium” option until 2009. This delivery option provides users with greater access when they scale up their services. The freemium option was instrumental in increasing MailChimp’s user base from 85,000 to 450,000 within one year of its introduction. Nearshore software development can help you become a hub of continued innovation for your company. Tiempo Development provides software engineering teams that specialize in agile development, which is well-suited for developing innovative products. Our team members routinely collaborate with their team managers to accommodate changes in user requirements. Contact Tiempo today to find out more about what we can do for you.

27

About TiempoTiempo Development has more than 10 years of experience in nearshore software development, allowing us to deliver SaaS software on time and on budget. We also understand the issues our customers face in assessing their resources for executing on the MRD. Contact us today to find out what Tiempo can do for you.

28