An Attempt to Making SaaS Development More Predictable

We firmly believe that changing the world around us for the better is everyone’s responsibility. Furthermore, it’s also our responsibility to learn and grow with each passing day, so that we’re able to improve the world around us.

For centuries, only a small group of people had the power to change the world. Among them there were kings, generals, heads of the church, artists, scientists, and only then the owners of multinational corporations. All others had to learn to survive and to comply with the wishes of the powerful ones.

During the past few decades, however, we’ve witnessed a radical change. As technology and democracy advanced across the globe, the power to change something from the ground up ended in the hands of tens or even hundreds of millions of people.

We are among the lucky ones. The ones building software. We are lucky because we can make an impact, if we wish to do so.

There are plenty of people with great ideas, initiative and energy. Many of them choose to become entrepreneurs. Many more others decide to become intrapreneurs in order to change companies, institutions and existing systems from within. Some want to transform a community, while others wish to revolutionise an entire industry. Most of them want to change something for the better.

Many of these initiatives have a major software component. However, as we all know, building quality software is challenging. Even more so if we consider projects built from the ground up.

In our discussions with our clients about their ideas, we often compare building software to building a tower block. Whenever an entrepreneur has an idea for a software project, the plan is to build a 100-storey tower block. Most of the times, however, there’s only budget for the foundation, the first two storeys and 5 parking spots.

The development team needs to start working from day 1 knowing that there would be a 100-storey building. They don’t know yet if there will be apartments, offices, shops, museums, or rather an all-in-one building. This calls for a foundation that’s ready in no time, but is still able to sustain the weight of the entire tower block. On top of that, it needs to be modifiable in time, as technology advances and the needs of the inhabitants change.

Unpredictable circumstances make building quality software very difficult. There’s no certainty as to what needs to be developed, since the needs of the users and the users themselves can differ from one month to another. Technology evolves so fast that last year’s version is already obsolete today.

The fact that many software projects started from scratch end up nowhere shouldn’t surprise anyone. Most such projects exceed their budget or take three times longer to complete. And that’s without taking quality issues into account.

SaaS Execution Map

Statistical chances are never in the favour of people with ideas who need quality software. There are more people in the world who have great ideas than there are people with the experience and expertise required for bringing these great ideas to life.

Success Factors — What Product Development Aspects Should You Mind?

There are numerous things that could go wrong and put an end to the project’s future. Working on 50 projects for tech startups has enabled us to identify the essential points that you can adjust to increase the success chances of any software project started from scratch.

Since this is a very complex field, we tried to condense all these success factors into a tool that can be used by anyone. We called it the ‘SaaS Execution Map’ (Software as a Service Execution Map).

1. Roles and Team Members

• Back-end developer
• Front-end developer
• DevOps engineer
• Mobile developer (iOS, Android or hybrid)
• QA automation engineer
• Tester
• Database Designer / Administrator
• Business Analyst
• Designer (Graphic, UX, identity)
• Project Manager
• Product Manager

Depending on the complexity of the project, chances are each of these roles will be needed at some point. Depending on the project, more specialized expertise might be required for managing large data sets, machine learning or medical imaging. However, you won’t need the whole team from day 1. Moreover, you won’t need the entire team throughout the entire duration of the project. Still, being able to anticipate when each team member is needed is essential, as it facilitates planning the workload.

2. Methodology — What Is the Team Working on and When?

Claiming that Scrum, with its two-week sprints and the ceremonies we all know, is the only methodology required for delivering a product is a far too simplistic approach. Scrum is barely the first step taken in the right direction, but it doesn’t guarantee anything.

The experience we’ve gathered and the mistakes we’ve made taught us that there should be 3 distinct phases in the first years of every software project started from scratch:

• From Zero to Product Design
• The launch of the minimum viable product (MVP)
• Further development to reach One.

In this context, we make the difference between innovation from Zero to One and from One to One Thousand.

The choice we’ve made is to focus on working on projects from Zero to One. The success factors we’ve identified are the most relevant to these projects. Each of these phases is characterised by a specific way of doing things and by different deliverables that the team should be working on.

To sum up:

• The problem: It’s getting more and more difficult to successfully build a software product from scratch.
• The opportunity: Following past years’ developments, we’re at a point where we, the ones working in the IT&C industry in Iasi, can have a significant, positive impact on our surroundings, locally, nationally and even globally.
• A possible solution: Besides energy and great ideas, there’s also an acute need for disciplined execution. The SaaS Execution Map is a tool that can significantly increase the success chances of projects that are started from scratch, and that have a major software component.

Product Design: It’s Time to Dream

At this point, the keyword is “creativity.” It’s time to dream and to sketch on a piece of paper the product or project’s long-term vision.

The more ideas the team puts on paper in the first few weeks, the greater the chances for team members working on the project in different phases to better understand the context and to contribute productively.

The concepts developed in this phase should cover all grounds and should be distributed throughout the upcoming project phases.

A possible example is the concept of “Personas.” We’ve learned along the way that it’s extremely important to have a clear image of the product’s ideal users. To find this out, you need to answer the following questions:

• Are the users of the product the same as the buyers?
• Do they have particular needs and/or behaviors?
• What is the market segment that we should target with the first version of the product, knowing that there’s not enough time, nor resources, to satisfy the needs of everyone.
• When exactly do we want to address the needs of each category of users or buyers?

It makes little difference what template you use for defining the personas for your product. In some contexts, it might be more useful to focus on demographic aspects. In other cases, the behavior users have when interacting might matter more.

