Step-by-Step Guide To

Successfully Creating and

Launching an Saas Product
Contents
The Anatomy of a Strong Market Requirement Document............................................................................................................4
High-Level Requirements....................................................................................................................................................................................................................... 6
Persona Definitions..................................................................................................................................................................................................................................... 7
Major Feature Sets..................................................................................................................................................................................................................................... 9
Writing and Executing Great User Stories...........................................................................................................................................10
User’s Perspective........................................................................................................................................................................................................................................ 12
Simplicity.............................................................................................................................................................................................................................................................. 12
Epics........................................................................................................................................................................................................................................................................ 12
Collaboration.................................................................................................................................................................................................................................................... 13
Technical Requirements........................................................................................................................................................................................................................... 13
Assessing if Your Company Has the Resources to Execute on the Market Requirements Document ..............................14
Time-to-Market Requirements.......................................................................................................................................................................................................... 16
Resource Requirements.......................................................................................................................................................................................................................... 16
Flexibility Requirements........................................................................................................................................................................................................................... 17
Going to Market: Bridging the Gap between Development and Marketing...............................................................................18
Product Boundaries.................................................................................................................................................................................................................................... 21
Development Strategy............................................................................................................................................................................................................................. 21
Marketing Strategies.................................................................................................................................................................................................................................. 22
Customer Onboarding.............................................................................................................................................................................................................................. 23
Great! You Have Gone to Market, Now What?...................................................................................................................................24
Validation............................................................................................................................................................................................................................................................. 26
Innovation........................................................................................................................................................................................................................................................... 26
Demand............................................................................................................................................................................................................................................................... 27
About 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 Requirements
The 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
 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
Writing and Executing Great chances of success, and they’re also one of the
most common techniques for capturing product

User Stories 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.

10 11

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.”
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, Technical Requirements
which product managers should use when they’re
unable to collaborate with the nearshore software
User stories are most useful for capturing
development team.
product functionality, but they aren’t well-
suited for describing the user experience
Early literature on Extreme Programming uses the
and visual design of software. Developers
term “story cards” instead of user stories since
therefore need to complement user stories
they were written on index cards. Even today,
with other techniques, such as sketches,
developers often capture user stories on paper cards
storyboards and workflow diagrams.
because they’re inexpensive and widely available.
Furthermore, developers shouldn’t use user
Furthermore, cards encourage collaboration
stories to capture technical requirements. A
between developers since they can be displayed
technical story or modeling language is more
on a table and checked for inconsistencies and
appropriate for communicating a system’s
dependencies. Developers may then store the user
architectural elements. Finally, user stories are
stories electronically once they’re complete.
most useful for reusable software and may not
be necessary when developing a prototype for
User stories should remain highly accessible since
the sole purpose of validating a design idea.
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.
13

Assessing if Your Company Has the
Resources to Execute on the Market
Requirements Document
14
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.
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
18
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
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 Customer Onboarding
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 SaaS products typically require customers to on board themselves, which requires them to study,
streamline purchases through the conversion of a trial to the full product. Furthermore, SaaS customers understand, and use the product without outside help. This requirement means that product managers
are typically willing to provide inbound sales leads in exchange for a trial product. A free trial also provides must ensure that even non expert users can easily access new features. A superior SaaS product also
the vendor with an opportunity to greatly increase sales through self-service. 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
 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.

Great! You Have Gone to Innovation and agility are some of the most important
Market, Now What? 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.
SaaS customers generally obtain applications
from a platform that charges a subscription fee
Demand by the month or year. These platforms usually
use tiered subscriptions rather than fixed
subscriptions, meaning the fee is determined
Pricing and accessibility remain some of the most
by factors such as campaigns, clicks and users.
important factors for creating demand for an SaaS
MailChimp is a typical example of a tiered
product. A product that is only available on a small
subscription service. This service launched in
number of cloud platforms will have difficulty
2001, although it didn’t offer its “freemium”
generating high demand just as much as a product
option until 2009. This delivery option
that’s overpriced. The cloud services market currently
provides users with greater access when they
has many players, so SaaS providers typically must
scale up their services. The freemium option
offer their solutions on many platforms to improve
was instrumental in increasing MailChimp’s
market penetration. Providers achieve success by
user base from 85,000 to 450,000 within one
charging a higher price and selling their service on
year of its introduction.
larger platforms that require a lower commitment
from their users.
Nearshore software development can help
you become a hub of continued innovation for
This delivery model attracts users who are more
your company. Tiempo Development provides
concerned about making a long-term commitment
software engineering teams that specialize in
with a new cloud platform before they decide if
agile development, which is well-suited for
they like the product, even with a high initial price.
developing innovative products. Our team
This is especially true with users who have already
members routinely collaborate with their team
spent a significant amount of time tailoring their
managers to accommodate changes in user
preferences on their current SaaS subscription
requirements. Contact Tiempo today to find
service. An SaaS developer that fails to provide a
out more about what we can do for you.
truly innovative product runs the risk of its potential
customers remaining with what they already have or
using nothing at all.
27
 About Tiempo
Tiempo 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