It’s of utmost importance for team members to ask themselves “Who are we building this product for?”. Moreover, the answer to this question should be seen and understood by everyone involved in the project.

Among the visible results of the Product Design phase, there should be a prototype of the product. The prototype can take many forms and serve many purposes, depending on the project and the context.

There are cases when it’s useful to build a Visual Prototype that includes the application’s or platform’s final design of the main flows. There’s an enormous advantage in not having to write the entire app. That would take months or years with at least 4 or 5 people onboard, in order to validate the idea with clients or investors.

A Visual Prototype can take anywhere from several days to two weeks, and can save a lot of time and resources that would otherwise be spent on developing functionalities with no value for the users.

Other situations might require building a Functional Prototype. Technologies that are extremely new, and hence, untested, or that are at the limit between theoretical solutions and functional technologies call for a “proof of concept” in the form of a prototype. This can diminish the risks associated with technologies that might not be the right solution for the problems to be solved or for the team currently working on the project. We can all agree that it’s better to find this out 2 weeks into the project rather than after 6 or 12 months.

Launching an MVP: The Keyword Is ‘Focus’

During the second phase, when the launch of the MVP is prepared, the team’s attention shifts from creativity to quick delivery and the limitation of the project’s scope to a small set of essential functionalities. The keyword here is ‘focus.’

As a rule of thumb, an MVP can be developed with a small team in 3 months. Any MVP that takes more than 6 months to build is no longer an MVP, as it has too many functionalities.

Obviously, things are more complicated than in the Product Design phase. There are more team members, more moving mechanisms and more topics that could lead to surprises of the unpleasant kind. Many of them are already standardized by most of the companies: the backlog, separate development environments, sprints, non-functional requirements, etc.

In hindsight, the greatest mistakes we made taught us two things:

• NO
• Covering the product with automated test suites

Why ‘NO’? Because we all know how difficult it is to say NO. This is valid both in professional contexts, when a manager asks us to perform a task we don’t have time for, and in personal contexts, among friends and family members, when it’s extremely difficult to refuse someone.

And still, here lies the key to building an MVP efficiently.

NO.

We have NO time to add a functionality you thought about last night, without analysing the long-term impact on the product.

We have NO need for this button that has only been requested by a single customer, even if he threatens not buying the product otherwise.

We can make NO changes to the chosen technology. We first have to launch the MVP on the market, validate it, and only then consider major changes to the product.

The second learnt lesson refers to the need for covering the product with automated tests. It doesn’t matter if they’re unit tests, automated interface tests, integration or regression tests, API tests or any other kind.

The MVP represents the foundation and the first two storeys of the 100-storey tower block that we want to build. If there are no written tests for the MVP, it will be extremely painful and costly to make any changes to the product, add functionalities or expand the team with new people.

If tests aren’t written from the start, chances are they won’t ever be.

Development to One: In this phase, the focus shifts on ‘growth’

If everything goes according to plan, there will be a growth in:

• The Team
• Number of roles included in the team
• User base
• Code base
• Issues and difficulties that could appear along the way

The team needs to find the middle ground between two extremes that do not work. On one hand, we have the Waterfall approach, which involves writing extremely detailed documentation for the entire product, for everything that should be developed within the first year. In this unpredictable, always changing environment, it’s unrealistic to believe that it is possible to anticipate in detail all of the needs that the product should satisfy.

On the other hand, we have the pure Agile approach, that involves starting to work on a product and writing code without an initial plan, and without thinking ahead of how version 1 or 2 of the product should work.

Extremes are dangerous and rarely have a positive outcome.

The model we’ve developed after numerous iterations is represented by a flexible process that depends a lot on the type of product we’re developing. In any and all situations, there’s a team effort for finding the most efficient solution to a certain problem. The only variations appear when validating the solution with the beneficiary.

3. How to Work as a Real Team

In the best case scenario, when starting a new project, we’d team up with colleagues we’ve worked with for at least 2 or 3 years. That would mean that all team members know each other and work optimally from day 1. We all know that it’s unrealistic to have such expectations.

And yet, team communication and collaboration influence greatly the project’s success. At least that’s what we’ve learned over the years. Among the 3 main success factors, this one’s absolutely critical. If everyone involved in the project works as being part of the same team, the chances of success grow considerably.

What does a real team look like?

A definition that’s as good as any says that a real team is a group of people with:

• A common goal
• Complementary competencies and abilities
• Common values and beliefs
• Responsibility for their actions towards the other team members

If we analyse the way teams are assembled and disassembled, and how fast people change their roles, positions and even the companies they work for, it becomes clear that if we leave things to evolve on their own, naturally, the chances of developing a real team are nearly null.

Yet, if we take a look at the definition for real teams, we can see that it’s not as difficult as it seems. It shouldn’t take years for a group of people who are working together to identify the common scope.

The individual or the people who have to choose the components of the team need to make sure that the members have complementary competencies and abilities, as well as common values and beliefs. As for the responsibility towards their colleagues, this depends on the team members’ trust in each other.

A team that lacks trust is not a team. It’s just a group of individuals who happen to work together. They don’t share their knowledge, but compete against each other for a better position, don’t cooperate with one another.

It doesn’t matter how capable or talented these individuals are. They will never reach their true potential if there’s no trust. Nor can creative thinking, efficiency, productivity or collaboration exist without trust.

Maybe it’s more difficult than we’d wish, but if the product’s or company’s success depends on this, the effort is totally worth it.

The original article was published on December 5, 2016 in PIN Magazine, a Romanian publication that explores the people, technology and events in the local IT industry.